zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Flavio Junqueira <...@apache.org>
Subject Re: Zookeeper with SSL release date
Date Thu, 31 Mar 2016 20:11:21 GMT
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 <shralex@gmail.com> 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 <jbr@squareup.com> wrote:
> 
>> seems like an orthogonal requirement?
>> 
>> On Thu, Mar 24, 2016 at 3:37 PM, Alexander Shraer <shralex@gmail.com>
>> 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 <phunt@apache.org> 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 <shralex@gmail.com>
>>>> 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 <phunt@apache.org>
>>> wrote:
>>>>> 
>>>>>> On Mon, Mar 21, 2016 at 9:14 PM, Alexander Shraer <
>> shralex@gmail.com>
>>>>>> 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 <phunt@apache.org>
>>>> wrote:
>>>>>>> 
>>>>>>>> On Mon, Mar 21, 2016 at 8:52 PM, Alexander Shraer <
>>> shralex@gmail.com
>>>>> 
>>>>>>>> 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" <phunt@apache.org>
>>> wrote:
>>>>>>>>> 
>>>>>>>>>> On Thu, Mar 17, 2016 at 4:08 PM, Flavio Junqueira <
>>> fpj@apache.org
>>>>> 
>>>>>>>> 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
>>>>>> <powellm79@yahoo.com.INVALID
>>>>>>>>> 
>>>>>>>>>> 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 <
>>>>>>>> fpj@apache.org>
>>>>>>>>>> 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
>>>>>>>> <powellm79@yahoo.com.INVALID>
>>>>>>>>>> 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 <
>>>>>>>> fpj@apache.org>
>>>>>>>>>> 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-eq6Q@mail.gmail.com%3E
>>>>>>>>>> <
>>>>>>>>>> 
>>>>>>>> 
>>>>>> 
>>>> 
>>> 
>> https://mail-archives.apache.org/mod_mbox/zookeeper-dev/201407.mbox/%3CCANLc_9KG6-Dhm=wwfuwzNioGK70pg+iHMHPigYfJDSLf9-eq6Q@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 <
>>>> shralex@gmail.com>
>>>>>>>> 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 <
>>>>>>>> fpj@apache.org>
>>>>>>>>>> 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" <
>> jbr@squareup.com
>>>> 
>>>>>> 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 <
>>>>>>>> fpj@apache.org>
>>>>>>>>>>>>>>> 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 <
>>>> jbr@squareup.com
>>>>>>> 
>>>>>>>>>> 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
>>>>>>>>>>>>>>>>> <powellm79@yahoo.com.invalid
>>>>>>>>>>>>>>>>>>> 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 <
>>>>>>>>>>>>>>>>> fpj@apache.org>
>>>>>>>>>>>>>>>>>>> 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 <
>>>>>>>>>> cnauroth@hortonworks.com>
>>>>>>>>>>>>>>>>>>> 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" <
>>>> jbr@squareup.com
>>>>>>> 
>>>>>>>>>> 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 <
>>>>>>>>>>>>>>>>>>> cnauroth@hortonworks.com>
>>>>>>>>>>>>>>>>>>>>> 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" <itsbehind@gmail.com
>>> 
>>>>>> 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.
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>> 
>>>>>> 
>>>> 
>>> 
>> 


Mime
View raw message