zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Shraer <shra...@gmail.com>
Subject Re: Zookeeper with SSL release date
Date Thu, 17 Mar 2016 05:24:25 GMT
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.


Alex


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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message