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. >> > >>>>>>>>>>> >> > >>>>>>>>>> >> > >>>>>>>>>> >> > >>>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>> >> > >>>>> >> > >>>> >> > >>> >> > > >> > >>
