I think these orthogonal concerns. Why limit reconfig to ACL users only? On Thu, Mar 31, 2016 at 11:37 PM, Alexander Shraer <[email protected]> wrote:
> Citing Patrick: > > > If you're running zk w/o security turned on and suddenly folks can do > reconfig > > operations it's going to potentially be a problem. > ... > > Rather than force people to turn on kerberos (etc...) we could instead > > have the feature off > > From this I understood that the concern is mostly about users that DON'T > use ACLs. My proposal is to disable > reconfig/getconfig for all such users, forcing users who want reconfig to > also use ACLs. Users who do use ACLs > don't have to use reconfig and will have to set the ACLs on the config > znode before they can use it. > > In preprequestprocessor where acls are checked for reconfig operation we > can check that: > > skipACL = false && nodeRecord.acl != null && nodeRecord.acl.size() != 0 > > meaning you're using ACLs, and have actually set ACLs on the config node. > > For getConfig its a bit trickier since its just a getData on the server > side (for efficiency > of reads, we avoided checking whether path == config znode). What we could > do is before sending > the operation to the server check skipACL = false and maybe also issue a > getACL call to check that > nodeRecord.acl != null && nodeRecord.acl.size() != 0 > and only then issue a getData. This part is not air tight but its probably > sufficient. > > And of course we can emphasize the need for ACLs on this znode in the > release. > > > On Thu, Mar 31, 2016 at 1:11 PM, Flavio Junqueira <[email protected]> wrote: > > > I think Jason is saying that this is orthogonal in the following sense. > > You set ACLs because you care about authentication/authorization in your > > cluster, but you may not want reconfig enabled, it just happened that you > > wanted to use ACLs. > > > > Perhaps you can elaborate a bit on how you think we can perform this ACL > > check? What would you check precisely? > > > > -Flavio > > > > > On 24 Mar 2016, at 21:19, Alexander Shraer <[email protected]> wrote: > > > > > > I'm not so sure its orthogonal. The question is whether someone would > > ever > > > want to use reconfig without ACLs, > > > as this allows any client to reconfigure the servers away or add a > bunch > > of > > > servers that shouldn't be there :) and whether we should facilitate > this > > > knowing its insecure. > > > > > > Requiring ACLs solves the security concern for both reconfig and > > getconfig. > > > For example, if you don't want your clients to know the list of > servers, > > > limit their read permissions on the configuration znode. > > > > > > On Thu, Mar 24, 2016 at 2:11 PM, Jason Rosenberg <[email protected]> > > wrote: > > > > > >> seems like an orthogonal requirement? > > >> > > >> On Thu, Mar 24, 2016 at 3:37 PM, Alexander Shraer <[email protected]> > > >> wrote: > > >> > > >>> How about a simpler alternative to the proposed flag for reconfig: a > > >> check > > >>> in the code that requires ACLs to be set. > > >>> If people want to use reconfig, they should use ACLs too. > > >>> > > >>> What do you think ? > > >>> > > >>> Alex > > >>> > > >>> On Mon, Mar 21, 2016 at 9:58 PM, Patrick Hunt <[email protected]> > > wrote: > > >>> > > >>>> I would say if in doubt add a safety. (a config parameter to turn it > > >>>> off). Cost is almost zero and worst case it will just give us peace > of > > >>>> mind. ;-) > > >>>> > > >>>> Patrick > > >>>> > > >>>> On Mon, Mar 21, 2016 at 9:41 PM, Alexander Shraer < > [email protected]> > > >>>> wrote: > > >>>>> ok, thanks for the suggestion, I'll look into it. For reconfig I > > >> think > > >>>> its > > >>>>> pretty clear that its an admin > > >>>>> functionality. I just always imagined that its controlled via acls, > > >>> but I > > >>>>> understand > > >>>>> the concerns now. > > >>>>> > > >>>>> getConfig returns the dynamic config (list of all servers with all > > >>> ports > > >>>>> and quorum system if defined) > > >>>>> and has an option to filter that info and just return the server > > >>>> connection > > >>>>> string (server and client port only). > > >>>>> > > >>>>> > > >>>>> On Mon, Mar 21, 2016 at 9:32 PM, Patrick Hunt <[email protected]> > > >>> wrote: > > >>>>> > > >>>>>> On Mon, Mar 21, 2016 at 9:14 PM, Alexander Shraer < > > >> [email protected]> > > >>>>>> wrote: > > >>>>>>> I don't think that getConfig should be an admin functionality. It > > >> is > > >>>>>>> essential for client-side re-balancing > > >>>>>>> that we implemented (all clients shoudl be able to detect > > >>>> configuration > > >>>>>>> changes via getConfig). It could > > >>>>>>> be hidden somewhat by defining higher-level re-balancing > > >>>>>>> policies (ZOOKEEPER-2016) > > >>>>>>> but there hasn't been enough progress on that. Perhaps instead > > >>>> getConfig > > >>>>>>> should be controlled > > >>>>>>> by a separate flag ? > > >>>>>>> > > >>>>>> > > >>>>>> I believe that the Hadoop community has something we could use: > > >>>>>> > > >>>>>> > > >>>> > > >>> > > >> > > > https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-common/InterfaceClassification.html > > >>>>>> (whether through annotations or just documenting it in the API > > >>> javadoc) > > >>>>>> > > >>>>>> e.g. we could list getConfig as public/unstable for example and > > >> still > > >>>>>> ship it as GA. That would mark it as something that could change > re > > >>>>>> API policy. > > >>>>>> > > >>>>>> Is the entire config exposed through getConfig? If so then we > might > > >>>>>> want to enable/disable it with a flag similar to reconfig. Might > be > > >>>>>> safer to just do that if we're not sure. > > >>>>>> > > >>>>>> > > >>>>>> Re classification - we could do the same thing with reconfig, but > I > > >>>>>> think that would be a mistake. If we feel strongly where it should > > >>>>>> live long term we should just move it now. > > >>>>>> > > >>>>>> Patrick > > >>>>>> > > >>>>>>> > > >>>>>>> On Mon, Mar 21, 2016 at 9:04 PM, Patrick Hunt <[email protected]> > > >>>> wrote: > > >>>>>>> > > >>>>>>>> On Mon, Mar 21, 2016 at 8:52 PM, Alexander Shraer < > > >>> [email protected] > > >>>>> > > >>>>>>>> wrote: > > >>>>>>>>> Hi Patrick, Flavio, > > >>>>>>>>> > > >>>>>>>>> Since there seems to be consensus on this, I can add this flag, > > >>>> unless > > >>>>>>>>> someone else wants to. I assume that getConfig should still > > >> work > > >>>>>>>> regardless > > >>>>>>>>> of the flag ? is there a security concern with clients knowing > > >>> the > > >>>>>> list > > >>>>>>>> of > > >>>>>>>>> servers? > > >>>>>>>>> > > >>>>>>>> > > >>>>>>>> We've always hidden that detail from users. We don't even expose > > >>>> which > > >>>>>>>> server you're connected to today. I remember Ben (and perhaps > > >>>> Flavio?) > > >>>>>>>> highlighting this as important to maintain although I'm not > super > > >>>>>>>> familiar with the specifics on why. It made sense to me though > > >> from > > >>>>>>>> the perspective that we don't want clients to make assumptions > > >> that > > >>>>>>>> probably shouldn't. > > >>>>>>>> > > >>>>>>>> My thinking is that we should 1) add a config option to enable > > >>>>>>>> reconfig (off by default), 2) move reconfig specific > > >> functionality > > >>>>>>>> from ZooKeeper.java (including getconfig) into an "admin" > > >> package, > > >>>>>>>> within say a class ZooKeeperAdmin, 3) document/test use of ACLs > > >> for > > >>>>>>>> when folks do want to enable reconfig and are also worried about > > >>>> auth. > > >>>>>>>> (e.g. turn on kerb) > > >>>>>>>> > > >>>>>>>> Again, I don't see any of this as a quality issue personally. As > > >>> such > > >>>>>>>> I don't see why any of this (1-3) should hold up a 3.5.2-alpha > if > > >>> we > > >>>>>>>> were interested in doing such a release. Adjusting the API > should > > >>> be > > >>>>>>>> done before we move to "beta" though. Although that seems like a > > >>>>>>>> pretty mechanical (eclipse/idea) type refactoring? > > >>>>>>>> > > >>>>>>>> Patrick > > >>>>>>>> > > >>>>>>>>> Cheers, > > >>>>>>>>> Alex > > >>>>>>>>> On Mar 21, 2016 8:34 PM, "Patrick Hunt" <[email protected]> > > >>> wrote: > > >>>>>>>>> > > >>>>>>>>>> On Thu, Mar 17, 2016 at 4:08 PM, Flavio Junqueira < > > >>> [email protected] > > >>>>> > > >>>>>>>> wrote: > > >>>>>>>>>>> I gotta say that I'm not super excited about this option, > > >> but > > >>>> for > > >>>>>> some > > >>>>>>>>>> reason I ended up carrying the flag. To recap, I just raised > > >>> this > > >>>>>> option > > >>>>>>>>>> because it seems that there are folks interested in features > > >> in > > >>>> 3.5 > > >>>>>> like > > >>>>>>>>>> SSL and not necessarily in reconfiguration. SSL is important > > >> and > > >>>> to > > >>>>>> take > > >>>>>>>>>> Kafka as an example, it sucks that we can't have a whole set > > >> up > > >>>> using > > >>>>>>>> SSL. > > >>>>>>>>>> For ZK, the real questions are: > > >>>>>>>>>>> > > >>>>>>>>>>> 1- how fast can we make 3.5 stable? > > >>>>>>>>>>> 2- would it be faster if we have a way of disabling > > >>>>>> reconfiguration? > > >>>>>>>>>>> 3- would enough users care about a stable 3.5 that has > > >>>>>> reconfiguration > > >>>>>>>>>> disabled? > > >>>>>>>>>>> > > >>>>>>>>>>> It is taking a long time to get 3.5 to beta. There has been > > >>> some > > >>>>>> good > > >>>>>>>>>> activity around 3.5.2 release, which is a great step, but it > > >> is > > >>>>>> unclear > > >>>>>>>>>> when 3.5.3 is going to come and if we will be able to make 3.5 > > >>>> beta > > >>>>>>>> then. > > >>>>>>>>>> Frankly, disabling reconfiguration sounds undesirable because > > >> it > > >>>> is > > >>>>>> an > > >>>>>>>>>> important feature, but I currently don't use it in production, > > >>> so > > >>>>>> from a > > >>>>>>>>>> practical point of view, I can go both ways. Whether we go > > >>> through > > >>>>>> the > > >>>>>>>>>> trouble of doing 2 depends on users interested in that option > > >>> and > > >>>>>> folks > > >>>>>>>>>> willing to implement it. > > >>>>>>>>>>> > > >>>>>>>>>>> To answer your question, Powell, my pseudo-proposal is kind > > >>> of a > > >>>>>> funny > > >>>>>>>>>> option because once the feature is stable, then we wouldn't > > >>> need a > > >>>>>>>> switch > > >>>>>>>>>> any longer, so there is not need of a deprecation path, we > > >> just > > >>>> start > > >>>>>>>>>> ignoring it from the first beta release. Until it is beta, I'd > > >>> say > > >>>>>> that > > >>>>>>>>>> default is disabled. > > >>>>>>>>>> > > >>>>>>>>>> I would argue that we need this even when it does become > > >> stable. > > >>>> To > > >>>>>> me > > >>>>>>>>>> this is not a quality issue so much as it is an auth issue. We > > >>>> want > > >>>>>> to > > >>>>>>>>>> make it simple for folks to run a vanilla/old ZK cluster and > > >> not > > >>>>>> worry > > >>>>>>>>>> about the security implications of having reconfig enabled. > > >>>>>>>>>> > > >>>>>>>>>> Patrick > > >>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> -Flavio > > >>>>>>>>>>> > > >>>>>>>>>>>> On 17 Mar 2016, at 17:44, powell molleti > > >>>>>> <[email protected] > > >>>>>>>>> > > >>>>>>>>>> wrote: > > >>>>>>>>>>>> > > >>>>>>>>>>>> Hi Flavio, > > >>>>>>>>>>>> > > >>>>>>>>>>>> Generally do config options and command line args come > > >> under > > >>>> the > > >>>>>> same > > >>>>>>>>>> SLA as API?. I was assuming as such hence my question. Perhaps > > >>> if > > >>>> the > > >>>>>>>>>> expectation is that this config option is temporary from get > > >> go > > >>>> then > > >>>>>>>> may be > > >>>>>>>>>> it is ok. The default for re-config support will be enabled or > > >>>>>>>> disabled?. > > >>>>>>>>>>>> > > >>>>>>>>>>>> I am just thinking from provisioning point of view when > > >>> people > > >>>>>>>> generate > > >>>>>>>>>> config options etc. > > >>>>>>>>>>>> > > >>>>>>>>>>>> Thanks > > >>>>>>>>>>>> Powell. > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> On Thursday, March 17, 2016 12:12 AM, Flavio Junqueira < > > >>>>>>>> [email protected]> > > >>>>>>>>>> wrote: > > >>>>>>>>>>>> Hi Powell, > > >>>>>>>>>>>> > > >>>>>>>>>>>> I was thinking config file and system property server side. > > >>>> What's > > >>>>>>>> your > > >>>>>>>>>> concern with compatibility? The API itself wouldn't change, > > >> but > > >>>> the > > >>>>>>>> config > > >>>>>>>>>> option wouldn't exist in previous versions and would not exist > > >>>>>> either in > > >>>>>>>>>> later stable versions of 3.5. > > >>>>>>>>>>>> > > >>>>>>>>>>>> -Flavio > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>>> On 16 Mar 2016, at 22:08, 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. > > >>>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>> > > >>>>>> > > >>>> > > >>> > > >> > > > > >
