+1 to Powell's point: if you could share out a list of the issues perhaps some of us can take the more straightforward or mechanical ones to get closer to 3.5.
Regards, Irfan. On Wed, Mar 16, 2016 at 3:08 PM, powell molleti <[email protected] > wrote: > Will this option be supplied via config file/args/API?. Will this option > be a temporary thing i.e what about its compatibility?. > > thanks > Powell. > > > > On Wednesday, March 16, 2016 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. > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>> > >>>> > >>> > >> >
