Re: [DISCUSS] Sending 3.4 release line to End-Of-Life status
On Fri, Apr 3, 2020 at 12:57 PM Patrick Hunt wrote:
>
> On Thu, Apr 2, 2020 at 1:14 PM Christopher wrote:
>
> > On Thu, Apr 2, 2020 at 12:20 PM Patrick Hunt wrote:
> > >
> > > On Thu, Apr 2, 2020 at 8:15 AM Andor Molnar wrote:
> > >
> > > > Alright. Not sure how to coordinate this properly, let’s try to discuss
> > > > these 3 points individually.
> > > >
> > > > 1) EOL is 1st of June, 2020 which means from this day forward 3.4 is
> > ...
> > > >- not supported by the community dev team,
> > > >- not accepting patches, no future releases, no security fixes,
> > > >- latest version is still accessible at download page for 1(?) year
> > > >
> > > >
> > > Apache archival process is documented on this page:
> > > https://www.apache.org/legal/release-policy.html#when-to-archive
> > > we do get nudged on it every so often: e.g.
> > > https://issues.apache.org/jira/browse/ZOOKEEPER-1752
> >
> > The archival process is regarding removal of old versions from the
> > mirroring system. It does not apply to "current" releases ("current"
> > being defined as still linked from the project's download page).
> >
> >
> The text is pretty unequivocal and not what you are saying.
>
> "downloads.apache.org should contain *the latest release in each branch
> that is currently under development*. When development ceases on a version
> branch, releases of that branch should be removed from the project's
> download directory."
>
> Meaning it should go to archive only once the branch is no longer under
> active development, not that it would be "removed". The semantics btw
> archive and remove are different. I don't think we should ever truly
> "remove" anything once we've officially released it. eg. you can still find
> 3.3 on the archive site if you want it.
The portion you are quoting is from an FAQ, below the release policy,
not the release policy itself. The actual policy doesn't address the
archival *process*, only the requirement that releases be archived.
The release policy is set by VP Legal, whereas the release and
archival *processes* are managed by VP Infra. The FAQs have their
shortcomings and could be improved (this isn't the first time these
FAQs have caused confusion by seemingly conflicting with how INFRA
operates the distribution channels).
In order to be consistent with best practices for how the mirror
system is intended to be used for release artifact distribution, I
interpret "When development ceases" to refer to the entire development
lifecycle, including release promotion via announcements and
availability on the downloads page. Otherwise, you'd have to archive
any "final release" of a branch immediately, and if you wanted to
widely distribute the release by promoting it on the downloads page,
you would have to link to the archives which is *BAD*. Projects
should distribute releases via the mirroring system, not via the
archives. Once they stop promoting the artifacts on their downloads
page, the artifacts should be removed (archived) from
SVN/dist.apache.org as the same time.
If you're uncomfortable with interpreting "development" to include the
release promotion period where they are linked on the downloads page,
you could instead just choose to not "cease" development until you are
ready to remove it from the downloads page. You could slow development
down to the point where maybe you might still release critical
security fixes, for example, but really nothing else. Development is
still "active" and hasn't "ceased". But, what you should not do, is
continue promoting the artifact on the downloads page with a link to
the archives.
If somebody from INFRA wants to contradict me on this... I'm happy to
be corrected with more accurate information... but I'm 99% confident
they don't want releases being promoted that cause users to pull more
heavily on the archives servers, as that would be a costly drain on
Foundation resources.
All that said, the last 3.4 release has been promoted on the downloads
page for over a year now, which is probably long enough for a final
release, so it's probably easiest to just go ahead and remove it from
your downloads page (and from the mirrors, of course) sooner, rather
than wait until later.
[jira] [Created] (ZOOKEEPER-3784) PrometheusProvider uses deprecated sun.misc.Unsafe
Karthik Prasad created ZOOKEEPER-3784:
-
Summary: PrometheusProvider uses deprecated sun.misc.Unsafe
Key: ZOOKEEPER-3784
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3784
Project: ZooKeeper
Issue Type: Bug
Components: metric system
Affects Versions: 3.6.0
Reporter: Karthik Prasad
Attachments: zoo.log
Enabled Prometheus Metrics Server on zookeeper that is running on
OpenJDK-11.0.5 with minimal modules enabled. Server crashed with below error.
{code:java}
// code placeholder
{code}
2020-04-04 05:17:32,310 [myid:1] - INFO [main:AbstractConnector@330] - Started
ServerConnector@7c711375\{HTTP/1.1,[http/1.1]}{0.0.0.0:7000}2020-04-04
05:17:32,310 [myid:1] - INFO [main:AbstractConnector@330] - Started
ServerConnector@7c711375\{HTTP/1.1,[http/1.1]}{0.0.0.0:7000}2020-04-04
05:17:32,311 [myid:1] - INFO [main:Server@399] - Started @897ms2020-04-04
05:17:32,321 [myid:1] - INFO [main:ServerMetrics@62] - ServerMetrics
initialized with provider
org.apache.zookeeper.metrics.prometheus.PrometheusMetricsProvider@5efa40fe2020-04-04
05:17:32,334 [myid:1] - INFO [main:AbstractConnector@380] - Stopped
ServerConnector@7c711375\{HTTP/1.1,[http/1.1]}{0.0.0.0:7000}2020-04-04
05:17:32,335 [myid:1] - INFO [main:ContextHandler@1016] - Stopped
o.e.j.s.ServletContextHandler@4c163e3\{/,null,UNAVAILABLE}Exception in thread
"main" java.lang.NoClassDefFoundError: sun/misc/Unsafe at
io.prometheus.client.Striped64.getUnsafe(Striped64.java:316) at
io.prometheus.client.Striped64.(Striped64.java:296) at
io.prometheus.client.Summary$Child.(Summary.java:260) at
io.prometheus.client.Summary$Child.(Summary.java:198) at
io.prometheus.client.Summary.newChild(Summary.java:159) at
io.prometheus.client.Summary.newChild(Summary.java:81) at
io.prometheus.client.SimpleCollector.labels(SimpleCollector.java:76) at
io.prometheus.client.SimpleCollector.initializeNoLabelsChild(SimpleCollector.java:107)
at io.prometheus.client.Summary.(Summary.java:92) at
io.prometheus.client.Summary$Builder.create(Summary.java:136) at
io.prometheus.client.Summary$Builder.create(Summary.java:95) at
io.prometheus.client.SimpleCollector$Builder.register(SimpleCollector.java:245)
at
org.apache.zookeeper.metrics.prometheus.PrometheusMetricsProvider$PrometheusSummary.(PrometheusMetricsProvider.java:348)
at
org.apache.zookeeper.metrics.prometheus.PrometheusMetricsProvider$Context.lambda$getSummary$2(PrometheusMetricsProvider.java:235)
at java.base/java.util.concurrent.ConcurrentHashMap.computeIfAbsent(Unknown
Source) at
org.apache.zookeeper.metrics.prometheus.PrometheusMetricsProvider$Context.getSummary(PrometheusMetricsProvider.java:231)
at org.apache.zookeeper.server.ServerMetrics.(ServerMetrics.java:70) at
org.apache.zookeeper.server.ServerMetrics.metricsProviderInitialized(ServerMetrics.java:63)
at
org.apache.zookeeper.server.quorum.QuorumPeerMain.runFromConfig(QuorumPeerMain.java:161)
at
org.apache.zookeeper.server.quorum.QuorumPeerMain.initializeAndRun(QuorumPeerMain.java:136)
at
org.apache.zookeeper.server.quorum.QuorumPeerMain.main(QuorumPeerMain.java:90)Caused
by: java.lang.ClassNotFoundException: sun.misc.Unsafe at
java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(Unknown Source) at
java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(Unknown
Source) at java.base/java.lang.ClassLoader.loadClass(Unknown Source) ... 21 more
When I enabled jdk.unsupported module, zookeeper server started and able to
access prometheus metrics. However jdk.unsupported is deprecated.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: ZooKeeper snapCount Tuning
The workload is a more deciding factor than hardwares when tuning zookeeper.snapCount and other config parameters, under current ZK implementation. I am afraid there is no universal value that applicable to every case although we can provide recommended settings by benchmarking predictable and usual workloads. In any cases, larger snap count leading to less frequent snapshotting, which should improve system performance but at the cost of longer recovery time. For new hardwares, I think most of time ZK just get the benefit for free. For preallocation, I agree and think that'll still be useful, as that's a file system thing and work regardless of underlying medium. To get optimal usage of the new hardware would require more thought, and just borrow some ideas from database world that might applicable to ZK: * Off loading snapshot to dedicated hardware accelerator like FPGA. * SyncRequestProcessor can flush transaction to NVRam without buffering and group commit. * Durable ZK data tree on NVRam that does not require WAL and snapshot. I suspect not much going on here as ZK, unlike databases, never received enough workloads (which is a by design) that justifies the investment. On Fri, Apr 3, 2020 at 1:34 PM Ted Dunning wrote: > On Fri, Apr 3, 2020 at 10:01 AM Patrick Hunt wrote: > > > ... > > Makes sense. For eg. SSD characteristics are vastly diff from spinning > > media. > > > super true. > > > > I suspect it would be worth looking into this in even more depth - > > we pre-allocate certain files, perhaps that's no longer necessary, etc... > > > > The preallocation still makes sense on most file systems since meta-data > changes (i.e. changing file length) are much more expensive than data > changes (overwriting previously allocated blocks). > > Makes sense. If we do something it would be great to have a set of tests > > that could be used/reused to explore the various types even beyond SSD > > itself. > > > > Indeed. Storage class memory, for example, could make for an amazing ZK > implementation. So could use of the upcoming SSD devices that implement > key-value stores. > > > > > > Regards, > > > > Patrick > > > > > > > My hypothesis is: with a larger snapCount value, ZK can have higher > > > throughput because it is spending less time creating snapshots. > > > > > > Thanks! > > > > > >
Re: ZooKeeper snapCount Tuning
On Fri, Apr 3, 2020 at 10:01 AM Patrick Hunt wrote: > ... > Makes sense. For eg. SSD characteristics are vastly diff from spinning > media. super true. > I suspect it would be worth looking into this in even more depth - > we pre-allocate certain files, perhaps that's no longer necessary, etc... > The preallocation still makes sense on most file systems since meta-data changes (i.e. changing file length) are much more expensive than data changes (overwriting previously allocated blocks). Makes sense. If we do something it would be great to have a set of tests > that could be used/reused to explore the various types even beyond SSD > itself. > Indeed. Storage class memory, for example, could make for an amazing ZK implementation. So could use of the upcoming SSD devices that implement key-value stores. > > Regards, > > Patrick > > > > My hypothesis is: with a larger snapCount value, ZK can have higher > > throughput because it is spending less time creating snapshots. > > > > Thanks! > > >
Re: ZooKeeper snapCount Tuning
On Fri, Apr 3, 2020 at 6:19 AM David Mollitor wrote: > Hello Community, > > The configuration zookeeper.snapCount defaults to a value of 100,000 and > has been at this default for 11 years now. > > > https://github.com/apache/zookeeper/blob/e87bad6774e7269ef21a156aff9dad089ef54794/zookeeper-server/src/main/java/org/apache/zookeeper/server/ZooKeeperServer.java#L1149 > > Based on the last ZK meetup, I know there has been some recent attempts to > re-run the baseline performance benchmarks. > > The current value may be a "safe" value. However, I think we can all agree > that hardware has improved quite a bit in the past 11 years. Does anyone > have any experience tweaking and testing this number on a production > system? Are there any recommendations out there for how to set this value? > > Makes sense. For eg. SSD characteristics are vastly diff from spinning media. I suspect it would be worth looking into this in even more depth - we pre-allocate certain files, perhaps that's no longer necessary, etc... Makes sense. If we do something it would be great to have a set of tests that could be used/reused to explore the various types even beyond SSD itself. Regards, Patrick > My hypothesis is: with a larger snapCount value, ZK can have higher > throughput because it is spending less time creating snapshots. > > Thanks! >
Re: [DISCUSS] Sending 3.4 release line to End-Of-Life status
On Thu, Apr 2, 2020 at 1:14 PM Christopher wrote:
> On Thu, Apr 2, 2020 at 12:20 PM Patrick Hunt wrote:
> >
> > On Thu, Apr 2, 2020 at 8:15 AM Andor Molnar wrote:
> >
> > > Alright. Not sure how to coordinate this properly, let’s try to discuss
> > > these 3 points individually.
> > >
> > > 1) EOL is 1st of June, 2020 which means from this day forward 3.4 is
> ...
> > >- not supported by the community dev team,
> > >- not accepting patches, no future releases, no security fixes,
> > >- latest version is still accessible at download page for 1(?) year
> > >
> > >
> > Apache archival process is documented on this page:
> > https://www.apache.org/legal/release-policy.html#when-to-archive
> > we do get nudged on it every so often: e.g.
> > https://issues.apache.org/jira/browse/ZOOKEEPER-1752
>
> The archival process is regarding removal of old versions from the
> mirroring system. It does not apply to "current" releases ("current"
> being defined as still linked from the project's download page).
>
>
The text is pretty unequivocal and not what you are saying.
"downloads.apache.org should contain *the latest release in each branch
that is currently under development*. When development ceases on a version
branch, releases of that branch should be removed from the project's
download directory."
Meaning it should go to archive only once the branch is no longer under
active development, not that it would be "removed". The semantics btw
archive and remove are different. I don't think we should ever truly
"remove" anything once we've officially released it. eg. you can still find
3.3 on the archive site if you want it.
Patrick
> The question here is regarding the timing for removal from the
> project's download page. I suggest event-based, rather than
> time-based. Since ZK seems to be maintaining 3 release lines
> concurrently, you could remove 3.4 when 3.7 is released, unless
> there's a good reason to drop it sooner (to reduce the number of
> concurrent releases supported to 2, for example).
>
> >
> >
> > > 2) Supported upgrade path is: latest 3.4 -> latest 3.5 -> latest 3.6
> > >
> > > 3) Interoperability guarantees:
> > >- Previous version of ZooKeeper client is able to connect to server
> as
> > > long as there’s no new feature enforced on server side,
> > >- Previous version of ZooKeeper server is able to accept connections
> > > from clients as long as they don’t want to use new features.
> > >
> > >
> > I believe 2/3 are consistent with "Backward Compatibility" here?
> > https://cwiki.apache.org/confluence/display/ZOOKEEPER/ReleaseManagement
> >
> > Patrick
> >
> >
> > > Thoughts?
> > >
> > > Andor
> > >
> > >
> > >
> > >
> > > > On 2020. Apr 2., at 6:30, Michael Han wrote:
> > > >
> > > > +1.
> > > >
> > > > For EOL policy statement, just to throw something out here that i can
> > > think
> > > > of:
> > > >
> > > > * Define what EOL means (such as: not supported by community dev team
> > > > anymore, no future 3.4 releases .. still accessible at download page
> for
> > > X
> > > > years..) and a date of EOL.
> > > >
> > > > * Provide guidelines for upgrading paths to 3.5 / 3.6.
> > > >
> > > > * State interoperability guarantees another post pointed out
> previously ^
> > > >
> > > > On Wed, Apr 1, 2020 at 2:04 AM Andor Molnar
> wrote:
> > > >
> > > >> Hi folks,
> > > >>
> > > >> Based on Enrico’s latest post about a 3.4 client problem I’d like to
> > > push
> > > >> this initiative.
> > > >> Asking more senior members of the community what communicated
> policy is
> > > >> needed exactly to say 3.4 is EoL?
> > > >>
> > > >> In terms of timing I’d like Patrick’s suggestion about 1st of June,
> > > 2020.
> > > >>
> > > >> Any objections?
> > > >>
> > > >> Andor
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>> On 2020. Mar 4., at 18:45, Michael K. Edwards <
> m.k.edwa...@gmail.com>
> > > >> wrote:
> > > >>>
> > > >>> I think it would be useful for an EOL statement about 3.4.x to
> include
> > > a
> > > >>> policy on interoperability of newer ZooKeeper servers with 3.4.x
> client
> > > >>> code. Stacks that build on top of Kafka and Hadoop (I'm looking at
> > > you,
> > > >>> Spark) often wind up having an indirect dependency on a comically
> stale
> > > >>> ZooKeeper library. Even if this library isn't really exercised by
> the
> > > >>> client side of the stack, it's there in the mountain of jars; and
> when
> > > >>> application code also wants to use ZooKeeper more directly, using a
> > > newer
> > > >>> client library can get kind of messy. The approach I've taken has
> been
> > > >> to
> > > >>> rebuild large swathes of the stack around a consistent, recent
> > > ZooKeeper
> > > >>> build; but I think it would be relevant to a lot of people to know
> > > >> whether,
> > > >>> say, a 3.4.14 client will work reliably with a 3.6.x quorum.
> > > >>>
> > > >>> On Wed, Mar 4, 2020 at 9:28 AM Enrico Olivelli <
> eolive...@gmail.com>
> > > >> wrote:
> > > >>>
> > > Il giorno
Re: [ANNOUNCE] New ZooKeeper committer: Mate Szalay-Beko
Congrats!!! > On Apr 3, 2020, at 3:42 AM, Andor Molnar wrote: > > The Apache ZooKeeper PMC recently extended committer karma to Mate and he has > accepted. > Mate has made some great contributions (including C client!) and we are > looking forward to even more. :) > > Congratulations and welcome aboard, Mate! > >
Re: [ANNOUNCE] New ZooKeeper committer: Mate Szalay-Beko
Kudos Mate! Patrick On Fri, Apr 3, 2020 at 3:07 AM tison wrote: > Kudos Mate! > > Best, > tison. > > > Tamas Penzes 于2020年4月3日周五 下午5:53写道： > > > Congrats Mate! > > > > On Fri, Apr 3, 2020, 10:42 Andor Molnar wrote: > > > > > The Apache ZooKeeper PMC recently extended committer karma to Mate and > he > > > has accepted. > > > Mate has made some great contributions (including C client!) and we are > > > looking forward to even more. :) > > > > > > Congratulations and welcome aboard, Mate! > > > > > > > > > > > >
ZooKeeper snapCount Tuning
Hello Community, The configuration zookeeper.snapCount defaults to a value of 100,000 and has been at this default for 11 years now. https://github.com/apache/zookeeper/blob/e87bad6774e7269ef21a156aff9dad089ef54794/zookeeper-server/src/main/java/org/apache/zookeeper/server/ZooKeeperServer.java#L1149 Based on the last ZK meetup, I know there has been some recent attempts to re-run the baseline performance benchmarks. The current value may be a "safe" value. However, I think we can all agree that hardware has improved quite a bit in the past 11 years. Does anyone have any experience tweaking and testing this number on a production system? Are there any recommendations out there for how to set this value? My hypothesis is: with a larger snapCount value, ZK can have higher throughput because it is spending less time creating snapshots. Thanks!
Re: [DISCUSS] Sending 3.4 release line to End-Of-Life status
I think maintaining and storing releases are two different things. We don’t
want to maintain 3 release lines that’s why we want to announce 3.4 EoL. Apache
asked us to host only the latest releases on ‘downloads’ server and move
everything else to ‘archive’. I don’t bother making them available for eternity
if Apache is happy with that. e.g. I’m still able to download 3.3.x versions
from the archive.
In terms of testing I’ll do some quick smoke tests with different client-server
combination before making the announcement. Bear with me.
Please keep share your thoughts until that.
Andor
> On 2020. Apr 2., at 22:14, Christopher wrote:
>
> On Thu, Apr 2, 2020 at 12:20 PM Patrick Hunt wrote:
>>
>> On Thu, Apr 2, 2020 at 8:15 AM Andor Molnar wrote:
>>
>>> Alright. Not sure how to coordinate this properly, let’s try to discuss
>>> these 3 points individually.
>>>
>>> 1) EOL is 1st of June, 2020 which means from this day forward 3.4 is ...
>>> - not supported by the community dev team,
>>> - not accepting patches, no future releases, no security fixes,
>>> - latest version is still accessible at download page for 1(?) year
>>>
>>>
>> Apache archival process is documented on this page:
>> https://www.apache.org/legal/release-policy.html#when-to-archive
>> we do get nudged on it every so often: e.g.
>> https://issues.apache.org/jira/browse/ZOOKEEPER-1752
>
> The archival process is regarding removal of old versions from the
> mirroring system. It does not apply to "current" releases ("current"
> being defined as still linked from the project's download page).
>
> The question here is regarding the timing for removal from the
> project's download page. I suggest event-based, rather than
> time-based. Since ZK seems to be maintaining 3 release lines
> concurrently, you could remove 3.4 when 3.7 is released, unless
> there's a good reason to drop it sooner (to reduce the number of
> concurrent releases supported to 2, for example).
>
>>
>>
>>> 2) Supported upgrade path is: latest 3.4 -> latest 3.5 -> latest 3.6
>>>
>>> 3) Interoperability guarantees:
>>> - Previous version of ZooKeeper client is able to connect to server as
>>> long as there’s no new feature enforced on server side,
>>> - Previous version of ZooKeeper server is able to accept connections
>>> from clients as long as they don’t want to use new features.
>>>
>>>
>> I believe 2/3 are consistent with "Backward Compatibility" here?
>> https://cwiki.apache.org/confluence/display/ZOOKEEPER/ReleaseManagement
>>
>> Patrick
>>
>>
>>> Thoughts?
>>>
>>> Andor
>>>
>>>
>>>
>>>
On 2020. Apr 2., at 6:30, Michael Han wrote:
+1.
For EOL policy statement, just to throw something out here that i can
>>> think
of:
* Define what EOL means (such as: not supported by community dev team
anymore, no future 3.4 releases .. still accessible at download page for
>>> X
years..) and a date of EOL.
* Provide guidelines for upgrading paths to 3.5 / 3.6.
* State interoperability guarantees another post pointed out previously ^
On Wed, Apr 1, 2020 at 2:04 AM Andor Molnar wrote:
> Hi folks,
>
> Based on Enrico’s latest post about a 3.4 client problem I’d like to
>>> push
> this initiative.
> Asking more senior members of the community what communicated policy is
> needed exactly to say 3.4 is EoL?
>
> In terms of timing I’d like Patrick’s suggestion about 1st of June,
>>> 2020.
>
> Any objections?
>
> Andor
>
>
>
>
>> On 2020. Mar 4., at 18:45, Michael K. Edwards
> wrote:
>>
>> I think it would be useful for an EOL statement about 3.4.x to include
>>> a
>> policy on interoperability of newer ZooKeeper servers with 3.4.x client
>> code. Stacks that build on top of Kafka and Hadoop (I'm looking at
>>> you,
>> Spark) often wind up having an indirect dependency on a comically stale
>> ZooKeeper library. Even if this library isn't really exercised by the
>> client side of the stack, it's there in the mountain of jars; and when
>> application code also wants to use ZooKeeper more directly, using a
>>> newer
>> client library can get kind of messy. The approach I've taken has been
> to
>> rebuild large swathes of the stack around a consistent, recent
>>> ZooKeeper
>> build; but I think it would be relevant to a lot of people to know
> whether,
>> say, a 3.4.14 client will work reliably with a 3.6.x quorum.
>>
>> On Wed, Mar 4, 2020 at 9:28 AM Enrico Olivelli
> wrote:
>>
>>> Il giorno mer 4 mar 2020 alle ore 17:23 Patrick Hunt
>>> ha scritto:
It seems like we should have a stated/communicated policy around
> release
lifecycles before sending an EOL message. That way folks have some
> runway
to plan for the event, both near term (3.4) as well as l
Re: [ANNOUNCE] New ZooKeeper committer: Mate Szalay-Beko
Kudos Mate! Best, tison. Tamas Penzes 于2020年4月3日周五 下午5:53写道： > Congrats Mate! > > On Fri, Apr 3, 2020, 10:42 Andor Molnar wrote: > > > The Apache ZooKeeper PMC recently extended committer karma to Mate and he > > has accepted. > > Mate has made some great contributions (including C client!) and we are > > looking forward to even more. :) > > > > Congratulations and welcome aboard, Mate! > > > > > > >
Re: [ANNOUNCE] New ZooKeeper committer: Mate Szalay-Beko
Congrats Mate! On Fri, Apr 3, 2020, 10:42 Andor Molnar wrote: > The Apache ZooKeeper PMC recently extended committer karma to Mate and he > has accepted. > Mate has made some great contributions (including C client!) and we are > looking forward to even more. :) > > Congratulations and welcome aboard, Mate! > > >
Re: [DISCUSS] Sending 3.4 release line to End-Of-Life status
Well, for a long time we only had 1 line maintained, 3.4 basically. It is
just right now we have 3 lines, which is I think one too many. (Plus we
also have master to maintain additional to the active release lines, that's
4 active branches. Well, more or less, 3.4 is pretty inactive already).
I pretty much agree with Andor's points. My only comment is what testing do
we do to achieve number 3? (different version of client-server
connectability)
- Norbert
On Thu, Apr 2, 2020 at 10:14 PM Christopher wrote:
> On Thu, Apr 2, 2020 at 12:20 PM Patrick Hunt wrote:
> >
> > On Thu, Apr 2, 2020 at 8:15 AM Andor Molnar wrote:
> >
> > > Alright. Not sure how to coordinate this properly, let’s try to discuss
> > > these 3 points individually.
> > >
> > > 1) EOL is 1st of June, 2020 which means from this day forward 3.4 is
> ...
> > >- not supported by the community dev team,
> > >- not accepting patches, no future releases, no security fixes,
> > >- latest version is still accessible at download page for 1(?) year
> > >
> > >
> > Apache archival process is documented on this page:
> > https://www.apache.org/legal/release-policy.html#when-to-archive
> > we do get nudged on it every so often: e.g.
> > https://issues.apache.org/jira/browse/ZOOKEEPER-1752
>
> The archival process is regarding removal of old versions from the
> mirroring system. It does not apply to "current" releases ("current"
> being defined as still linked from the project's download page).
>
> The question here is regarding the timing for removal from the
> project's download page. I suggest event-based, rather than
> time-based. Since ZK seems to be maintaining 3 release lines
> concurrently, you could remove 3.4 when 3.7 is released, unless
> there's a good reason to drop it sooner (to reduce the number of
> concurrent releases supported to 2, for example).
>
> >
> >
> > > 2) Supported upgrade path is: latest 3.4 -> latest 3.5 -> latest 3.6
> > >
> > > 3) Interoperability guarantees:
> > >- Previous version of ZooKeeper client is able to connect to server
> as
> > > long as there’s no new feature enforced on server side,
> > >- Previous version of ZooKeeper server is able to accept connections
> > > from clients as long as they don’t want to use new features.
> > >
> > >
> > I believe 2/3 are consistent with "Backward Compatibility" here?
> > https://cwiki.apache.org/confluence/display/ZOOKEEPER/ReleaseManagement
> >
> > Patrick
> >
> >
> > > Thoughts?
> > >
> > > Andor
> > >
> > >
> > >
> > >
> > > > On 2020. Apr 2., at 6:30, Michael Han wrote:
> > > >
> > > > +1.
> > > >
> > > > For EOL policy statement, just to throw something out here that i can
> > > think
> > > > of:
> > > >
> > > > * Define what EOL means (such as: not supported by community dev team
> > > > anymore, no future 3.4 releases .. still accessible at download page
> for
> > > X
> > > > years..) and a date of EOL.
> > > >
> > > > * Provide guidelines for upgrading paths to 3.5 / 3.6.
> > > >
> > > > * State interoperability guarantees another post pointed out
> previously ^
> > > >
> > > > On Wed, Apr 1, 2020 at 2:04 AM Andor Molnar
> wrote:
> > > >
> > > >> Hi folks,
> > > >>
> > > >> Based on Enrico’s latest post about a 3.4 client problem I’d like to
> > > push
> > > >> this initiative.
> > > >> Asking more senior members of the community what communicated
> policy is
> > > >> needed exactly to say 3.4 is EoL?
> > > >>
> > > >> In terms of timing I’d like Patrick’s suggestion about 1st of June,
> > > 2020.
> > > >>
> > > >> Any objections?
> > > >>
> > > >> Andor
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>> On 2020. Mar 4., at 18:45, Michael K. Edwards <
> m.k.edwa...@gmail.com>
> > > >> wrote:
> > > >>>
> > > >>> I think it would be useful for an EOL statement about 3.4.x to
> include
> > > a
> > > >>> policy on interoperability of newer ZooKeeper servers with 3.4.x
> client
> > > >>> code. Stacks that build on top of Kafka and Hadoop (I'm looking at
> > > you,
> > > >>> Spark) often wind up having an indirect dependency on a comically
> stale
> > > >>> ZooKeeper library. Even if this library isn't really exercised by
> the
> > > >>> client side of the stack, it's there in the mountain of jars; and
> when
> > > >>> application code also wants to use ZooKeeper more directly, using a
> > > newer
> > > >>> client library can get kind of messy. The approach I've taken has
> been
> > > >> to
> > > >>> rebuild large swathes of the stack around a consistent, recent
> > > ZooKeeper
> > > >>> build; but I think it would be relevant to a lot of people to know
> > > >> whether,
> > > >>> say, a 3.4.14 client will work reliably with a 3.6.x quorum.
> > > >>>
> > > >>> On Wed, Mar 4, 2020 at 9:28 AM Enrico Olivelli <
> eolive...@gmail.com>
> > > >> wrote:
> > > >>>
> > > Il giorno mer 4 mar 2020 alle ore 17:23 Patrick Hunt
> > > ha scritto:
> > > >
> > > > It seems like we should have a stated/communicated policy around
> > > >> release
>
[ANNOUNCE] New ZooKeeper committer: Mate Szalay-Beko
The Apache ZooKeeper PMC recently extended committer karma to Mate and he has accepted. Mate has made some great contributions (including C client!) and we are looking forward to even more. :) Congratulations and welcome aboard, Mate!
