ps. here's my jira dashboard, it tracks both 3.4 and 3.5 activity/status and gives some insight on progress on each: https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12327688 granted it only shows the current "in progress" releases (3.4.9/3.5.2)
Patrick On Wed, Mar 16, 2016 at 10:56 PM, Patrick Hunt <[email protected]> wrote: > On Wed, Mar 16, 2016 at 10:24 PM, Alexander Shraer <[email protected]> wrote: >> Here is a link for bugs marked as 3.5.2: >> https://issues.apache.org/jira/browse/ZOOKEEPER/fixforversion/12331981/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-issues-panel >> >> The API issue Flavio mentioned is >> https://issues.apache.org/jira/browse/ZOOKEEPER-2014 personally I don't >> think this issue >> is significant enough to block the release, but I may be wrong. ZooKeeper >> supports ACLs and these can be used to solve the >> issue described in the JIRA, at least until a better solution is in place. >> > > I think the linked jira does a good job of covering the concerns > expressed by multiple folks. Granted I may be more sensitive to the > issues as I deal with enterprise users generally. > > Patrick > >> >> >> On Wed, Mar 16, 2016 at 9:33 PM, Jason Rosenberg <[email protected]> wrote: >> >>> Forgive me, as I have not long been an active member of the zookeeper >>> community (other than as a grateful user over the last 3 years or so). >>> >>> If I understand correclty, 3.5.X has been alpha for several years or so >>> now? I think if there isn't a plan to have a stable release soon (say >>> within another year), it's a problem. It should be about having a regular >>> release cycle, with the hope that new features and bug fixes become >>> available in a reasonable time. If one feature is just not stable, then it >>> shouldn't block other features, etc. Saying a feature is a major part of >>> 3.5, doesn't quite make sense in this formulation. Instead releases >>> incorporate features, and if features get delayed, they can be postponed to >>> a subsequent release. >>> >>> The issue is that we have people saying they don't want to fix things in >>> 3.4.X (or back port fixes from 3.5.X to 3.4.X). But if 3.5.X is still >>> literally still years away (after having been under development for years), >>> we should re-evaluate, no? >>> >>> Jason >>> >>> On Wed, Mar 16, 2016 at 8:46 PM, Patrick Hunt <[email protected]> wrote: >>> >>> > I'm not a huge fan of turning it off to be honest. Also just turning >>> > it off at the API level wouldn't be enough, we'd need to turn it off >>> > at the protocol level (otw it could still be accessed). >>> > >>> > I'd rather see us address it than kick it down the road. It's a major >>> > feature of 3.5. >>> > >>> > Patrick >>> > >>> > On Wed, Mar 16, 2016 at 2:46 PM, Flavio Junqueira <[email protected]> >>> wrote: >>> > > The main issue to sort out is stability of the API. There is a security >>> > concern around the fact that clients can freely reconfigure the ensemble. >>> > If we follow the plan that Pat proposed some time ago: >>> > > >>> > > >>> > >>> https://mail-archives.apache.org/mod_mbox/zookeeper-dev/201407.mbox/%3CCANLc_9KG6-Dhm=wwfuwzniogk70pg+ihmhpigyfjdslf9-e...@mail.gmail.com%3E >>> > < >>> > >>> https://mail-archives.apache.org/mod_mbox/zookeeper-dev/201407.mbox/%3CCANLc_9KG6-Dhm=wwfuwzniogk70pg+ihmhpigyfjdslf9-e...@mail.gmail.com%3E >>> > > >>> > > >>> > > Locking the API is the main step to move it to beta. Sorting out bugs >>> is >>> > definitely necessary, but it isn't the main thing that is keeping 3.5 in >>> > alpha. >>> > > >>> > > About making it experimental, I was raising the option of having a >>> > switch that disables the API calls, not the code. The reason why that >>> could >>> > work is that anyone using 3.5 who uses the "experimental" API must >>> explicit >>> > turn on the switch and enable the calls. If they do it, they need to be >>> > aware that the API can change. >>> > > >>> > > I must say that I haven't really looked closely into doing it, and I'm >>> > not even entirely convinced that this is a good idea, but since Jason >>> > raised the point, I'm exploring options. >>> > > >>> > > -Flavio >>> > > >>> > >> On 16 Mar 2016, at 20:59, Alexander Shraer <[email protected]> wrote: >>> > >> >>> > >> Looking at the list of ~50 blocker and critical bugs in ZooKeeper, >>> only >>> > 3-4 >>> > >> are related to reconfig. Given this, and the fact that it is run in >>> > >> production since 2012 in multiple companies, I don't think its more >>> > >> unstable than any other part of ZooKeeper. >>> > >> >>> > >> There are multiple reconfig-related bugs that turned out really >>> > difficult >>> > >> to debug without access to the actual system or at least to the Hudson >>> > >> machines where some tests are failing. In the past, Michi and I >>> > physically >>> > >> went to Hortonworks to debug one such issue, but this is of course >>> not a >>> > >> good method, and we weren't able to arrange such a visit again. >>> > >> >>> > >> Regarding making it optional - the reconfig logic has several >>> different >>> > >> parts, some would be really difficult to disable using a configuration >>> > >> parameter. But the actual dynamic expansion of the cluster is >>> triggered >>> > by >>> > >> the reconfig command, so it should not affect users who don't invoke >>> it. >>> > >> >>> > >> On Wed, Mar 16, 2016 at 1:09 PM, Flavio P JUNQUEIRA <[email protected]> >>> > wrote: >>> > >> >>> > >>> I suppose we could give it a try. How do other folks feel about it? >>> > >>> >>> > >>> -Flavio >>> > >>> On 16 Mar 2016 19:52, "Jason Rosenberg" <[email protected]> wrote: >>> > >>> >>> > >>>> So, you could enable the dynamic reconfiguration feature behind a >>> > config >>> > >>>> option, and document that it should only be enabled experimentally, >>> > use >>> > >>> at >>> > >>>> your own risk. Keep it off by default. Allow only static config by >>> > >>>> default, until it's stable? >>> > >>>> >>> > >>>> Jason >>> > >>>> >>> > >>>> On Wed, Mar 16, 2016 at 3:34 PM, Flavio Junqueira <[email protected]> >>> > >>> wrote: >>> > >>>> >>> > >>>>> Hi Jason, >>> > >>>>> >>> > >>>>> The consumer in Kafka is pretty independent from the core >>> (brokers), >>> > >>>>> that's how that project manages to make such a separation. We don't >>> > >>> have >>> > >>>>> the same with ZooKeeper as the feature we are talking about is part >>> > of >>> > >>>> the >>> > >>>>> server and the only way I see of doing what you say is to turn off >>> > >>>>> features. More specifically, we'd need to disable the reconfig API >>> > and >>> > >>> do >>> > >>>>> not allow any change to the configuration, even though the code is >>> > >>> there. >>> > >>>>> >>> > >>>>> Reconfig here refers to the ability of changing the configuration >>> of >>> > an >>> > >>>>> ensemble (e.g., changing the set of servers). >>> > >>>>> >>> > >>>>> -Flavio >>> > >>>>> >>> > >>>>>> On 16 Mar 2016, at 19:14, Jason Rosenberg <[email protected]> >>> wrote: >>> > >>>>>> >>> > >>>>>> So, it would seem sensible to me to have a release where all >>> > features >>> > >>>> are >>> > >>>>>> stable, except where noted. E.g. mark certain features as only >>> > >>> 'alpha >>> > >>>>>> quality', e.g. the 're-config feature'. (I assume it's possible >>> to >>> > >>>>> happily >>> > >>>>>> use 3.5.X without exercising the unstable re-config bits?). >>> > >>>>>> >>> > >>>>>> There's precedent for doing this sort of thing in other projects, >>> > >>> e.g. >>> > >>>> in >>> > >>>>>> Kafka, they've had several release where a new "Consumer API" is >>> > >>>> shipped >>> > >>>>>> that is available for beta-testing, but you can still just use the >>> > >>>> older >>> > >>>>>> stable consumer api, etc. >>> > >>>>>> >>> > >>>>>> Jason >>> > >>>>>> >>> > >>>>>> On Wed, Mar 16, 2016 at 2:01 PM, powell molleti >>> > >>>>> <[email protected] >>> > >>>>>>> wrote: >>> > >>>>>> >>> > >>>>>>> Hi Doug, >>> > >>>>>>> Is 3.5 being an alpha release preventing you from using it?. Or >>> > have >>> > >>>> you >>> > >>>>>>> run into issues with it?. In general perhaps ZK 3.5 being labeled >>> > as >>> > >>>>> alpha >>> > >>>>>>> might not be fair, since it is far more stable then what most >>> > people >>> > >>>>>>> associate an alpha release to be. >>> > >>>>>>> Perhaps if you do not use re-config feature may be it will just >>> > work >>> > >>>> for >>> > >>>>>>> you?. >>> > >>>>>>> There are many examples of 3.5.X being used in productions from >>> my >>> > >>>>> limited >>> > >>>>>>> knowledge. >>> > >>>>>>> ThanksPowell. >>> > >>>>>>> >>> > >>>>>>> On Wednesday, March 16, 2016 2:44 AM, Flavio Junqueira < >>> > >>>>> [email protected]> >>> > >>>>>>> wrote: >>> > >>>>>>> >>> > >>>>>>> >>> > >>>>>>> None of us expected the reconfig changes to take this long to >>> > >>>> stabilize. >>> > >>>>>>> Until we get there, I don't think we can do anything else with >>> 3.5. >>> > >>>> The >>> > >>>>>>> best bet we have is to work harder to bring 3.5 into a stable >>> > rather >>> > >>>>> than >>> > >>>>>>> trying to work around it. >>> > >>>>>>> >>> > >>>>>>> There are lots of people interested in seeing 3.5 stable, and if >>> we >>> > >>>> get >>> > >>>>>>> everyone to contribute more patches and code reviews, we should >>> be >>> > >>>> able >>> > >>>>> to >>> > >>>>>>> do it sooner. After all, it is a community based effort, so the >>> > >>>>> community >>> > >>>>>>> shouldn't rely on just 2-3 people doing the work. >>> > >>>>>>> >>> > >>>>>>> -Flavio >>> > >>>>>>> >>> > >>>>>>>> On 15 Mar 2016, at 17:28, Chris Nauroth < >>> [email protected] >>> > > >>> > >>>>>>> wrote: >>> > >>>>>>>> >>> > >>>>>>>> Doug, I forgot to respond to your question about 3.4. Since 3.4 >>> > is >>> > >>>> the >>> > >>>>>>>> stable maintenance line, we are very conservative about >>> > >>> back-porting >>> > >>>> to >>> > >>>>>>>> it. Our policy is to limit back-ports to critical bug fixes and >>> > >>> not >>> > >>>>>>>> introduce any new features in the 3.4 line. This is a matter of >>> > >>>>> managing >>> > >>>>>>>> risk. >>> > >>>>>>>> >>> > >>>>>>>> Jason, your question about release cadence is a fair one. If >>> it's >>> > >>>> any >>> > >>>>>>>> consolation, we are now taking the approach of trying to limit >>> the >>> > >>>>> scope >>> > >>>>>>>> of anything new introduced in 3.5 too. That would allow us to >>> > >>> focus >>> > >>>> on >>> > >>>>>>>> stabilization: resolving blocker bugs and freezing public >>> APIs. I >>> > >>>>> think >>> > >>>>>>>> this will help us accelerate the releases into beta and eventual >>> > >>> GA. >>> > >>>>>>>> >>> > >>>>>>>> I am new to ZooKeeper release management, so I'd like to hear >>> > >>>> thoughts >>> > >>>>>>>> from more experienced committers and PMC members about your >>> > >>> proposal >>> > >>>> to >>> > >>>>>>>> try to cut a stable release for a limited subset of what is in >>> > >>>>> branch-3.5 >>> > >>>>>>>> now. My instinct is that it would be challenging to cherry-pick >>> > >>> out >>> > >>>>>>>> pieces of branch-3.5 piecemeal at this point. This would become >>> > >>>>> another >>> > >>>>>>>> release line for an already resource-constrained volunteer staff >>> > to >>> > >>>>>>>> manage. I'd prefer to dedicate those limited resources to >>> overall >>> > >>>> 3.5 >>> > >>>>>>>> stabilization. Also, a 3.5 release in which certain features >>> > >>>>> "vanished" >>> > >>>>>>>> because of not meeting some stability criteria would be >>> > >>> undesirable. >>> > >>>>>>>> >>> > >>>>>>>> --Chris Nauroth >>> > >>>>>>>> >>> > >>>>>>>> >>> > >>>>>>>> >>> > >>>>>>>> >>> > >>>>>>>> On 3/15/16, 10:12 AM, "Jason Rosenberg" <[email protected]> >>> wrote: >>> > >>>>>>>> >>> > >>>>>>>>> Chris, >>> > >>>>>>>>> >>> > >>>>>>>>> Can you say whether some parts of 3.5.X are more stable than >>> > >>> others >>> > >>>>>>> (e.g. >>> > >>>>>>>>> if we don't care about certain new features, is it relatively >>> > >>>> stable)? >>> > >>>>>>>>> Would it be possible to cut out a version that only has the >>> bits >>> > >>> we >>> > >>>>>>> think >>> > >>>>>>>>> are stable (and release that)? >>> > >>>>>>>>> >>> > >>>>>>>>> From that timeline, and the historic release cadence, it would >>> > >>> seem >>> > >>>> to >>> > >>>>>>> be >>> > >>>>>>>>> a >>> > >>>>>>>>> years away before we get to the stable release? >>> > >>>>>>>>> >>> > >>>>>>>>> Thanks, >>> > >>>>>>>>> >>> > >>>>>>>>> Jason >>> > >>>>>>>>> >>> > >>>>>>>>> On Tue, Mar 15, 2016 at 1:06 PM, Chris Nauroth < >>> > >>>>>>> [email protected]> >>> > >>>>>>>>> wrote: >>> > >>>>>>>>> >>> > >>>>>>>>>> Hello Doug, >>> > >>>>>>>>>> >>> > >>>>>>>>>> Thanks for your interest in the SSL feature! >>> > >>>>>>>>>> >>> > >>>>>>>>>> At this point, I think we're still pretty far away from >>> > >>> declaring a >>> > >>>>>>>>>> stable >>> > >>>>>>>>>> release in the 3.5 line. I don't think we're close enough >>> that >>> > >>>>> anyone >>> > >>>>>>>>>> can >>> > >>>>>>>>>> offer a reliable ETA. This is an earlier thread that >>> describes >>> > >>> the >>> > >>>>>>>>>> high-level strategy for release planning in the 3.5 line: >>> > >>>>>>>>>> >>> > >>>>>>>>>> https://s.apache.org/ADK1 >>> > >>>>>>>>>> >>> > >>>>>>>>>> The next step is a 3.5.2-alpha release. We're working on >>> > >>>> resolving a >>> > >>>>>>>>>> few >>> > >>>>>>>>>> more blockers before we produce a release candidate. >>> Hopefully >>> > >>>> that >>> > >>>>>>>>>> will >>> > >>>>>>>>>> get done in the next few weeks. >>> > >>>>>>>>>> >>> > >>>>>>>>>> --Chris Nauroth >>> > >>>>>>>>>> >>> > >>>>>>>>>> >>> > >>>>>>>>>> >>> > >>>>>>>>>> >>> > >>>>>>>>>> On 3/15/16, 9:39 AM, "Doug" <[email protected]> wrote: >>> > >>>>>>>>>> >>> > >>>>>>>>>>> I know it's only been a few months, but I was wondering if >>> > there >>> > >>>>> was a >>> > >>>>>>>>>>> ballpark release date for a stable version of 3.5.1. Or is >>> > there >>> > >>>> any >>> > >>>>>>>>>>> chance >>> > >>>>>>>>>>> the SSL feature would be added to 3.4.8? Just another person >>> > >>>> looking >>> > >>>>>>> to >>> > >>>>>>>>>>> have >>> > >>>>>>>>>>> that feature in a stable version. Thanks for all you do! :) >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> -- >>> > >>>>>>>>>>> View this message in context: >>> > >>>>>>>>>>> >>> > >>>>>>>>>> >>> > >>>>>>>>>> >>> > >>>>>>> >>> > >>>>> >>> > >>>> >>> > >>> >>> > >>> http://zookeeper-user.578899.n2.nabble.com/Zookeeper-with-SSL-release-dat >>> > >>>>>>>>>> e >>> > >>>>>>>>>>> -tp7581744p7582136.html >>> > >>>>>>>>>>> Sent from the zookeeper-user mailing list archive at >>> > Nabble.com. >>> > >>>>>>>>>>> >>> > >>>>>>>>>> >>> > >>>>>>>>>> >>> > >>>>>>>> >>> > >>>>>>> >>> > >>>>>>> >>> > >>>>>>> >>> > >>>>>>> >>> > >>>>> >>> > >>>>> >>> > >>>> >>> > >>> >>> > > >>> > >>>
