zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Hunt <ph...@apache.org>
Subject Re: Zookeeper with SSL release date
Date Thu, 17 Mar 2016 05:56:50 GMT
On Wed, Mar 16, 2016 at 10:24 PM, Alexander Shraer <shralex@gmail.com> 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 <jbr@squareup.com> 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 <phunt@apache.org> 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 <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