I was thinking server side actually. If the switch is off, any attempt to reconfig is a no-op and the server would log a warning. If you we want to propagate the error up, then yeah, we need to start worrying about compatibility and such.
I also would rather see us address it, although I can fully understand that there are other fixes and improvements in 3.5 that people are interested in. -Flavio > On 17 Mar 2016, at 00:46, 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. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>> >>>> >>
