On Tue, Jul 22, 2014 at 11:29 AM, Alexander Shraer <shra...@gmail.com> wrote:
> Hmm. It doesn't really make sense to me - the reconfig should be completed
> before
> the servers come up and process new ops. We submitted the reconfig to
> server 1, it timed out
> on new quorum, but when 1 becomes leader again after 2 restarts 1 should
> complete the reconfig.
> is 1 becoming leader after 2 restarts ?
>
What should I look for in the logs? Any specific log messages that
would help debug?
> About admin controls - reconfig/getConfig are open to everyone, unless you
> set permissions on the configuration znode being written during reconfig.
> nodeRecord = getRecordForPath(ZooDefs.CONFIG_NODE);
>
> checkACL(zks, nodeRecord.acl, ZooDefs.Perms.WRITE,
> request.authInfo);
>
So I can turn off all access then? (read and write). Should we ship
that as the default? We should add that to the docs.
In the past we've always tried to hide this type of information from
clients (e.g. we don't expose the zk server address to the client for
a session). This seems like a very big departure. Why didn't we move
it to a separate, administrative, interface?
Patrick
>
>
> On Tue, Jul 22, 2014 at 11:16 AM, Patrick Hunt <phu...@gmail.com> wrote:
>
>> Looks like 3 hasn't been removed (unfortunately the assertion doesn't
>> include any msg detail, but that's the way it looks to me like the
>> test is setup):
>>
>> if (leavingServers != null) {
>> for (String leaving : leavingServers)
>>
>> Assert.assertFalse(configStr.contains("server.".concat(leaving)));
>> }
>>
>> which is called from:
>>
>> qu.restart(2);
>> // Now that 2 is back up, they'll complete the reconfig removing 3
>> and
>> // can process other ops.
>> testServerHasConfig(zkArr[1], null, leavingServers);
>>
>> It seems like the problem is that testServerHasConfig is not waiting
>> for the configuration to be updated? In this case 2 was just restarted
>> and 3 hasn't had a chance to be removed? (on a slower machine say,
>> which might be why you aren't seeing the issue? hence the flakeyness)
>>
>> Patrick
>>
>> On Tue, Jul 22, 2014 at 10:57 AM, Alexander Shraer <shra...@gmail.com>
>> wrote:
>> > Hi Patrick, I'm not sure why you're seeing this - it consistently passes
>> on
>> > my machine. In case you'd like to take a look, the test has tons of
>> > comments explaining the scenario. Let me know how I can help.
>> >
>> >
>> > On Tue, Jul 22, 2014 at 9:53 AM, Patrick Hunt <ph...@apache.org> wrote:
>> >
>> >> Hi Alex, I've also seen the test "testLeaderTimesoutOnNewQuorum" fail
>> >> multiple times (not every time, but ~50%, so flakey) in the last few
>> >> days. It's failing both on jdk6 and jdk7. (this is my personal
>> >> jenkins, I haven't see any other failures than this during the past
>> >> few days).
>> >>
>> >> junit.framework.AssertionFailedError
>> >> at
>> >>
>> org.apache.zookeeper.test.ReconfigTest.testServerHasConfig(ReconfigTest.java:127)
>> >> at
>> >>
>> org.apache.zookeeper.test.ReconfigTest.testLeaderTimesoutOnNewQuorum(ReconfigTest.java:450)
>> >> at
>> >>
>> org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:52)
>> >>
>> >> Patrick
>> >>
>> >> On Tue, Jul 22, 2014 at 8:37 AM, Alexander Shraer <shra...@gmail.com>
>> >> wrote:
>> >> > Hi Rakesh,
>> >> >
>> >> > Thanks for looking at this. In general even if we find the bug since
>> we
>> >> > should test it before committing a fix, it seems better to remove the
>> >> test
>> >> > for now and debug this on a build machine. I'm trying to get access to
>> >> it.
>> >> >
>> >> > Looking at this log:
>> >> >
>> >>
>> https://builds.apache.org/view/S-Z/view/ZooKeeper/job/ZooKeeper-trunk/2380/testReport/org.apache.zookeeper.server.quorum/ReconfigRecoveryTest/testCurrentObserverIsParticipantInNewConfig/
>> >> >
>> >> > Something weird is going on. Sever 3 hasn't started yet, but version
>> >> 200000000
>> >> > is already being sent around as committed!
>> >> >
>> >> > 2014-07-21 10:44:50,901 [myid:2] - INFO
>> >> >
>> [WorkerReceiver[myid=2]:FastLeaderElection$Messenger$WorkerReceiver@293]
>> >> > - 2 Received version: 200000000 my version: 0
>> >> >
>> >> >
>> >> > and also in leader election messages.
>> >> >
>> >> > Also weird is that the version of 2 is 0 as if it is a joiner,
>> whereas we
>> >> > explicitly started it with 100000000.
>> >> > Then it makes sense that the new config can't be committed since its
>> >> > version is not high enough...
>> >> >
>> >> > I wonder if its possible that not all servers from the previous test
>> are
>> >> > dead and they are interfering...
>> >> >
>> >> >
>> >> > On Tue, Jul 22, 2014 at 3:53 AM, Rakesh R <rake...@huawei.com> wrote:
>> >> >
>> >> >> Hi Alex,
>> >> >>
>> >> >> Yeah it is consistently passing in my machine also.
>> >> >>
>> >> >>
>> >> >> I have quickly gone through the
>> >> >> testCurrentObserverIsParticipantInNewConfig failure logs in
>> >> >> PreCommit-ZOOKEEPER-Build. It looks like 200000000 (n.config version)
>> >> has
>> >> >> not taken and still leader election is seeing 100000000 (n.config
>> >> version).
>> >> >> Unfortunately I didn't find the reason for not considering the
>> updated
>> >> >> config version.
>> >> >>
>> >> >>
>> >> >> Reference:
>> >> >>
>> >>
>> https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2213/testReport/junit/org.apache.zookeeper.server.quorum/ReconfigRecoveryTest/testCurrentObserverIsParticipantInNewConfig
>> >> >>
>> >> >> 2014-07-22 06:38:00,330 [myid:1] - INFO
>> >> >> [QuorumPeer[myid=1]/127.0.0.1:11298:FastLeaderElection@922] -
>> >> >> Notification time out: 51200
>> >> >> 2014-07-22 06:38:00,330 [myid:1] - INFO
>> >> >> [WorkerReceiver[myid=1]:FastLeaderElection@682] - Notification: 2
>> >> >> (message format version), 1 (n.leader), 0x100000005 (n.zxid), 0x1
>> >> >> (n.round), LOOKING (n.state), 1 (n.sid), 0x1 (n.peerEPoch), LOOKING
>> (my
>> >> >> state)100000000 (n.config version)
>> >> >> 2014-07-22 06:38:00,331 [myid:2] - INFO
>> >> >> [WorkerReceiver[myid=2]:FastLeaderElection@682] - Notification: 2
>> >> >> (message format version), 1 (n.leader), 0x100000005 (n.zxid), 0x1
>> >> >> (n.round), LOOKING (n.state), 2 (n.sid), 0x1 (n.peerEPoch), LOOKING
>> (my
>> >> >> state)100000000 (n.config version)
>> >> >> 2014-07-22 06:38:00,330 [myid:2] - INFO
>> >> >> [QuorumPeer[myid=2]/127.0.0.1:11301:FastLeaderElection@922] -
>> >> >> Notification time out: 51200
>> >> >> 2014-07-22 06:38:00,331 [myid:0] - INFO
>> >> >> [WorkerReceiver[myid=0]:FastLeaderElection@682] - Notification: 2
>> >> >> (message format version), 1 (n.leader), 0x100000005 (n.zxid), 0x1
>> >> >> (n.round), LOOKING (n.state), 1 (n.sid), 0x1 (n.peerEPoch), LOOKING
>> (my
>> >> >> state)100000000 (n.config version)
>> >> >> 2014-07-22 06:38:00,331 [myid:2] - INFO
>> >> >> [WorkerReceiver[myid=2]:FastLeaderElection@682] - Notification: 2
>> >> >> (message format version), 1 (n.leader), 0x100000005 (n.zxid), 0x1
>> >> >> (n.round), LOOKING (n.state), 1 (n.sid), 0x1 (n.peerEPoch), LOOKING
>> (my
>> >> >> state)100000000 (n.config version)
>> >> >>
>> >> >>
>> >> >> 2014-07-22 06:38:00,332 [myid:0] - INFO
>> >> >> [WorkerReceiver[myid=0]:FastLeaderElection@682] - Notification: 2
>> >> >> (message format version), 1 (n.leader), 0x100000005 (n.zxid), 0x1
>> >> >> (n.round), LOOKING (n.state), 2 (n.sid), 0x1 (n.peerEPoch), LOOKING
>> (my
>> >> >> state)100000000 (n.config version)
>> >> >> 2014-07-22 06:38:00,332 [myid:1] - INFO
>> >> >> [WorkerReceiver[myid=1]:FastLeaderElection@682] - Notification: 2
>> >> >> (message format version), 1 (n.leader), 0x100000005 (n.zxid), 0x1
>> >> >> (n.round), LOOKING (n.state), 2 (n.sid), 0x1 (n.peerEPoch), LOOKING
>> (my
>> >> >> state)100000000 (n.config version)
>> >> >>
>> >> >>
>> >> >> -Rakesh
>> >> >>
>> >> >> -----Original Message-----
>> >> >> From: Alexander Shraer [mailto:shra...@gmail.com]
>> >> >> Sent: 22 July 2014 11:57
>> >> >> To: dev@zookeeper.apache.org
>> >> >> Subject: Re: ZooKeeper 3.5.0-alpha planning
>> >> >>
>> >> >> I tried to look into it, but the test consistently passes locally on
>> two
>> >> >> machines.
>> >> >> I don't currently have access to the build machine, but I can try to
>> ask
>> >> >> for access.
>> >> >> Unless anyone has a better suggestion, we could remove the failing
>> test
>> >> in
>> >> >> the meanwhile and open a JIRA to add it back...
>> >> >>
>> >> >>
>> >> >> On Mon, Jul 21, 2014 at 10:09 PM, Patrick Hunt <ph...@apache.org>
>> >> wrote:
>> >> >>
>> >> >> > I'm seeing alot of test failures in
>> >> >> > testCurrentObserverIsParticipantInNewConfig could someone take a
>> look?
>> >> >> > Seems related to ZOOKEEPER-1807 recent commit.
>> >> >> >
>> >> >> >
>> >> >> >
>> >> https://issues.apache.org/jira/browse/ZOOKEEPER-1807?focusedCommentId=
>> >> >> >
>> 14069024&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-
>> >> >> > tabpanel#comment-14069024
>> >> >> >
>> >> >> > Patrick
>> >> >> >
>> >> >> > On Mon, Jul 21, 2014 at 11:12 AM, Rakesh Radhakrishnan
>> >> >> > <rakeshr.apa...@gmail.com> wrote:
>> >> >> > > lgtm +1
>> >> >> > >
>> >> >> > >
>> >> >> > > On Mon, Jul 21, 2014 at 11:37 PM, FPJ
>> >> >> > > <fpjunque...@yahoo.com.invalid>
>> >> >> > wrote:
>> >> >> > >
>> >> >> > >> +1 for having an RC this week. Since this is an alpha release, I
>> >> >> > >> +think
>> >> >> > 72
>> >> >> > >> biz hours is enough for the vote.
>> >> >> > >>
>> >> >> > >> -Flavio
>> >> >> > >>
>> >> >> > >> > -----Original Message-----
>> >> >> > >> > From: Patrick Hunt [mailto:ph...@apache.org]
>> >> >> > >> > Sent: 21 July 2014 18:55
>> >> >> > >> > To: DevZooKeeper
>> >> >> > >> > Subject: Re: ZooKeeper 3.5.0-alpha planning
>> >> >> > >> >
>> >> >> > >> > I fixed a number of issues. I also started a few threads with
>> >> >> > >> > builds@
>> >> >> > >> > - the ulimit issue is still outstanding. Hongchao and I worked
>> >> >> > through a
>> >> >> > >> > number of findbugs issues, it's not closed yet but it's pretty
>> >> >> close.
>> >> >> > >> >
>> >> >> > >> > I don't see why we can't create an RC and start voting this
>> week
>> >> >> > though.
>> >> >> > >> > Anyone disagree?
>> >> >> > >> >
>> >> >> > >> > How long should we let the vote run, the std 72 biz hours or
>> >> >> > >> > should we
>> >> >> > >> plan
>> >> >> > >> > for more to allow folks more time to test?
>> >> >> > >> >
>> >> >> > >> > Patrick
>> >> >> > >> >
>> >> >> > >> > On Mon, Jul 21, 2014 at 10:29 AM, Raúl Gutiérrez Segalés
>> >> >> > >> > <r...@itevenworks.net> wrote:
>> >> >> > >> > > On 18 July 2014 10:32, Patrick Hunt <ph...@apache.org>
>> wrote:
>> >> >> > >> > >
>> >> >> > >> > >> You may notice some back/forth on Apache Jenkins ZK jobs -
>> I'm
>> >> >> > trying
>> >> >> > >> > >> to fix some of the jobs that were broken during the recent
>> >> >> > >> > >> host upgrade.
>> >> >> > >> > >>
>> >> >> > >> > >
>> >> >> > >> > > How are things looking? Is it likely that we can have a
>> 3.5.0
>> >> >> > >> > > alpha release week or are we still blocked on Jenkins?
>> >> >> > >> > >
>> >> >> > >> > >
>> >> >> > >> > > -rgs
>> >> >> > >> > >
>> >> >> > >> > >
>> >> >> > >> > >
>> >> >> > >> > >
>> >> >> > >> > >
>> >> >> > >> > >
>> >> >> > >> > >> Patrick
>> >> >> > >> > >>
>> >> >> > >> > >> On Thu, Jul 17, 2014 at 1:47 PM, Michi Mutsuzaki
>> >> >> > >> > >> <mi...@cs.stanford.edu>
>> >> >> > >> > >> wrote:
>> >> >> > >> > >> > I'll check in ZOOKEEPER-1683.
>> >> >> > >> > >> >
>> >> >> > >> > >> > On Thu, Jul 17, 2014 at 11:20 AM, Alexander Shraer
>> >> >> > >> > >> > <shra...@gmail.com>
>> >> >> > >> > >> wrote:
>> >> >> > >> > >> >> can we also have ZOOKEEPER-1683 in ? Camille gave a +1
>> and
>> >> >> > >> > >> >> all
>> >> >> > >> > >> subsequent
>> >> >> > >> > >> >> changes were formatting as suggested by Rakesh.
>> >> >> > >> > >> >>
>> >> >> > >> > >> >>
>> >> >> > >> > >> >> On Thu, Jul 17, 2014 at 9:48 AM, Patrick Hunt
>> >> >> > >> > >> >> <ph...@apache.org
>> >> >> > >
>> >> >> > >> > wrote:
>> >> >> > >> > >> >>
>> >> >> > >> > >> >>> I'm concerned that the CI tests are all failing due to,
>> >> >> > >> > >> >>> for
>> >> >> > e.g.
>> >> >> > >> > >> >>> findbugs issues. At the very least our build/test/ci
>> >> >> > >> > >> >>> should be pretty clean - some flakeys is ok (the recent
>> >> >> > >> > >> >>> startServer fix
>> >> >> > and
>> >> >> > >> > >> >>> some other flakeys that have been addressed go a long
>> way
>> >> >> > >> > >> >>> on
>> >> >> > that
>> >> >> > >> > >> >>> issue) but I think the findbugs problem should be
>> cleaned
>> >> >> > >> > >> >>> up before we cut a release. I started a separate
>> thread to
>> >> >> > >> > >> >>> discuss
>> >> >> > >> the
>> >> >> > >> > findbugs issue.
>> >> >> > >> > >> >>>
>> >> >> > >> > >> >>> Otw we seem to be in ok shape - 1863 is in.
>> >> >> > >> > >> >>>
>> >> >> > >> > >> >>> Anyone have a chance to give feedback to Raul on 1919?
>> >> >> > >> > >> >>>
>> >> >> > >> > >> >>> Patrick
>> >> >> > >> > >> >>>
>> >> >> > >> > >> >>> On Tue, Jul 15, 2014 at 10:34 AM, Flavio Junqueira
>> >> >> > >> > >> >>> <fpjunque...@yahoo.com.invalid> wrote:
>> >> >> > >> > >> >>> > My take:
>> >> >> > >> > >> >>> >
>> >> >> > >> > >> >>> > - ZK-1863 is pending review. It is a blocker and it
>> can
>> >> >> > >> > >> >>> > go
>> >> >> > in.
>> >> >> > >> > >> >>> > See
>> >> >> > >> > >> the
>> >> >> > >> > >> >>> jira for comments.
>> >> >> > >> > >> >>> > - We can try to have ZK-1807 in for the first alpha.
>> >> >> > >> > >> >>> > - I'd rather not have the first alpha depending on
>> >> >> > >> > >> >>> > ZK-1919
>> >> >> > and
>> >> >> > >> > >> ZK-1910,
>> >> >> > >> > >> >>> we can leave it for the second alpha.
>> >> >> > >> > >> >>> >
>> >> >> > >> > >> >>> > If you agree with this, then we should be able to
>> cut a
>> >> >> > >> > >> >>> > candidate by
>> >> >> > >> > >> the
>> >> >> > >> > >> >>> end of this week.
>> >> >> > >> > >> >>> >
>> >> >> > >> > >> >>> > -Flavio
>> >> >> > >> > >> >>> >
>> >> >> > >> > >> >>> > On 15 Jul 2014, at 17:26, Patrick Hunt
>> >> >> > >> > >> >>> > <ph...@apache.org>
>> >> >> > >> wrote:
>> >> >> > >> > >> >>> >
>> >> >> > >> > >> >>> >> Per my previous note you can now see the c client
>> test
>> >> >> > >> > >> >>> >> log output
>> >> >> > >> > >> here
>> >> >> > >> > >> >>> >> in the "build artifacts" section:
>> >> >> > >> > >> >>> >>
>> >> >> > >> > >> >>>
>> >> >> > >> > >>
>> >> https://builds.apache.org/view/S-Z/view/ZooKeeper/job/ZooKeepe
>> >> >> > >> > >> r-
>> >> >> > >> > trunk
>> >> >> > >> > >> /2372/
>> >> >> > >> > >> >>> >>
>> >> >> > >> > >> >>> >> Patrick
>> >> >> > >> > >> >>> >>
>> >> >> > >> > >> >>> >> On Mon, Jul 14, 2014 at 7:36 PM, Patrick Hunt
>> >> >> > >> > >> >>> >> <ph...@apache.org>
>> >> >> > >> > >> wrote:
>> >> >> > >> > >> >>> >>> Update: we're back to 8 blockers on 3.5.0 (not
>> clear
>> >> >> > >> > >> >>> >>> to me which
>> >> >> > >> > >> >>> >>> one(s?) is new?)
>> >> >> > >> > >> >>> >>>
>> >> >> > >> > >> >>> >>> Looks like the autoconf issue I reported is hitting
>> >> >> > >> > >> >>> >>> the upgraded apache jenkins instances as well. I've
>> >> >> > >> > >> >>> >>> updated the "archive" list
>> >> >> > >> > >> to
>> >> >> > >> > >> >>> >>> include the c tests stdout redirect. So while it
>> won't
>> >> >> > >> > >> >>> >>> go
>> >> >> > to
>> >> >> > >> > >> console
>> >> >> > >> > >> >>> >>> at least we can debug when there is a failure.
>> >> >> > >> > >> >>> >>>
>> >> >> > >> > >> >>> >>> Raul has been helping Bill with reviews for the
>> jetty
>> >> >> > server
>> >> >> > >> > >> support
>> >> >> > >> > >> >>> >>> and it looks like that should be ready soon.
>> >> >> > >> > >> >>> >>>
>> >> >> > >> > >> >>> >>> Raul also requested that someone prioritize
>> reviewing
>> >> >> > >> > >> "ZOOKEEPER-1919
>> >> >> > >> > >> >>> >>> Update the C implementation of removeWatches to
>> have
>> >> >> > >> > >> >>> >>> it
>> >> >> > >> > match
>> >> >> > >> > >> >>> >>> ZOOKEEPER-1910" so that we can include it in 3.5.0.
>> >> >> > >> Flavio/Michi?
>> >> >> > >> > >> >>> >>>
>> >> >> > >> > >> >>> >>> Hongchao got a patch in to cleanup the flakey c
>> client
>> >> >> > >> > >> >>> >>> reconfig
>> >> >> > >> > >> test -
>> >> >> > >> > >> >>> >>> kudos on helping cleanup the build/test infra!
>> >> >> > >> > >> >>> >>>
>> >> >> > >> > >> >>> >>>
>> >> >> > >> > >> >>> >>> Based on previous comments it looks like we're
>> pretty
>> >> >> > close.
>> >> >> > >> > >> >>> >>> Do
>> >> >> > >> > >> folks
>> >> >> > >> > >> >>> >>> feel comfortable with a 3.5.0 alpha at this point?
>> >> >> > >> > >> >>> >>> (with a few
>> >> >> > >> > >> pending
>> >> >> > >> > >> >>> >>> as above)
>> >> >> > >> > >> >>> >>>
>> >> >> > >> > >> >>> >>> Patrick
>> >> >> > >> > >> >>> >>>
>> >> >> > >> > >> >>> >>> On Fri, Jul 11, 2014 at 9:24 AM, Raúl Gutiérrez
>> >> >> > >> > >> >>> >>> Segalés <r...@itevenworks.net> wrote:
>> >> >> > >> > >> >>> >>>> On Jul 11, 2014 6:37 AM, "Flavio Junqueira"
>> >> >> > >> > >> >>> <fpjunque...@yahoo.com.invalid>
>> >> >> > >> > >> >>> >>>> wrote:
>> >> >> > >> > >> >>> >>>>>
>> >> >> > >> > >> >>> >>>>> Just so that we don´t delay too much, what if we
>> >> >> > >> > >> >>> >>>>> release
>> >> >> > an
>> >> >> > >> > >> >>> >>>>> alpha
>> >> >> > >> > >> >>> version
>> >> >> > >> > >> >>> >>>> without 1863 and 1807, and do another one in 2-3
>> >> >> > >> > >> >>> >>>> weeks
>> >> >> > time?
>> >> >> > >> > >> >>> >>>>>
>> >> >> > >> > >> >>> >>>>
>> >> >> > >> > >> >>> >>>> +1
>> >> >> > >> > >> >>> >>>>
>> >> >> > >> > >> >>> >>>> -rgs
>> >> >> > >> > >> >>> >>>>
>> >> >> > >> > >> >>> >>>>> -Flavio
>> >> >> > >> > >> >>> >>>>>
>> >> >> > >> > >> >>> >>>>>
>> >> >> > >> > >> >>> >>>>> On Thursday, July 3, 2014 6:12 AM, Raúl Gutiérrez
>> >> >> > Segalés <
>> >> >> > >> > >> >>> >>>> r...@itevenworks.net> wrote:
>> >> >> > >> > >> >>> >>>>>
>> >> >> > >> > >> >>> >>>>>
>> >> >> > >> > >> >>> >>>>>>
>> >> >> > >> > >> >>> >>>>>>
>> >> >> > >> > >> >>> >>>>>> On 2 July 2014 21:19, Patrick Hunt
>> >> >> > >> > >> >>> >>>>>> <ph...@apache.org>
>> >> >> > >> > wrote:
>> >> >> > >> > >> >>> >>>>>>
>> >> >> > >> > >> >>> >>>>>>> Update: we're down to 7 blockers on 5.1.0
>> (from 8
>> >> >> > >> > >> >>> >>>>>>> in
>> >> >> > the
>> >> >> > >> > >> >>> >>>>>>> last
>> >> >> > >> > >> >>> check).
>> >> >> > >> > >> >>> >>>>>>> 1810 is waiting on feedback from Michi, and
>> >> >> > >> > >> >>> >>>>>>> Camille is
>> >> >> > >> > >> threatening
>> >> >> > >> > >> >>> to
>> >> >> > >> > >> >>> >>>>>>> commit 1863. I see some great progress in
>> general
>> >> >> > >> > >> >>> >>>>>>> on
>> >> >> > the
>> >> >> > >> > >> >>> >>>>>>> patch availables queue, which is great to see.
>> >> >> > >> > >> >>> >>>>>>>
>> >> >> > >> > >> >>> >>>>>>> So here's something else we might consider -
>> >> >> > >> > >> >>> >>>>>>> should we drop
>> >> >> > >> > >> jdk6
>> >> >> > >> > >> >>> >>>>>>> support from 3.5. It's long since EOL by Oracle
>> >> >> > >> > >> >>> >>>>>>> but I suspect
>> >> >> > >> > >> some
>> >> >> > >> > >> >>> >>>>>>> folks are still using ZK with 6. We gotta move
>> >> >> > >> > >> >>> >>>>>>> forward though,
>> >> >> > >> > >> >>> can't
>> >> >> > >> > >> >>> >>>>>>> support it forever. Thoughts? Note that we are
>> >> >> > currently
>> >> >> > >> > >> >>> >>>>>>> building/testing trunk against jdk6, 7 and 8.
>> >> >> > >> > >> >>> >>>>>>>
>> >> https://builds.apache.org/view/S-Z/view/ZooKeeper/
>> >> >> > >> > >> >>> >>>>>>>
>> >> >> > >> > >> >>> >>>>>>
>> >> >> > >> > >> >>> >>>>>> Extra eyes/review for
>> >> >> > >> > >> >>> >>>>
>> https://issues.apache.org/jira/browse/ZOOKEEPER-1807
>> >> >> > >> > >> >>> >>>>>> would be appreciated (otherwise anyone using
>> >> >> > >> > >> >>> >>>>>> Observers with the
>> >> >> > >> > >> >>> upcoming
>> >> >> > >> > >> >>> >>>>>> alpha release will see there network usage go
>> >> >> wild...).
>> >> >> > >> > >> >>> >>>>>>
>> >> >> > >> > >> >>> >>>>>>
>> >> >> > >> > >> >>> >>>>>> -rgs
>> >> >> > >> > >> >>> >>>>>>
>> >> >> > >> > >> >>> >>>>>>
>> >> >> > >> > >> >>> >>>>>>
>> >> >> > >> > >> >>> >>>>>>
>> >> >> > >> > >> >>> >>>>>>
>> >> >> > >> > >> >>> >>>>>>> Patrick
>> >> >> > >> > >> >>> >>>>>>>
>> >> >> > >> > >> >>> >>>>>>> On Tue, Jul 1, 2014 at 2:26 AM, Flavio
>> Junqueira
>> >> >> > >> > >> >>> >>>>>>> <fpjunque...@yahoo.com.invalid> wrote:
>> >> >> > >> > >> >>> >>>>>>>> According to me, ZK-1810 should be in already,
>> >> >> > >> > >> >>> >>>>>>>> but I need a +1
>> >> >> > >> > >> >>> >>>> there. I
>> >> >> > >> > >> >>> >>>>>>> think Michi hasn't checked in because LETest
>> >> >> > >> > >> >>> >>>>>>> failed in the
>> >> >> > >> > >> last QA
>> >> >> > >> > >> >>> run
>> >> >> > >> > >> >>> >>>>>>> there. However, that patch doesn't affect
>> LETest,
>> >> >> > >> > >> >>> >>>>>>> and
>> >> >> > in
>> >> >> > >> > >> >>> >>>>>>> fact
>> >> >> > >> > >> it
>> >> >> > >> > >> >>> fails
>> >> >> > >> > >> >>> >>>> in
>> >> >> > >> > >> >>> >>>>>>> trunk intermittently, so the test failure
>> doesn't
>> >> >> > >> > >> >>> >>>>>>> seem
>> >> >> > to
>> >> >> > >> > >> >>> >>>>>>> be
>> >> >> > >> > >> >>> related
>> >> >> > >> > >> >>> >>>> to the
>> >> >> > >> > >> >>> >>>>>>> patch.
>> >> >> > >> > >> >>> >>>>>>>>
>> >> >> > >> > >> >>> >>>>>>>> I haven't checked ZK-1863, so I can't say
>> >> >> > >> > >> >>> >>>>>>>> anything concrete
>> >> >> > >> > >> about
>> >> >> > >> > >> >>> it.
>> >> >> > >> > >> >>> >>>>>>>>
>> >> >> > >> > >> >>> >>>>>>>> -Flavio
>> >> >> > >> > >> >>> >>>>>>>>
>> >> >> > >> > >> >>> >>>>>>>>
>> >> >> > >> > >> >>> >>>>>>>>
>> >> >> > >> > >> >>> >>>>>>>> On Tuesday, July 1, 2014 5:53 AM, Patrick
>> Hunt <
>> >> >> > >> > >> ph...@apache.org>
>> >> >> > >> > >> >>> >>>> wrote:
>> >> >> > >> > >> >>> >>>>>>>>
>> >> >> > >> > >> >>> >>>>>>>>
>> >> >> > >> > >> >>> >>>>>>>>>
>> >> >> > >> > >> >>> >>>>>>>>>
>> >> >> > >> > >> >>> >>>>>>>>> Hi Flavio, do you think those jiras can get
>> >> >> > >> > >> reviewed/finalized
>> >> >> > >> > >> >>> before
>> >> >> > >> > >> >>> >>>>>>>>> the end of the week? I'd like to try cutting
>> an
>> >> >> > >> > >> >>> >>>>>>>>> RC
>> >> >> > >> > soonish...
>> >> >> > >> > >> >>> >>>>>>>>>
>> >> >> > >> > >> >>> >>>>>>>>> Patrick
>> >> >> > >> > >> >>> >>>>>>>>>
>> >> >> > >> > >> >>> >>>>>>>>>
>> >> >> > >> > >> >>> >>>>>>>>> On Sun, Jun 29, 2014 at 5:02 AM, Flavio
>> >> >> > >> > >> >>> >>>>>>>>> Junqueira <fpjunque...@yahoo.com.invalid>
>> >> wrote:
>> >> >> > >> > >> >>> >>>>>>>>>> +1 for the plan of releasing alpha versions.
>> >> >> > >> > >> >>> >>>>>>>>>>
>> >> >> > >> > >> >>> >>>>>>>>>> I'd like to have ZK-1818 (ZK-1810) and
>> ZK-1863
>> >> in.
>> >> >> > >> > >> >>> >>>>>>>>>> They are
>> >> >> > >> > >> both
>> >> >> > >> > >> >>> >>>> patch
>> >> >> > >> > >> >>> >>>>>>> available. ZK-1870 is in trunk, but it is still
>> >> >> > >> > >> >>> >>>>>>> open because we
>> >> >> > >> > >> >>> need a
>> >> >> > >> > >> >>> >>>> 3.4
>> >> >> > >> > >> >>> >>>>>>> patch.
>> >> >> > >> > >> >>> >>>>>>>>>>
>> >> >> > >> > >> >>> >>>>>>>>>> -Flavio
>> >> >> > >> > >> >>> >>>>>>>>>>
>> >> >> > >> > >> >>> >>>>>>>>>>
>> >> >> > >> > >> >>> >>>>>>>>>> On 26 Jun 2014, at 01:07, Patrick Hunt
>> >> >> > >> > >> >>> >>>>>>>>>> <ph...@apache.org>
>> >> >> > >> > >> >>> wrote:
>> >> >> > >> > >> >>> >>>>>>>>>>
>> >> >> > >> > >> >>> >>>>>>>>>>> Hey folks, we've been talking about it for
>> a
>> >> >> > while, a
>> >> >> > >> > >> >>> >>>>>>>>>>> few
>> >> >> > >> > >> >>> people
>> >> >> > >> > >> >>> >>>> have
>> >> >> > >> > >> >>> >>>>>>>>>>> mentioned on the list as well as contacted
>> me
>> >> >> > >> > >> >>> >>>>>>>>>>> personally
>> >> >> > >> > >> that
>> >> >> > >> > >> >>> they
>> >> >> > >> > >> >>> >>>>>>>>>>> would like to see some progress on the
>> first
>> >> >> > >> > >> >>> >>>>>>>>>>> 3.5
>> >> >> > >> > release.
>> >> >> > >> > >> Every
>> >> >> > >> > >> >>> >>>>>>>>>>> release is a compromise, if we wait for
>> >> >> > >> > >> >>> >>>>>>>>>>> perfection we'll
>> >> >> > >> > >> never
>> >> >> > >> > >> >>> get
>> >> >> > >> > >> >>> >>>>>>>>>>> anything out the door. 3.5 has tons of
>> great
>> >> >> > >> > >> >>> >>>>>>>>>>> new features,
>> >> >> > >> > >> >>> lots of
>> >> >> > >> > >> >>> >>>>>>>>>>> hard work, let's get it out in a release so
>> >> >> > >> > >> >>> >>>>>>>>>>> that folks can
>> >> >> > >> > >> use
>> >> >> > >> > >> >>> it,
>> >> >> > >> > >> >>> >>>>>>>>>>> test it, and give feedback.
>> >> >> > >> > >> >>> >>>>>>>>>>>
>> >> >> > >> > >> >>> >>>>>>>>>>> Jenkins jobs have been pretty stable except
>> >> >> > >> > >> >>> >>>>>>>>>>> for the known
>> >> >> > >> > >> >>> flakey
>> >> >> > >> > >> >>> >>>> test
>> >> >> > >> > >> >>> >>>>>>>>>>> ZOOKEEPER-1870 which Flavio committed
>> today to
>> >> >> > >> > trunk.
>> >> >> > >> > >> >>> >>>>>>>>>>> Note
>> >> >> > >> > >> that
>> >> >> > >> > >> >>> >>>>>>>>>>> jenkins has also been verifying the code on
>> >> >> > >> > >> >>> >>>>>>>>>>> jdk7
>> >> >> > and
>> >> >> > >> > jdk8.
>> >> >> > >> > >> >>> >>>>>>>>>>>
>> >> >> > >> > >> >>> >>>>>>>>>>> Here's my thinking again on how we should
>> plan
>> >> >> > >> > >> >>> >>>>>>>>>>> our
>> >> >> > >> > >> releases:
>> >> >> > >> > >> >>> >>>>>>>>>>>
>> >> >> > >> > >> >>> >>>>>>>>>>> I don't think we'll be able to do a
>> >> >> > >> > >> >>> >>>>>>>>>>> 3.5.x-stable
>> >> >> > for
>> >> >> > >> > >> >>> >>>>>>>>>>> some
>> >> >> > >> > >> time.
>> >> >> > >> > >> >>> >>>> What I
>> >> >> > >> > >> >>> >>>>>>>>>>> think we should do instead is similar to
>> what
>> >> >> > >> > >> >>> >>>>>>>>>>> we
>> >> >> > did
>> >> >> > >> > >> >>> >>>>>>>>>>> for
>> >> >> > >> > >> 3.4.
>> >> >> > >> > >> >>> >>>> (this is
>> >> >> > >> > >> >>> >>>>>>>>>>> also similar to what Hadoop did during
>> their
>> >> >> > Hadoop 2
>> >> >> > >> > >> release
>> >> >> > >> > >> >>> >>>> cycle)
>> >> >> > >> > >> >>> >>>>>>>>>>> Start with a series of alpha releases,
>> >> >> > >> > >> >>> >>>>>>>>>>> something people
>> >> >> > >> > >> can run
>> >> >> > >> > >> >>> >>>> and
>> >> >> > >> > >> >>> >>>>>>>>>>> test with, once we address all the blockers
>> >> >> > >> > >> >>> >>>>>>>>>>> and
>> >> >> > feel
>> >> >> > >> > >> >>> comfortable
>> >> >> > >> > >> >>> >>>> with
>> >> >> > >> > >> >>> >>>>>>>>>>> the apis & remaining jiras we then switch
>> to
>> >> >> beta.
>> >> >> > >> > >> >>> >>>>>>>>>>> Once we
>> >> >> > >> > >> get
>> >> >> > >> > >> >>> >>>> some
>> >> >> > >> > >> >>> >>>>>>>>>>> good feedback we remove the alpha/beta
>> moniker
>> >> >> > >> > and
>> >> >> > >> > >> >>> >>>>>>>>>>> look at
>> >> >> > >> > >> >>> making
>> >> >> > >> > >> >>> >>>> it
>> >> >> > >> > >> >>> >>>>>>>>>>> "stable'. At some later point it will
>> become
>> >> >> > >> > >> >>> >>>>>>>>>>> the
>> >> >> > >> > >> >>> "current/stable"
>> >> >> > >> > >> >>> >>>>>>>>>>> release, taking over from 3.4.x.
>> >> >> > >> > >> >>> >>>>>>>>>>>
>> >> >> > >> > >> >>> >>>>>>>>>>> e.g.
>> >> >> > >> > >> >>> >>>>>>>>>>> 3.5.0-alpha (8 blockers) 3.5.1-alpha (3
>> >> >> > >> > >> >>> >>>>>>>>>>> blockers) 3.5.2-alpha (0 blockers)
>> 3.5.3-beta
>> >> >> > >> > >> >>> >>>>>>>>>>> (apis locked) 3.5.4-beta 3.5.5-beta
>> >> >> > >> > >> >>> >>>>>>>>>>> 3.5.6 (no longer considered alpha/beta but
>> >> >> > >> > >> >>> >>>>>>>>>>> also not
>> >> >> > >> > >> "stable" vs
>> >> >> > >> > >> >>> >>>> 3.4.x,
>> >> >> > >> > >> >>> >>>>>>>>>>> maybe use it for production but we still
>> >> >> > >> > >> >>> >>>>>>>>>>> expect things to
>> >> >> > >> > >> shake
>> >> >> > >> > >> >>> >>>> out)
>> >> >> > >> > >> >>> >>>>>>>>>>> 3.5.7
>> >> >> > >> > >> >>> >>>>>>>>>>> ....
>> >> >> > >> > >> >>> >>>>>>>>>>> 3.5.x - ready to replace 3.4 releases for
>> >> >> > production
>> >> >> > >> > >> >>> >>>>>>>>>>> use,
>> >> >> > >> > >> >>> stable,
>> >> >> > >> > >> >>> >>>>>>> etc...
>> >> >> > >> > >> >>> >>>>>>>>>>>
>> >> >> > >> > >> >>> >>>>>>>>>>> There are 8 blockers currently, are any of
>> >> >> > >> > >> >>> >>>>>>>>>>> these something
>> >> >> > >> > >> that
>> >> >> > >> > >> >>> >>>> should
>> >> >> > >> > >> >>> >>>>>>>>>>> hold up 3.5.0-alpha?
>> >> >> > >> > >> >>> >>>>>>>>>>>
>> >> >> > >> > >> >>> >>>>>>>>>>> I'll hold open the discussion for a couple
>> >> >> > >> > >> >>> >>>>>>>>>>> days. If folks
>> >> >> > >> > >> find
>> >> >> > >> > >> >>> >>>> this a
>> >> >> > >> > >> >>> >>>>>>>>>>> reasonable plan I'll start the ball
>> rolling to
>> >> >> > >> > >> >>> >>>>>>>>>>> cut
>> >> >> > an
>> >> >> > >> RC.
>> >> >> > >> > >> >>> >>>>>>>>>>>
>> >> >> > >> > >> >>> >>>>>>>>>>> Patrick
>> >> >> > >> > >> >>> >>>>>>>>>>
>> >> >> > >> > >> >>> >>>>>>>>>
>> >> >> > >> > >> >>> >>>>>>>>>
>> >> >> > >> > >> >>> >>>>>>>>>
>> >> >> > >> > >> >>> >>>>>>>
>> >> >> > >> > >> >>> >>>>>>
>> >> >> > >> > >> >>> >>>>>>
>> >> >> > >> > >> >>> >>>>>>
>> >> >> > >> > >> >>> >
>> >> >> > >> > >> >>>
>> >> >> > >> > >>
>> >> >> > >>
>> >> >> > >>
>> >> >> >
>> >> >>
>> >>
>>
