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, 24 Mar 2016 19:37:35 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message