Re: [VOTE] Apache ZooKeeper release 3.4.14 candidate 5

[Raúl Gutiérrez Segalés]

+1, ran various tests with zk-shell.


-rgs

On Wed, Mar 27, 2019 at 7:15 AM Flavio Junqueira  wrote:

> +1, I have checked the following:
>
> - Signature and checksums
> - Builds locally, unit tests pass
> - NOTICE file has been updated to reflect the present year
> - Smoke tests with a local ensemble
> - Maven project is able to resolve zookeeper dependency using the staging
> repository
> - Release notes
>
> -Flavio
>
> > On 13 Mar 2019, at 19:07, Patrick Hunt  wrote:
> >
> > +1 - sig/xsum verified, rat ran clean, was able to run various ensemble
> > sizes successfully.
> >
> > Patrick
> >
> > On Wed, Mar 6, 2019 at 10:56 AM Andor Molnar  wrote:
> >
> >> This is a bugfix release candidate for 3.4.14. It fixes 8 issues, mostly
> >> build / unit tests issues,
> >> dependency updates flagged by OWASP, NPE and a name resolution problem.
> >> Among these it also supports
> >> experimental Maven build and Markdown based documentation generation.
> >>
> >> The full release notes is available at:
> >>
> >>
> >>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310801&version=12343587
> >>
> >> *** Please download, test and vote by March 10th 2019, 23:59 UTC+0. ***
> >>
> >> Source files:
> >> https://dist.apache.org/repos/dist/dev/zookeeper/zookeeper-3.4.14-rc5/
> >>
> >> Maven staging repo:
> >>
> >>
> https://repository.apache.org/content/groups/staging/org/apache/zookeeper/zookeeper/3.4.14/
> >>
> >> The release candidate tag in git to be voted upon: release-3.4.14-rc5
> >>
> >> ZooKeeper's KEYS file containing PGP keys we use to sign the release:
> >> http://www.apache.org/dist/zookeeper/KEYS
> >>
> >> Should we release this candidate?
> >>
> >> Regards,
> >> Andor
> >>
> >>
> >>
>
>

Re: [VOTE] Upgrade 3.5 and trunk to Java8

[Raúl Gutiérrez Segalés]

+1

On Thu, Mar 22, 2018 at 1:08 PM, Tamas Penzes  wrote:

> +1 (non-binding)
>
> On Thu, Mar 22, 2018 at 6:57 PM, Andor Molnar  wrote:
>
> > Hi all,
> >
> > Let's start the vote on upgrading to Java8.
> > https://issues.apache.org/jira/browse/ZOOKEEPER-3002
> >
> > *Shall we upgrade the minimum required Java version to compile and run
> > ZooKeeper on 3.5 and master branches to Java 1.8?*
> >
> > Please cast your vote by replying 'Yes' or 'No' to this thread.
> >
> > Thanks,
> > Andor
> >
>
>
>
> --
> *Tamás **Pénzes* | Engineering Manager
> e. tam...@cloudera.com
> cloudera.com 
>

Re: Re: [ANNOUNCE] New ZooKeeper committer: Abraham Fine

[Raúl Gutiérrez Segalés]

congrats Abe!


-rgs

On Wed, Jan 31, 2018 at 8:47 PM, Mohammad arshad  wrote:

> Congratulations and Welcome Abe!
>
> -Arshad
>
> -Original Message-
> From: Michael Han [mailto:h...@apache.org]
> Sent: Wednesday, January 31, 2018 12:09 PM
> To: dev@zookeeper.apache.org
> Subject: Re: Re: [ANNOUNCE] New ZooKeeper committer: Abraham Fine
>
> Congratulations Abe!
>
> On Tue, Jan 30, 2018 at 10:35 Brian Nixon 
> wrote:
>
> > Congratulations, Abe!
> >
> > On Tue, Jan 30, 2018 at 3:23 AM, Michelle Tan 
> > wrote:
> >
> > > Congratulations Abe! :D
> > >
> > > Regards,
> > > Michelle
> > >
> > > On Tue, Jan 30, 2018 at 11:18 AM, 岭秀 
> wrote:
> > >
> > > > Congratulations to Abe!  A well-deserved honor
> > > > 
> > > > 
> > > > -
> > > > > On Tue, Jan 30, 2018 at 1:22 AM, Patrick Hunt 
> > > wrote:
> > > > >
> > > > > > The Apache ZooKeeper PMC recently extended committer karma to Abe
> > and
> > > > he
> > > > > > has accepted. Abe has made some great contributions and we are
> > > looking
> > > > > > forward to even more :)
> > > > > >
> > > > > > Congratulations and welcome aboard Abe!
> > > > > >
> > > > > > Patrick
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: Major issue with Container Nodes/TTL nodes!!!

[Raúl Gutiérrez Segalés]

On 20 September 2017 at 12:54, Camille Fournier  wrote:

> Ok let's take this back to either public mailing list or jira. I'd write up
> thoughts on jira and ask there+ml to look. I'll try to look tonight
>

Thanks Camille!

Also, I merged this originally so I will work with Jordan on getting this
fixed. Let me know
when you have a write up of your proposed solution and I'll take a look.
Thanks!


-rgs



> On Sep 20, 2017 3:52 PM, "Jordan Zimmerman" 
> wrote:
>
> > I'd like to fix it as my company and probably many others are now using
> it
> > in production. The question is how to fix it safely and correctly. Is
> email
> > the best way to discuss this? Jira? Something else?
> >
> > I must say that there appears to be a trivial fix but I need the ZK
> > committers to think about this. In SessionTrackerImpl#
> initializeNextSession()
> > only some of the server ID bits are used. We could easily just mask the 2
> > high bits as well. But, what are the implications of this? Where is this
> > serverId byte used? What must be double checked?
> >
> > -Jordan
> >
> > On Sep 20, 2017, at 2:46 PM, Camille Fournier 
> wrote:
> >
> > Would you rather roll back the feature or put in a fix?
> >
> > On Sep 20, 2017 3:44 PM, "Jordan Zimmerman" 
> > wrote:
> >
> >> Hey Folks,
> >>
> >> This is very serious. Please - let's discuss immediately. I'm not
> certain
> >> how to fix this.
> >>
> >> -JZ
> >>
> >> On Sep 20, 2017, at 2:17 PM, Jordan Zimmerman <
> jor...@jordanzimmerman.com>
> >> wrote:
> >>
> >> See: https://issues.apache.org/jira/browse/ZOOKEEPER-2901
> >>
> >> It appears that the high order byte of a session ID is reserved for the
> >> ServerID. I don't know how I could have missed this or how this got by
> code
> >> review, but Container Nodes and TTL nodes are using the 2 high bits to
> >> denote container/TTL. I'll work on a fix ASAP. But, can someone validate
> >> this?
> >>
> >> -Jordan
> >>
> >>
> >>
> >
>

Re: Extending the vote (was: Re: [VOTE] Apache ZooKeeper release 3.5.3-beta candidate 1)

[Raúl Gutiérrez Segalés]

+1 -- Is am traveling so I need a few more days to test this in one of our
dev clusters.


-rgs


On Apr 7, 2017 2:53 PM, "Flavio Junqueira"  wrote:

> Would it be ok to extend the vote until mid next week?
>
> -Flavio
>
> > On 03 Apr 2017, at 18:26, Michael Han  wrote:
> >
> > Hi all,
> >
> > This is the second release candidate (RC1) of 3.5.3-beta, following the
> > first release candidate (RC0) cut off last week [1]. It fixes incorrect
> > Implementation-Version information contained in the manifest file of the
> > generated artifacts. There is no code changes, just regenerated and
> > resigned artifacts.
> >
> > The full release notes are available at:
> >
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> > projectId=12310801&version=12335444
> >
> >  Please download, test and vote by April 8th 2017, 23:59 UTC+0. 
> >
> > Source files:
> > https://home.apache.org/~hanm/zookeeper/zookeeper-3.5.3-beta-rc1/
> >
> > Maven staging repo:
> > https://repository.apache.org/content/groups/staging/org/
> > apache/zookeeper/zookeeper/3.5.3-beta/
> >
> > The tag to be voted upon:
> > *https://github.com/apache/zookeeper/tree/release-3.5.3-rc1
> > *
> >
> > ZooKeeper's KEYS file containing PGP keys we use to sign the release:
> > http://www.apache.org/dist/zookeeper/KEYS
> >
> > Should we release this candidate?
> >
> > [1]
> > http://mail-archives.apache.org/mod_mbox/zookeeper-dev/
> 201703.mbox/%3CCA%2Bi0x1LTONuaT6H%2BiOHAT2O1SVPKnQzzQh8vKMzWJVij
> CrHUrw%40mail.gmail.com%3E
> >
> > --
> > Cheers
> > Michael.
>
>

Re: [ANNOUNCE] New ZooKeeper committer: Michael Han

[Raúl Gutiérrez Segalés]

Congrats Michael!

On Jan 3, 2017 11:29 AM, "Patrick Hunt"  wrote:

> The Apache ZooKeeper PMC recently extended committer karma to Michael and
> he has accepted. Michael has made some great contributions and we are
> looking forward to even more :)
>
> Congratulations and welcome aboard, Michael!
> Patrick
>

Re: Test plan for ZK-1045 - Call for volunteers

[Raúl Gutiérrez Segalés]

On 18 November 2016 at 12:15, Patrick Hunt  wrote:

> As Flavio said originally on this thread this is a big change. Based on the
> current status of the patch and the testing feedback it seems like we've
> done significant work to ensure the quality of the change. Do folks feel
> that there has been sufficient review/testing that we can commit this and
> cut a 3.5.10 release? If not what specifically is left?
>

3.5.10?


-rgs

Re: QA for pull requests

[Raúl Gutiérrez Segalés]

Merged:

https://git-wip-us.apache.org/repos/asf?p=zookeeper.git;a=commitdiff;h=881256ea97a19e51b1c6e9a114e6e61ad83bd4ec;hp=440e0923dd9e3be533a196fdd6ada960860ca7f6

Thanks Flavio!


-rgs

On 12 November 2016 at 19:48, Raúl Gutiérrez Segalés 
wrote:

> Looking
>
> On 12 November 2016 at 11:25, Flavio Junqueira  wrote:
>
>> Second attempt, could any of the committers of this project take a look
>> at this, please?
>>
>> -Flavio
>>
>> > On 11 Nov 2016, at 08:11, Flavio Junqueira  wrote:
>> >
>> > I have made some changes to fix a couple issues with the QA for pull
>> requests. Can I have a committer checking it out, please? We need to have
>> this in otherwise the builds will keep failing.
>> >
>> > The issue is ZOOKEEPER-2631 and the pull request is this one:
>> >
>> > https://github.com/apache/zookeeper/pull/104/
>> >
>> > Thanks,
>> >
>> > -Flavio
>> >
>> >> On 10 Nov 2016, at 18:33, Flavio P JUNQUEIRA  wrote:
>> >>
>> >> I think the way I've done extract the jira number isn't working, none
>> of the recent pull requests is going through because the title isn't in the
>> expected format. We need to make that more robust.
>> >>
>> >> If anyone wants to contribute, then great, otherwise I'll fix it when
>> I have a chance.
>> >>
>> >> -Flavio
>> >
>>
>>
>

Re: QA for pull requests

[Raúl Gutiérrez Segalés]

Looking

On 12 November 2016 at 11:25, Flavio Junqueira  wrote:

> Second attempt, could any of the committers of this project take a look at
> this, please?
>
> -Flavio
>
> > On 11 Nov 2016, at 08:11, Flavio Junqueira  wrote:
> >
> > I have made some changes to fix a couple issues with the QA for pull
> requests. Can I have a committer checking it out, please? We need to have
> this in otherwise the builds will keep failing.
> >
> > The issue is ZOOKEEPER-2631 and the pull request is this one:
> >
> > https://github.com/apache/zookeeper/pull/104/
> >
> > Thanks,
> >
> > -Flavio
> >
> >> On 10 Nov 2016, at 18:33, Flavio P JUNQUEIRA  wrote:
> >>
> >> I think the way I've done extract the jira number isn't working, none
> of the recent pull requests is going through because the title isn't in the
> expected format. We need to make that more robust.
> >>
> >> If anyone wants to contribute, then great, otherwise I'll fix it when I
> have a chance.
> >>
> >> -Flavio
> >
>
>

Re: [DISCUSS] QA github pre-commit queue

[Raúl Gutiérrez Segalés]

On 6 November 2016 at 11:54, Flavio Junqueira  wrote:

> ZOOKEEPER-2624 has been merged, thank Raul, Ben and Michael for reviewing.
>
> The QA for pull requests should be working for pull requests agains
> master, but let's keep an eye and polish any rough edges that might still
> be there.
>
> With ZOOKEEPER-2624 in, there is one last major decision we need to make
> to wrap this up. The pull request QA currently do not make a jira patch
> available. This is intentional because making it patch available will
> trigger the original Jira QA, which will be confusing because we will see a
> failure (I haven't tested, but I think that's what's going to happen). If
> we change the script to make the Jira patch available, then we need to
> either:
>
> 1- Disable the Jira QA altogether, which means that we will only have pull
> request QA available
> 2- Make the Jira QA script spot that there is a pull request available and
> not build it.
>
> I'm wondering if folks would be ok with only having patches submitted via
> pull requests or if we should continue to support the old Jira QA.
>

I am +1 on only having patches submitted via PRs, it's simpler to only have
to support one method. Thanks Flavio for making this happen!


-rgs

Re: Jenkins issue

[Raúl Gutiérrez Segalés]

On 5 November 2016 at 10:21, Michael Han  wrote:

> >> Might as well fix the issues
> +1. Created ZOOKEEPER-2628 for this task.
>

thanks Michael!


-rgs

Re: Bug in the c-binding in "zoo_remove_watchers"

[Raúl Gutiérrez Segalés]

Thanks for contributing Eyal! The patches have been merged.


-rgs

On 7 October 2016 at 02:57, Flavio Junqueira  wrote:

> Hey Eyal,
>
> Thanks for reporting this issue and producing a patch. We actually have
> some guidelines for contributing described here:
>
> https://cwiki.apache.org/confluence/display/ZOOKEEPER/HowToContribute <
> https://cwiki.apache.org/confluence/display/ZOOKEEPER/HowToContribute>
>
> Could you please report and provide your patch as described here?
>
> -Flavio
>
> > On 07 Oct 2016, at 07:17, Eyal Leshem  wrote:
> >
> > hi all ,
> >
> > I am new in this mailing-list -
> > and i joined  because i think a find a bug ,  and i want to know what
> is procedure for fixing it.
> >
> > the bug is in the c binding - when you use  "zoo_remove_watchers" ,
> > and it's can cause to someone that use this function to delete other
> watch - and not the one he mean to delete.
> >
> > The actual problem is in the function "removeWatcherFromList" -
> > That when we check if we need to delete the watch -  we compare the
> WatcherCtx to one node before the one we want to delete..
> >
> > a suggested patch is attached ..
> >
> > thanks a lot,
> > eyal
> >
> > 
>
>

Re: [VOTE] move Apache Zookeeper to git

[Raúl Gutiérrez Segalés]

On 12 September 2016 at 17:48, Patrick Hunt  wrote:

> On Mon, Sep 12, 2016 at 10:15 AM, Raúl Gutiérrez Segalés
>  wrote:
> > On 12 September 2016 at 09:58, Patrick Hunt  wrote:
> >
> >> Here it is, please take a look, review, and commit it to master
> >> (remember, needs to be git now :-) )
> >> https://issues.apache.org/jira/browse/ZOOKEEPER-2576
> >
> >
> > Merged:
> > https://git-wip-us.apache.org/repos/asf?p=zookeeper.git;a=commitdiff;h=
> 8c4082647f89b0a92fa00a2af8de84b3c7314e23
> >
> > This is only needed in master?
> >
>
> Only on master. Our current pre-commit is only for master. If we move
> to something like Yetus I believe they will also check branches.
>
> Raul/Ben/et.al. can you commit the second part of the patch? I
> attached it to ZOOKEEPER-2576. Bit of a cleanup on the command naming
> (missed build.xml changes). Thanks.
>

Merged:
https://git-wip-us.apache.org/repos/asf?p=zookeeper.git;a=commitdiff;h=b2a484cfe743116d2531fe5d1e1d78b3960c511e


-rgs

Re: [VOTE] move Apache Zookeeper to git

[Raúl Gutiérrez Segalés]

On 12 September 2016 at 09:58, Patrick Hunt  wrote:

> Here it is, please take a look, review, and commit it to master
> (remember, needs to be git now :-) )
> https://issues.apache.org/jira/browse/ZOOKEEPER-2576


Merged:
https://git-wip-us.apache.org/repos/asf?p=zookeeper.git;a=commitdiff;h=8c4082647f89b0a92fa00a2af8de84b3c7314e23

This is only needed in master?


-rgs

p.s.: this feels so good! thanks Pat & Ben :-)


>
> Patrick
>
> On Mon, Sep 12, 2016 at 9:10 AM, Patrick Hunt  wrote:
> > I worked up a patch last night, I'll create the jira and attach the
> > patch later today when I get a few.
> >
> > Patrick
> >
> > On Mon, Sep 12, 2016 at 7:29 AM, Flavio Junqueira 
> wrote:
> >>
> >>> On 12 Sep 2016, at 06:42, Patrick Hunt  wrote:
> >>>
> >>> afaik there has never been github integration for anything with ZK.
> >>> QAbot only runs against jira/svn.
> >>
> >> I'm not sure what you're trying to say here. Both Apache Kafka and
> Apache BookKeeper use ZK and currently use github.
> >>
> >>>
> >>> FYI: I've gone through all the jenkins jobs (3.4/3.5/trunk) and gotten
> >>> them working again. There was a ton of cruft in there which I
> >>> attempted to cleanup. I think things should be ok, but I will be
> >>> monitoring over the next few days. If you notice obvious issues please
> >>> lmk (vs say flakey tests).
> >>>
> >>
> >> Thanks for doing this, Pat.
> >>
> >>> Additionally - qabot (precommit job) is broken. The zookeeper script
> >>> ./src/java/test/bin/test-patch.sh is used by QAbot, and it uses svn
> >>> directly. We'll need to patch this script in order to get qabot
> >>> functional again - replace svn with git usage. There's only a few
> >>> lines but I'm not familiar with this script. If anyone wants to take a
> >>> stab please submit a jira/patch. I've turned off precommit job on
> >>> jenkins until we get this straightened out.
> >>> https://builds.apache.org/view/S-Z/view/ZooKeeper/job/
> PreCommit-ZOOKEEPER-Build/
> >>>
> >>
> >> If we don't have a jira yet, we should create one. It is important to
> turn pre-commit back on.
> >>
> >> -Flavio
> >>
> >>> Patrick
> >>>
> >>> On Sun, Sep 11, 2016 at 9:32 PM, Benjamin Reed 
> wrote:
>  sure. i'll update it to reference git rather than svn.
> 
>  if i understand correctly pull requests that were submitted via
> github were
>  reviewed by the qa bot (or something like that) in the past, but it
> was
>  turned off. we should turn that back on i think.
> 
>  thanx
>  ben
> 
>  On Sun, Sep 11, 2016 at 8:49 PM, Patrick Hunt 
> wrote:
> >
> > FYI Apache INFRA has made the cutover -
> > https://issues.apache.org/jira/browse/INFRA-12573
> >
> > At this point we need to update the "how to contribute" etc... Ben do
> > you want to take a stab at that? I can update the respective Jenkins
> > jobs.
> >
> > What else is there?
> >
> > Patrick
> >
> > On Wed, Sep 7, 2016 at 9:59 AM, Chris Nauroth <
> cnaur...@hortonworks.com>
> > wrote:
> >> Thank you for doing this, Eddie.  I just picked up the code review.
> >>
> >> --Chris Nauroth
> >>
> >> On 9/7/16, 9:49 AM, "Edward Ribeiro" 
> wrote:
> >>
> >>Hey folks, as part of this major change, I took a look at the
> >> gitignore and
> >>it already lacks a lot of file extensions for a modern Java
> project.
> >>Therefore, I created a trivial patch (shameless plug) that
> updates
> >> for more
> >>commonly extensions:
> >> https://issues.apache.org/jira/browse/ZOOKEEPER-2557
> >>
> >>Could you please review it and (the committers) this incorporated
> >> into
> >>branches before the transition if everything is alright, whenever
> >> you have
> >>time? The final gitignore doesn't look particularly big and cover
> >> only
> >>mostly the common IDE extensions and temporary files.
> >>
> >>Cheers,
> >>Eddie
> >>
> >>
> >>On Wed, Sep 7, 2016 at 7:31 AM, Flavio Junqueira  >
> >> wrote:
> >>
> >>> +1
> >>>
>  On 07 Sep 2016, at 06:10, Patrick Hunt  wrote:
> 
>  Quick update (more details on the INFRA jira). It might take
> >> upwards of
> >>> 24
>  hours to do the svn->git migration although our repo isn't that
> >> large,
>  likely less. INFRA can do it, for example, on Saturday around
> >> 18:00 UTC.
>  Any concerns with such an approach?
> 
>  Patrick
> 
>  On Sun, Sep 4, 2016 at 9:20 PM, Patrick Hunt 
> >> wrote:
> 
> > Follow along here:
> >> https://issues.apache.org/jira/browse/INFRA-12573
> >
> > Patrick
> >
> > On Sun, Sep 4, 2016 at 8:33 AM, Benjamin Reed
> >>  wrote:
> >
> >> with 10 votes for (5 of which are from the PMC) on no votes
> >> against.
> >>> the
> >> vote p

Re: Missing patch ZOOKEEPER-1927 in 3.5 branch

[Raúl Gutiérrez Segalés]

On 7 September 2016 at 20:53, Patrick Hunt  wrote:

> No worries. I would have committed myself but it wasn't clear if that

was the right thing to do or not. Thanks for resolving.
>

Merged:

https://github.com/apache/zookeeper/commit/ac26b96b61e116937239a15fb4dbcc4f17a4f818


-rgs



> Patrick
>
> On Wed, Sep 7, 2016 at 8:50 PM, Raúl Gutiérrez Segalés
>  wrote:
> > On 7 September 2016 at 20:44, Patrick Hunt  wrote:
> >>
> >> Hi Chris, Raul, it looks like ZOOKEEPER-1927 is in 3.4 and trunk,
> >> however it did not land in 3.5.2 as recorded in the jira.
> >>
> >> https://issues.apache.org/jira/browse/ZOOKEEPER-1927
> >>
> >> I noticed this when attempting to commit
> >> https://issues.apache.org/jira/browse/ZOOKEEPER-2536 as it applied
> >> cleanly to trunk but not to 3.5 branch.
> >>
> >> I looked at the logs and afaict it's in 3.4 and trunk, but not in 3.5
> >> branch.
> >>
> >> Do you guys know what happened here? Just an oversight or on purpose?
> >
> >
> > Definitely oversight -- sorry. I'll go ahead and merge now. Thanks!
> >
> >
> > -rgs
> >
>

Re: Missing patch ZOOKEEPER-1927 in 3.5 branch

[Raúl Gutiérrez Segalés]

On 7 September 2016 at 20:44, Patrick Hunt  wrote:

> Hi Chris, Raul, it looks like ZOOKEEPER-1927 is in 3.4 and trunk,
> however it did not land in 3.5.2 as recorded in the jira.
>
> https://issues.apache.org/jira/browse/ZOOKEEPER-1927
>
> I noticed this when attempting to commit
> https://issues.apache.org/jira/browse/ZOOKEEPER-2536 as it applied
> cleanly to trunk but not to 3.5 branch.
>
> I looked at the logs and afaict it's in 3.4 and trunk, but not in 3.5
> branch.
>
> Do you guys know what happened here? Just an oversight or on purpose?
>

Definitely oversight -- sorry. I'll go ahead and merge now. Thanks!


-rgs

Re: [VOTE] move Apache Zookeeper to git

[Raúl Gutiérrez Segalés]

+1

-rgs

On Aug 31, 2016 3:29 PM, "Benjamin Reed"  wrote:

> flip the switch to git and update the relevant scripts and docs.
>
> i couldn't figure out which timeframe this falls under in the voting
> procedure table, but i think it's safe to go with 3 days, so the vote will
> close on Saturday, September 3 at 6:30pm pdt.
>
> +1 from me
>

Re: switching to git?

[Raúl Gutiérrez Segalés]

On 26 August 2016 at 10:35, Benjamin Reed  wrote:

> i'm starting to get back into zk development :) i'm a bit distressed that
> we are still using svn and patches managed by jiras. i've gotten extremely
> spoiled by gerritt and phabricator over the years!
>
> as a first step to more efficient workflows for contributors and committers
> can we move to git? i had an offline conversation with pat and he knows how
> to flip the switch.
>

big +1


-rgs

Re: [ANNOUNCE] Chris Nauroth joins the Apache ZooKeeper PMC

[Raúl Gutiérrez Segalés]

Thanks & congrats Chris! Great having you onboard :-)

On Aug 7, 2016 11:05 AM, "Flavio Junqueira"  wrote:

> In recognition of all his contributions to the project, the Apache
> ZooKeeper PMC has invited Chris Nauroth to join the PMC and he has
> accepted. I'd like to take the opportunity to thank Chris for his
> contributions and commitment to the project. Thank you and congratulations
> for joining the PMC, Chris!
>
> -Flavio

Re: Status: Apache ZooKeeper release 3.5.2-alpha candidate 1

[Raúl Gutiérrez Segalés]

Thanks Pat!

On 20 July 2016 at 14:57, Patrick Hunt  wrote:

> Site is updated.
>
> Patrick
>
> On Wed, Jul 20, 2016 at 2:51 PM, Patrick Hunt  wrote:
> > Thanks for pointing this out Chris, I'll update the site.
> >
> > FYI committers can view the official list here:
> > https://whimsy3.apache.org/roster/committee/zookeeper
> >
> > Patrick
> >
> > On Tue, Jul 19, 2016 at 10:09 PM, Chris Nauroth
> >  wrote:
> >> I had miscounted the vote from Raúl as non-binding, based on this page
> >> listing him as committer instead of PMC.
> >>
> >> http://zookeeper.apache.org/credits.html
> >>
> >> Thank you for the clarification.  We have the votes we need.
> >>
> >> (Side note: let's update that page.)
> >>
> >> --Chris Nauroth
> >>
> >>
> >>
> >>
> >> On 7/19/16, 9:44 PM, "Flavio Junqueira"  wrote:
> >>
> >>>What are the votes you're counting? I thought that myself, Raul, and Pat
> >>>had voted +1. The three of us are PMC members.
> >>>
> >>>-Flavio
> >>>
> >>>> On 19 Jul 2016, at 21:41, Chris Nauroth 
> >>>>wrote:
> >>>>
> >>>> I'm back.  Thanks to everyone who kept testing and voting while I was
> >>>>out.
> >>>>
> >>>> At this point, the tally is:
> >>>>
> >>>> 2 +1 (binding)
> >>>> 5 +1 (non-binding)
> >>>>
> >>>> Can we please get one more PMC member to try the release candidate and
> >>>> cast a vote?  (Camille, thank you for your testing and investigation
> of
> >>>> the test failures you saw.  I understand the choice to abstain.)
> >>>>
> >>>> --Chris Nauroth
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On 7/7/16, 11:16 AM, "Michael Han"  wrote:
> >>>>
> >>>>> Add my data points:
> >>>>> Java unit tests all passed on my mac and test cluster (Ubuntu 14.04).
> >>>>> Both NioNettySuiteTest and NettyNettySuiteTest also passed on mac in
> 5
> >>>>> runs.
> >>>>> Source used for testing:
> >>>>>
> >>>>>
> http://people.apache.org/~cnauroth/zookeeper-3.5.2-alpha-candidate-1/zoo
> >>>>>ke
> >>>>> eper-3.5.2-alpha.tar.gz
> >>>>>
> >>>>> On Thu, Jul 7, 2016 at 9:22 AM, Camille Fournier  >
> >>>>> wrote:
> >>>>>
> >>>>>> Testcase: testRemoveOneAsynchronous took 60.235 sec
> >>>>>>FAILED
> >>>>>> Waiting for server down
> >>>>>> junit.framework.AssertionFailedError: Waiting for server down
> >>>>>>at
> >>>>>>
> org.apache.zookeeper.test.QuorumUtil.shutdownAll(QuorumUtil.java:241)
> >>>>>>at
> >>>>>> org.apache.zookeeper.test.QuorumUtil.startAll(QuorumUtil.java:143)
> >>>>>>at
> >>>>>>
> >>>>>>
> >>>>>>
>
> >>>>>>org.apache.zookeeper.test.ReconfigTest.testRemoveOneAsynchronous(Reconf
> >>>>>>ig
> >>>>>> Test.java:436)
> >>>>>>at
> >>>>>>
> >>>>>>
> >>>>>>
>
> >>>>>>org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUn
> >>>>>>it
> >>>>>> 4ZKTestRunner.java:79)
> >>>>>>
> >>>>>>FAILED
> >>>>>> Waiting for server down
> >>>>>> junit.framework.AssertionFailedError: Waiting for server down
> >>>>>>at
> >>>>>>
> org.apache.zookeeper.test.QuorumUtil.shutdownAll(QuorumUtil.java:241)
> >>>>>>at
> >>>>>> org.apache.zookeeper.test.QuorumUtil.tearDown(QuorumUtil.java:306)
> >>>>>>at
> >>>>>>
> org.apache.zookeeper.test.ReconfigTest.tearDown(ReconfigTest.java:64)
> >>>>>>
> >>>>>> Both of these say they're waiting for server down. The logs are not
> >>>>>> particularly helpful. However, this does not fail in the earlier
> >>>&g

Re: ZooKeeper release validation cluster access

[Raúl Gutiérrez Segalés]

A bit late, but fwiw this was the 2015 flavor of my (personal) validation
process:

http://itevenworks.net/zk-releases

-rgs
On Jul 8, 2016 11:18 AM, "Michael Han"  wrote:

> Sure, I will post an early version next week.
>
> On Fri, Jul 8, 2016 at 10:55 AM, Camille Fournier 
> wrote:
>
> > That's great Michael do you think you could share any of your work on
> > github to get us started?
> > On Jul 8, 2016 1:41 PM, "Michael Han"  wrote:
> >
> > > Regarding ZK deployment automation, I am building an automation that is
> > > very similar to the requirement here - the motivation is to save me
> > > sometime on validation / regression test of ZOOKEEPER-1045 and I could
> > see
> > > same automation being used to validate a release as well.
> > > It might not be ready for this release given limited time I have but
> I'll
> > > share it once it's done. It's based on Ansible [1] and what it could
> do:
> > > - Provision a cluster on AWS with specified topology given subscription
> > > credential. Support on provisioning on GCP or Azure should be possible
> as
> > > well. This step is optional, as the cluster can be provisioned
> > separately,
> > > or using different approach (e.g. a docker cluster instead of VMs), and
> > if
> > > the cluster is already provisioned, the list of IPs will be passed to
> the
> > > tool.
> > > - Install a pre-configured ZK cluster on all nodes of the cluster,
> > > including all dependencies.
> > > - Support easy update / change state of the cluster both at cluster
> level
> > > (e.g. kill nodes) and at ZK level (e.g. update zoo.cfg and restart ZK).
> > >
> > > We do have some tools internally to provision and deploy ZK cluster but
> > > those tools have dependencies that can't be made public and also they
> > tied
> > > to specific version of ZK and is not exactly what I want (for 1045
> > > validation at least).
> > >
> > > [1] http://docs.ansible.com/ansible/index.html
> > >
> > >
> > > On Fri, Jul 8, 2016 at 6:58 AM, Flavio Junqueira 
> wrote:
> > >
> > > > We could consider using vagrant and something like ducktape (for
> > Kafka):
> > > >
> > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/tutorial+-+set+up+and+run+Kafka+system+tests+with+ducktape
> > > > <
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/tutorial+-+set+up+and+run+Kafka+system+tests+with+ducktape
> > > > >
> > > >
> > > > As for resources, ASF committers can have an msn subscription and we
> > > could
> > > > use some Azure resources for tests. I have actually recently shared
> one
> > > > Azure VM to show Michael a test failure in that setting. The
> > subscription
> > > > doesn't give access to a lot of resources as the monthly credit is
> > small,
> > > > but should be good enough for some distributed tests:
> > > >
> > > >
> > > >
> > >
> >
> http://mail-archives.apache.org/mod_mbox/www-community/201402.mbox/%3ccab56zcwvv5wmh99xaruldi2fvxmuj6r1axe66ul-afpo3cv...@mail.gmail.com%3E
> > > > <
> > > >
> > >
> >
> http://mail-archives.apache.org/mod_mbox/www-community/201402.mbox/%3ccab56zcwvv5wmh99xaruldi2fvxmuj6r1axe66ul-afpo3cv...@mail.gmail.com%3E
> > > > >
> > > >
> > > > -Flavio
> > > >
> > > > > On 08 Jul 2016, at 14:41, Camille Fournier 
> > wrote:
> > > > >
> > > > > These are all good questions.
> > > > >
> > > > > My ultimate hope here is that we can actually get something set up
> so
> > > > that
> > > > > for each release we want to do, we can easily run a standard smoke
> > test
> > > > on
> > > > > this cluster, and potentially leave the cluster available for a few
> > > days
> > > > > for additional testing by the community, to help those of us who do
> > not
> > > > > have an easy way to spin up a ZK cluster at our companies for
> testing
> > > to
> > > > > feel good about vetting a release.
> > > > >
> > > > > I think that a good first step would be to create something that
> can
> > > > > actually deploy a configured ZK on top of this cluster, and then
> > deploy
> > > > > some sort of basic test script on machines that executes, eg, pat's
> > > smoke
> > > > > test as Flavio pointed out. I will admit to being a bit perplexed
> as
> > to
> > > > > what the state of the nodes of this cluster look like when you get
> > > access
> > > > > to them and what needs to be installed on top of them to actually
> do
> > > this
> > > > > sort of automation. It looks like you can provision the nodes with
> an
> > > OS
> > > > on
> > > > > them, but beyond that it looks like we may need to create the
> > > automation
> > > > to
> > > > > install java first, then ZK. There's some very bare bones details
> > here:
> > > > >
> > > > > https://github.com/cncf/cluster
> > > > >
> > > > > *For those of you who have internal processes for vetting ZK, if
> any
> > of
> > > > you
> > > > > have automation for spinning up new ZK servers in a cloud env
> > hopefully
> > > > we
> > > > > can use that to start. Does anyone have that? *I think that's where
> > we
> > > > ne

Re: [VOTE] Apache ZooKeeper release 3.5.2-alpha candidate 1

[Raúl Gutiérrez Segalés]

+1

* ran zk-shell's test suite (all passes:
https://asciinema.org/a/buko9me6x0ct294cba5e9zk49)
* ran an Observer w/ 3.5.2-alpha taking some (light prod traffic) (all
looks good)

Thanks Chris et al!


-rgs

On 4 July 2016 at 05:31, Enrico Olivelli  wrote:

> +1 (non binding)
>
> Tested Apache BookKeeper trunk (4.5.0-SNAPSHOT)
>
> Tested Majordodo (http://majordodo.org). These tests also include
> running Apache BookKeeper 4.4.0 Client using the 3.5.2-alpha java
> client.
>
> Tested  BlazingCache (http://blazingcache.org) . These tests also
> include running Apache BookKeeper 4.4.0 Client using the 3.5.2-alpha
> java client.
>
> I have used the binary artifact published on Maven staging repo
>
> Regards
> Enrico
>
> 2016-07-03 0:54 GMT+02:00 Edward Ribeiro :
> > +1 (non-binding)
> >
> > - built ZK from source
> > - ran all the unit tests
> > - generated and checked javadocs
> > - generated and checked docs
> > - executed few manual test (zkCli.sh) and 4lw
> >
> > Some small issues (imho):
> >
> > - the copyright notice is still dating "2008-2013". It's worth updating
> to
> > the current year?
> > - I consistently ran on an test error equals to the one at
> > https://builds.apache.org/job/ZooKeeper-trunk/2982/console
> > - Also this one:
> >
> https://mail-archives.apache.org/mod_mbox/zookeeper-dev/201601.mbox/%3C1279938263.1283.1453526737790.JavaMail.jenkins@crius%3E
> >
> > - In fact, there were 14 failing tests total (I suspect all of them
> related
> > to the C tests). Any ideas? A couple of flacky tests?
> >
> >
> > Regards,
> > Eddie
> >
> >
> > On Sat, Jul 2, 2016 at 1:46 PM, Rakesh Radhakrishnan <
> > rakeshr.apa...@gmail.com> wrote:
> >
> >> +1
> >>
> >> - built zookeeper jar from source,
> >> - ran unit test cases, few zkCli commands, few four letter words,
> >> - tested few scenarios against Hadoop-2.7.2 version(3 node Kerberos
> secure
> >> cluster environment).
> >>
> >> Thanks Chris for making the release.
> >>
> >> Regards,
> >> Rakesh
> >>
> >> On Sat, Jul 2, 2016 at 7:43 PM, Flavio Junqueira 
> wrote:
> >>
> >> > +1
> >> >
> >> > - Checked license information
> >> > - Ran RAT tool
> >> > - Ran tests
> >> > - Ran some smoke tests
> >> > - Verified digests and signature
> >> > - Checked release notes
> >> >
> >> > All of the above LGTM
> >> >
> >> > -Flavio
> >> >
> >> >
> >> > > On 01 Jul 2016, at 08:45, Chris Nauroth 
> >> > wrote:
> >> > >
> >> > > This is a release candidate for 3.5.2-alpha. The full release notes
> are
> >> > > available at:
> >> > >
> >> > >
> >> >
> >>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310801&v
> >> > > ersion=12331981
> >> > >
> >> > > *** Please download, test and vote by July 5th 2016, 23:59 UTC+0.
> ***
> >> > >
> >> > > Source files:
> >> > >
> http://people.apache.org/~cnauroth/zookeeper-3.5.2-alpha-candidate-1/
> >> > >
> >> > > Maven staging repo:
> >> > >
> >> >
> >>
> https://repository.apache.org/content/groups/staging/org/apache/zookeeper/z
> >> > > ookeeper/3.5.2-alpha/
> >> > >
> >> > > The tag to be voted upon:
> >> > > https://svn.apache.org/repos/asf/zookeeper/tags/release-3.5.2-rc1/
> >> > >
> >> > > ZooKeeper's KEYS file containing PGP keys we use to sign the
> release:
> >> > > http://www.apache.org/dist/zookeeper/KEYS
> >> > >
> >> > > Should we release this candidate?
> >> > >
> >> > >
> >> > > --Chris Nauroth
> >> > >
> >> > >
> >> > >
> >> > >
> >> >
> >> >
> >>
>

Re: Status: Apache ZooKeeper release 3.5.2-alpha candidate 1

[Raúl Gutiérrez Segalés]

I'll cast my vote today, after I see this behave for a while at a staging
cluster at work.

Sorry for the lag.

-rgs
On Jul 7, 2016 12:58 AM, "Flavio P JUNQUEIRA"  wrote:

Hey PMC,

Where are your votes?

-Flavio
On 7 Jul 2016 5:51 a.m., "Chris Nauroth"  wrote:

> I need to leave for vacation now.  Unfortunately, the binding votes have
> not rolled in, so I won't be able to complete the release process before I
> leave.  I'll be available again on Monday, 7/18.  I can pick up the work
> then.  Alternatively, if the votes comes in during my absence and someone
> else wants to complete the release, please feel free.  If we go that way,
> then I could potentially pick up 3.5.3 release manager duties from Patrick
> to make up for it.
>
> --Chris Nauroth
>
>
>
>
> On 7/6/16, 8:51 AM, "Chris Nauroth"  wrote:
>
> >With inclusion of my own +1 (non-binding), the current tally on the
> >[VOTE] for release 3.5.2-alpha candidate 1 is:
> >
> >1 +1 (binding)
> >4 +1 (non-binding)
> >
> >Can we please have 2 more PMC members cast a binding vote to push this
> >[VOTE] to completion?  Thank you.
> >
> >--Chris Nauroth
>
>

Re: svn commit: r1747408 - in /zookeeper/trunk: CHANGES.txt src/java/main/org/apache/zookeeper/server/quorum/QuorumCnxManager.java

[Raúl Gutiérrez Segalés]

Hey Pat,

On 14 June 2016 at 21:18, Patrick Hunt  wrote:

> Raul, what's the status on this? Seems like trunk was committed but not
> 3.5? We don't want to lose track.
>

Yup - I was waiting on Chris before pushing to 3.5.

@Chris: may I push?


-rgs



>
> Patrick
>
> On Wed, Jun 8, 2016 at 8:43 AM,  wrote:
>
>> Author: rgs
>> Date: Wed Jun  8 15:43:15 2016
>> New Revision: 1747408
>>
>> URL: http://svn.apache.org/viewvc?rev=1747408&view=rev
>> Log:
>> ZOOKEEPER-2442: Socket leak in QuorumCnxManager connectOne
>> (Michael Han via rgs)
>>
>> Modified:
>> zookeeper/trunk/CHANGES.txt
>>
>> zookeeper/trunk/src/java/main/org/apache/zookeeper/server/quorum/QuorumCnxManager.java
>>
>> Modified: zookeeper/trunk/CHANGES.txt
>> URL:
>> http://svn.apache.org/viewvc/zookeeper/trunk/CHANGES.txt?rev=1747408&r1=1747407&r2=1747408&view=diff
>>
>> ==
>> --- zookeeper/trunk/CHANGES.txt (original)
>> +++ zookeeper/trunk/CHANGES.txt Wed Jun  8 15:43:15 2016
>> @@ -308,6 +308,9 @@ BUGFIXES:
>>ZOOKEEPER-2405: getTGT() in Login.java mishandles confidential
>>information (Michael Han via phunt)
>>
>> +  ZOOKEEPER-2442: Socket leak in QuorumCnxManager connectOne
>> +  (Michael Han via rgs)
>> +
>>  IMPROVEMENTS:
>>ZOOKEEPER-2024 Major throughput improvement with mixed workloads (Kfir
>> Lev-Ari via shralex)
>>
>>
>> Modified:
>> zookeeper/trunk/src/java/main/org/apache/zookeeper/server/quorum/QuorumCnxManager.java
>> URL:
>> http://svn.apache.org/viewvc/zookeeper/trunk/src/java/main/org/apache/zookeeper/server/quorum/QuorumCnxManager.java?rev=1747408&r1=1747407&r2=1747408&view=diff
>>
>> ==
>> ---
>> zookeeper/trunk/src/java/main/org/apache/zookeeper/server/quorum/QuorumCnxManager.java
>> (original)
>> +++
>> zookeeper/trunk/src/java/main/org/apache/zookeeper/server/quorum/QuorumCnxManager.java
>> Wed Jun  8 15:43:15 2016
>> @@ -237,9 +237,7 @@ public class QuorumCnxManager {
>>   * @param sid
>>   */
>>  public void testInitiateConnection(long sid) throws Exception {
>> -if (LOG.isDebugEnabled()) {
>> -LOG.debug("Opening channel to server " + sid);
>> -}
>> +LOG.debug("Opening channel to server " + sid);
>>  Socket sock = new Socket();
>>  setSockOpts(sock);
>>  sock.connect(self.getVotingView().get(sid).electionAddr, cnxTO);
>> @@ -434,17 +432,14 @@ public class QuorumCnxManager {
>>  LOG.debug("There is a connection already for server " + sid);
>>  return true;
>>  }
>> -try {
>>
>> - if (LOG.isDebugEnabled()) {
>> - LOG.debug("Opening channel to server " + sid);
>> - }
>> - Socket sock = new Socket();
>> +Socket sock = null;
>> +try {
>> + LOG.debug("Opening channel to server " + sid);
>> + sock = new Socket();
>>   setSockOpts(sock);
>>   sock.connect(electionAddr, cnxTO);
>> - if (LOG.isDebugEnabled()) {
>> - LOG.debug("Connected to server " + sid);
>> - }
>> + LOG.debug("Connected to server " + sid);
>>   initiateConnection(sock, sid);
>>   return true;
>>   } catch (UnresolvedAddressException e) {
>> @@ -454,11 +449,13 @@ public class QuorumCnxManager {
>>   // detail.
>>   LOG.warn("Cannot open channel to " + sid
>>   + " at election address " + electionAddr, e);
>> + closeSocket(sock);
>>   throw e;
>>   } catch (IOException e) {
>>   LOG.warn("Cannot open channel to " + sid
>>   + " at election address " + electionAddr,
>>   e);
>> + closeSocket(sock);
>>   return false;
>>   }
>>
>> @@ -574,6 +571,10 @@ public class QuorumCnxManager {
>>   *Reference to socket
>>   */
>>  private void closeSocket(Socket sock) {
>> +if (sock == null) {
>> +return;
>> +}
>> +
>>  try {
>>  sock.close();
>>  } catch (IOException ie) {
>> @@ -614,7 +615,7 @@ public class QuorumCnxManager {
>>  public void run() {
>>  int numRetries = 0;
>>  InetSocketAddress addr;
>> -
>> +Socket client = null;
>>  while((!shutdown) && (numRetries < 3)){
>>  try {
>>  ss = new ServerSocket();
>> @@ -632,7 +633,7 @@ public class QuorumCnxManager {
>>  setName(addr.toString());
>>  ss.bind(addr);
>>  while (!shutdown) {
>> -Socket client = ss.accept();
>> +client = ss.accept();
>>  setSockOpts(client);
>>  L

Re: Zookeeper 3.4.8 is bundled with old version of Netty:jar

[Raúl Gutiérrez Segalés]

On 7 June 2016 at 18:48, Patrick Hunt  wrote:

> There is a jira for this already. Someone want to drive this one?
>
> https://issues.apache.org/jira/browse/ZOOKEEPER-2399


So are we good in the 3.4 branch after:

https://github.com/apache/zookeeper/commit/f0a49567d545bd6584cb8ece2d491dc6c65174f8

or would we still need to backup netty 4.x support to that branch
(eventually)?


-rgs



>
>
> Patrick
>
> On Mon, Jun 6, 2016 at 1:51 PM, Michael Han  wrote:
>
> > FYI branch 3.4 was recently patched with Netty 3.10 to address some of
> the
> > security concerns as described in ZOOKEEPER-2423: Upgrade Netty version
> due
> > to security vulnerability.
> >
> >
> >
> https://github.com/apache/zookeeper/commit/f0a49567d545bd6584cb8ece2d491dc6c65174f8
> >
> >
> >
> >
> > On Mon, Jun 6, 2016 at 1:38 PM, Hegde, Pallavi 
> > wrote:
> >
> > > Hello,
> > > We are currently facing some security issues with Zookeeper version
> 3.4.7
> > > & 3.4.8, since its bundled with very old version of Netty:jar, version
> > > 3.7.0.
> > > Could you address this issue in future Zookeeper releases by packaging
> it
> > > with Netty.jar-4.0.27, or higher version of Netty:jar? I am sure this
> > will
> > > help many other issues including security violations.
> > >
> > > Thanks
> > > Pallavi
> > >
> > >
> >
> >
> > --
> > Cheers
> > Michael.
> >
>

Re: TTL Nodes: ZOOKEEPER-2169

[Raúl Gutiérrez Segalés]

On 15 May 2016 at 21:01, Jordan Zimmerman 
wrote:

> Very good point. I guess we could add fields for future growth. So,
> something like:
>
>   class CreateRequest2 {
>ustring path;
>buffer data;
>vector acl;
>int flags;
>long ttl;
>long future1;
>long future2;
>long future3;
>long future4;
>}
>
> Or is that silly?
>

It isn't, except it won't work now that I come to think of it. The way
read-only support is handled is by not declaring the new (boolean) field in
jute but by just trying to read it directly, i.e.:

boolean readOnly = false;
try {
readOnly = bia.readBool("readOnly");
cnxn.isOldClient = false;
} catch (IOException e) {
// this is ok -- just a packet from an old client which
// doesn't contain readOnly field
LOG.warn("Connection request from old client "
+ cnxn.getRemoteSocketAddress()
+ "; will be dropped if server is in r-o mode");
}

which destroys encapsulation. So more of those hacks is probably not
sustainable. Moving those hacks into the jute compiler so that it handles
optional fields (like the thrift compiler does) is probably more
sustainable, but not a trivial effort. But, given that moving to thrift (or
something else) is probably way harder we could explore that route.


>
> Also, I know that Flavio and Patrick have been discussion file format
> issues. It would be great if we could fix the hackiness of the
> ephemeralOwner. Any thoughts on that?
>

Same as above — we need to make jute smarter or move to thrift to solve it.
I suspect that anything else would be too much of a hack.

So, back to square one: we are tied with specialized classes for every new
operation. At which point, we could probably introduce Stat2 to get away of
the client-side ephemeralOwner hack. For the server-side, we are probably
out of luck for now.

Thoughts?


-rgs



> -Jordan
>
> > On May 15, 2016, at 12:18 PM, Raúl Gutiérrez Segalés <
> r...@itevenworks.net> wrote:
> >
> > Hey Jordan,
> >
> > On 8 May 2016 at 10:50, Jordan Zimmerman 
> wrote:
> >
> >> Flavio,
> >>
> >> Do you think you can review and merge this change? I think the ZK
> >> community would really like this feature.
> >>
> >
> > I am doing another pass now. While at it, I am thinking of this new
> request
> > type that's being introduced:
> >
> > ```
> >   class CreateTTLRequest {
> >ustring path;
> >buffer data;
> >vector acl;
> >int flags;
> >long ttl;
> >}
> > ```
> >
> > Should we make this more generic? This could very well be named
> > CreateRequest2.
> >
> > In the future, we could easily extend it by adding more fields. This is
> how
> > we extended the ConnectRequest class to support read-only in a backwards
> > compatible way, for instance.
> >
> > What do you all think? Is it worthwhile to make the (jute) type
> extensible
> > as opposed to having to many specialized request types?
> >
> >
> > -rgs
> >
> >
> >
> >> -Jordan
>
>

Re: TTL Nodes: ZOOKEEPER-2169

[Raúl Gutiérrez Segalés]

Hey Jordan,

On 8 May 2016 at 10:50, Jordan Zimmerman  wrote:

> Flavio,
>
> Do you think you can review and merge this change? I think the ZK
> community would really like this feature.
>

I am doing another pass now. While at it, I am thinking of this new request
type that's being introduced:

```
   class CreateTTLRequest {
ustring path;
buffer data;
vector acl;
int flags;
long ttl;
}
```

Should we make this more generic? This could very well be named
CreateRequest2.

In the future, we could easily extend it by adding more fields. This is how
we extended the ConnectRequest class to support read-only in a backwards
compatible way, for instance.

What do you all think? Is it worthwhile to make the (jute) type extensible
as opposed to having to many specialized request types?


-rgs



> -Jordan

Re: We need to prioritize getting logging fixed in trunk/3.5

[Raúl Gutiérrez Segalés]

+1. This sounds like a good plan. Thanks Chris!
On Mar 16, 2016 9:36 AM, "Chris Nauroth"  wrote:

> We now have multiple binding +1's for a revert.  To finalize the plan,
> here is what I propose:
>
> 1. Full revert of ZOOKEEPER-1371, targeted to 3.5.2.
>
> 2. Retarget ZOOKEEPER-1371 to 3.5.3 with the scope limited to just the
> SLF4J logging API changes.  We'd omit the build changes that dropped the
> SLF4J-Log4J 1.2 binding from the distro.  This would be a
> backwards-compatible change, and I believe it was the original intent of
> ZOOKEEPER-1371.  This is not critical to complete for 3.5.3.  I'm just
> pushing it ahead to the next version.
>
> 3. Retarget ZOOKEEPER-2342 to 3.6.0 for tracking Log4J 2 migration.  This
> will have to happen someday since Log4J 1 is end of life, but it will
> likely be backwards-incompatible, and the change provides no value add to
> justify it for the 3.5 line.
>
> I'll wait 24 hours before proceeding with a revert in case anyone else
> wants to comment.
>
> --Chris Nauroth
>
>
>
>
> On 3/16/16, 6:47 AM, "Camille Fournier"  wrote:
>
> >I'm a strong +1 to get this fixed even if it requires reverting the
> >original patch. Broken logging is huge. Let's do whatever is expedient and
> >sensible to fix it.
> >
> >On Tue, Mar 15, 2016 at 7:27 PM, Chris Nauroth 
> >wrote:
> >
> >> Yes, that's basically my assessment too.  Copy-pasting my earlier
> >>comment
> >> from ZOOKEEPER-1371:
> >>
> >> "After this patch, ZooKeeper no longer produces any logging, because
> >>there
> >> is no SLF4J binding jar available on the runtime classpath."
> >>
> >>
> >> There is no compatibility problem with switching to SLF4J exclusively as
> >> our API of choice for logging instead of calling the Log4J API.  The
> >> incompatible part is that the distro isn't shipping with any SLF4J
> >>binding
> >> included.  Perhaps we can do a partial revert of just that part of
> >> ZOOKEEPER-1371.
> >>
> >> --Chris Nauroth
> >>
> >>
> >>
> >>
> >> On 3/15/16, 11:54 AM, "Patrick Hunt"  wrote:
> >>
> >> >Hm, I started looking at the original patch in more depth:
> >> >
> >>
> >>
> https://issues.apache.org/jira/secure/attachment/12773684/ZOOKEEPER-1371-
> >>0
> >> >5.patch
> >> >
> >> >is the real root issue 2342 is trying to address the following line
> >> >change:
> >> >
> >> >- >> >transitive="false"/>
> >> >+ >> >transitive="false" conf="test->default"/>
> >> >
> >> >Specifically that we changed from runtime to test only for this
> >> >dependency? Perhaps we just need to revert that? I see some other
> >> >magic happening in the build.xml file that I don't quite understand -
> >> >adding a new target and NoLog4j... references.
> >> >
> >> >Raul perhaps you can give more insight since it seems like you worked
> >> >on 1371 most recently?
> >> >
> >> >Patrick
> >> >
> >> >
> >> >On Tue, Mar 15, 2016 at 11:41 AM, Chris Nauroth
> >> > wrote:
> >> >> I agree.  Even if we don't fully understand every minute technical
> >> >>detail
> >> >> of Log4J 2 vs. Log4J 1, I think we've learned enough from my
> >> >> work-in-progress patch to declare that a migration is too risky for
> >>the
> >> >> 3.5 line.  Reverting ZOOKEEPER-1371 (the earlier
> >>backwards-incompatible
> >> >> logging change) is the better choice for the interest of proceeding
> >>with
> >> >> 3.5 releases.
> >> >>
> >> >> --Chris Nauroth
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> On 3/15/16, 11:23 AM, "Patrick Hunt"  wrote:
> >> >>
> >> >>>I just commented on ZOOKEEPER-2342... not sure I fully understand all
> >> >>>the issues to be honest. Given how much we're trying to do in 3.5 it
> >> >>>seems like it would be prudent to wait on 1371 until 3.6... IMO. :-)
> >> >>>
> >> >>>Patrick
> >> >>>
> >> >>>On Tue, Mar 15, 2016 at 11:15 AM, Chris Nauroth
> >> >>> wrote:
> >>  At this point, I am +1 for a revert of the patch that introduced
> >>the
> >>  problem (ZOOKEEPER-1371).  We need more time to come up with a
> >> migration
> >>  path to Log4J 2 that minimizes impact on operators.  That will take
> >> time,
> >>  and I'd prefer that we don't hold up 3.5.2-alpha for it.
> >> 
> >>  --Chris Nauroth
> >> 
> >> 
> >> 
> >> 
> >>  On 3/15/16, 11:08 AM, "Patrick Hunt"  wrote:
> >> 
> >> >Hi folks, can we prioritize getting logging fixed? It's causing
> >>test
> >> >failures, e.g.:
> >> >
> >> https://builds.apache.org/job/ZooKeeper-trunk/2850/artifact/trunk/buil
> >> >d/
> >> >tm
> >> >p/zk.log
> >> >
> >> >This is the jira:
> >> >https://issues.apache.org/jira/browse/ZOOKEEPER-2342
> >> >
> >> >
> >> >Perhaps we should revert the change that caused this in the first
> >> >place.
> >> >
> >> >Patrick
> >> >
> >> 
> >> >>>
> >> >>
> >> >
> >>
> >>
>
>

Re: github.com zookeeper pull requests in "limbo"

[Raúl Gutiérrez Segalés]

I am +1 on moving to git as well.

What did it take for other Apache projects?

-rgs
On Mar 10, 2016 7:09 AM, "Flavio Junqueira"  wrote:

> I'd like to move to git...
>
> -Flavio
>
> > On 10 Mar 2016, at 15:07, Patrick Hunt  wrote:
> >
> > I could see us turning it on if we move to git as our source repo.
> > However I'm recommending we turn it _off_ until then. Interestingly
> > there's a discussion going on right now in apache infra about this
> > (github mirrors and PRs), I'll let you know.
> >
> > That said, is there any interest to move to git and drop svn? I'd like
> > to move personally, hadoop moved a while back and lucene/solr just
> > moved recently. I think it's a pretty well worn path if we're
> > interested to do so.
> >
> > Patrick
> >
> > On Thu, Mar 10, 2016 at 12:36 AM, Flavio Junqueira 
> wrote:
> >> I did mean turning it on, which is apparently the opposite of what Pat
> is proposing. Sorry about the confusion. =)
> >>
> >> -Flavio
> >>
> >>> On 10 Mar 2016, at 08:01, Raúl Gutiérrez Segalés 
> wrote:
> >>>
> >>> On Mar 9, 2016 11:26 PM, "Flavio Junqueira"  wrote:
> >>>>
> >>>> +1 for accepting requesting to infra to accept PRs via github. We've
> done
> >>> the transition in BookKeeper and have been doing it in Kafka for a
> while,
> >>> it works pretty well.
> >>>
> >>> Wait - you mean the other way around? Pat suggested turning off PRs in
> >>> github...
> >>>
> >>> -rgs
> >>>
> >>>>
> >>>> I'm happy you brought this up, Pay, I've been thinking about it.
> >>>>
> >>>> -Flavio
> >>>>
> >>>>> On 10 Mar 2016, at 00:38, Patrick Hunt  wrote:
> >>>>>
> >>>>> Hi folks. If you look on github.com you'll see a number of pull
> >>>>> request (41 atm) that are effectively in limbo given we don't accept
> >>>>> pull requests that way:
> >>>>> https://github.com/apache/zookeeper/pulls
> >>>>>
> >>>>> rather through our Jira process
> >>>>>
> https://cwiki.apache.org/confluence/display/ZOOKEEPER/HowToContribute
> >>>>>
> >>>>> someday we might move to git, but for the time being it seems like we
> >>>>> should do something about this.
> >>>>>
> >>>>> I was thinking about contacting Apache infra and asking them if they
> >>>>> can turn off accepting pull requests at github.com, just wanted to
> >>>>> check with dev@ to see if this makes sense or do folks want to do
> >>>>> something else? If I don't hear back anything negative in the next
> few
> >>>>> days I'll ping infra about shutting down acceptance of pull requests
> >>>>> (may not be possible but I'll check). I'm not talking about removing
> >>>>> the mirror to be clear, just shutting down accepting pull requests on
> >>>>> the mirror.
> >>>>>
> >>>>> Patrick
> >>>>>
> >>>>> ps. regardless we probably need to get back to everyone and ask them
> >>>>> to follow the HTC page I don't seem to be able to close out the
> >>>>> PRs, just comment on them, so that's going to be a possible issue as
> >>>>> well arg.
> >>>>
> >>
>
>

Re: github.com zookeeper pull requests in "limbo"

[Raúl Gutiérrez Segalés]

On Mar 9, 2016 11:26 PM, "Flavio Junqueira"  wrote:
>
> +1 for accepting requesting to infra to accept PRs via github. We've done
the transition in BookKeeper and have been doing it in Kafka for a while,
it works pretty well.

Wait - you mean the other way around? Pat suggested turning off PRs in
github...

-rgs

>
> I'm happy you brought this up, Pay, I've been thinking about it.
>
> -Flavio
>
> > On 10 Mar 2016, at 00:38, Patrick Hunt  wrote:
> >
> > Hi folks. If you look on github.com you'll see a number of pull
> > request (41 atm) that are effectively in limbo given we don't accept
> > pull requests that way:
> > https://github.com/apache/zookeeper/pulls
> >
> > rather through our Jira process
> > https://cwiki.apache.org/confluence/display/ZOOKEEPER/HowToContribute
> >
> > someday we might move to git, but for the time being it seems like we
> > should do something about this.
> >
> > I was thinking about contacting Apache infra and asking them if they
> > can turn off accepting pull requests at github.com, just wanted to
> > check with dev@ to see if this makes sense or do folks want to do
> > something else? If I don't hear back anything negative in the next few
> > days I'll ping infra about shutting down acceptance of pull requests
> > (may not be possible but I'll check). I'm not talking about removing
> > the mirror to be clear, just shutting down accepting pull requests on
> > the mirror.
> >
> > Patrick
> >
> > ps. regardless we probably need to get back to everyone and ask them
> > to follow the HTC page I don't seem to be able to close out the
> > PRs, just comment on them, so that's going to be a possible issue as
> > well arg.
>

[ANNOUNCE] Apache ZooKeeper 3.4.8

[Raúl Gutiérrez Segalés]

The Apache ZooKeeper team is proud to announce Apache ZooKeeper version
3.4.8.

ZooKeeper is a high-performance coordination service for distributed
applications. It exposes common services - such as naming,
configuration management, synchronization, and group services - in a
simple interface so you don't have to write them from scratch. You can
use it off-the-shelf to implement consensus, group management, leader
election, and presence protocols. And you can build on it for your
own, specific needs.

For ZooKeeper release details and downloads, visit:
http://zookeeper.apache.org/releases.html

ZooKeeper 3.4.8 Release Notes are at:
http://zookeeper.apache.org/doc/r3.4.8/releasenotes.html

We would like to thank the contributors that made the release possible.


The ZooKeeper Team

Re: [VOTE] Apache ZooKeeper release 3.4.8 candidate 0

[Raúl Gutiérrez Segalés]

Hi,

Quick reminder that the vote closes up on the 20th, it would be great to
have more votes and feedback this week. Thanks!


-rgs

On 5 February 2016 at 20:00, Raúl Gutiérrez Segalés 
wrote:

> This is a bugfix release candidate for 3.4.8. It fixes 9 issues, most
> notably a deadlock when shutting down ZooKeeper.
>
> The full release notes is available at:
>
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310801&version=12326517
>
> *** Please download, test and vote by February 20th 2016, 23:59 UTC+0. ***
>
> Source files:
> http://people.apache.org/~rgs/zookeeper-3-4-8-rc0/
>
> Maven staging repo:
>
> https://repository.apache.org/content/groups/staging/org/apache/zookeeper/zookeeper/3.4.8/
>
> The tag to be voted upon:
> https://svn.apache.org/repos/asf/zookeeper/tags/release-3.4.8-rc0
>
> ZooKeeper's KEYS file containing PGP keys we use to sign the release:
> http://www.apache.org/dist/zookeeper/KEYS
>
> Should we release this candidate?
>
> Note that the approval is by lazy majority according to the bylaws and
> only PMC votes are binding.
>
>
> -rgs
>

[VOTE] Apache ZooKeeper release 3.4.8 candidate 0

[Raúl Gutiérrez Segalés]

This is a bugfix release candidate for 3.4.8. It fixes 9 issues, most
notably a deadlock when shutting down ZooKeeper.

The full release notes is available at:

https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310801&version=12326517

*** Please download, test and vote by February 20th 2016, 23:59 UTC+0. ***

Source files:
http://people.apache.org/~rgs/zookeeper-3-4-8-rc0/

Maven staging repo:
https://repository.apache.org/content/groups/staging/org/apache/zookeeper/zookeeper/3.4.8/

The tag to be voted upon:
https://svn.apache.org/repos/asf/zookeeper/tags/release-3.4.8-rc0

ZooKeeper's KEYS file containing PGP keys we use to sign the release:
http://www.apache.org/dist/zookeeper/KEYS

Should we release this candidate?

Note that the approval is by lazy majority according to the bylaws and only
PMC votes are binding.


-rgs

3.4.8 release schedule

[Raúl Gutiérrez Segalés]

Hi all,

I'll be doing the release management for 3.4.8. Initially, we wanted to
just have the fix for the shutdown synchronization issue that affected
3.4.7. But then a few more - potentially important - issues came up.

To avoid blocking people who were already waiting on the fixes in 3.4.7,
I'll cut an RC for 3.4.8 tonight and we'll move on from there.

Hopefully, we can have 3.4.9 with the issues currently in-flight not much
later this year.

Sounds reasonable?

-rgs

Re: Zookeeper 3.4.7 release and future

[Raúl Gutiérrez Segalés]

Hi Jerry,


On 31 January 2016 at 17:59, Jerry He  wrote:

> Hi, Chris
>
> Thanks for the info!
>
> I will watch for any 3.4.8 announcement!
>

We should have an RC soon, see: https://goo.gl/PC0gle


-rgs



>
> Jerry
>
> On Sun, Jan 31, 2016 at 3:37 PM, Chris Nauroth 
> wrote:
>
> > Hello Jerry,
> >
> > We decided to retract the 3.4.7 release after discovering a critical bug.
> > We are currently in the process of closing down a plan for a 3.4.8
> > release, which is mostly intended to fix that critical bug.  At this
> > point, it looks likely that we'll create a release candidate next week.
> > If you'd like to keep track of status, then I suggest watching this list
> > for an announcement of a release candidate.
> >
> > --Chris Nauroth
> >
> >
> >
> >
> > On 1/30/16, 12:31 PM, "Jerry He"  wrote:
> >
> > >Hello,
> > >
> > >There was announcement that Zookeeper 3.4.7 was released last December.
> > >
> > >But it is not listed in this release page:
> > >http://zookeeper.apache.org/releases.html
> > >
> > >And the 'current' in the download page still points to 3.4.6:
> > >http://archive.apache.org/dist/zookeeper/current/
> > >
> > >What is the real status of this release?
> > >
> > >HBase 1.2 version decides not to use Zookeeper 3.4.7.  See:
> > >https://issues.apache.org/jira/browse/HBASE-14979
> > >https://issues.apache.org/jira/browse/ZOOKEEPER-2347
> > >
> > >Anything in the plan for release after Zookeeper 3.4.7?
> > >
> > >Thank you.
> > >
> > >Jerry
> >
> >
>

Re: 3.4.8 release

[Raúl Gutiérrez Segalés]

On 29 January 2016 at 10:23, Flavio Junqueira  wrote:

> Give me until the end of today to have a look at ZK-2247. Rakesh has put
> the effort to prepare the patch, so I'd like to consider it. If it is not
> ready, then let's push it to 3.4.9. Does it sound good, Raul?
>

Yeah that's reasonable. I actually won't be able to cut an RC until Sunday,
so we have the whole weekend for that patch get more reviews :-) Thanks
Flavio!


-rgs




>
> -Flavio
>
> > On 29 Jan 2016, at 10:20, Raúl Gutiérrez Segalés 
> wrote:
> >
> > Ok - lets punt them to 3.4.9 then.
> >
> >
> > -rgs
> >
> > On 29 January 2016 at 10:10, Chris Nauroth 
> wrote:
> >
> >> +1 for expediting the 3.4.8 release.  Our goal was simply to correct the
> >> critical bug discovered late in 3.4.7.  Any patches more than that can
> be
> >> deferred to a 3.4.9 at a later date.
> >>
> >> --Chris Nauroth
> >>
> >>
> >>
> >>
> >> On 1/29/16, 10:06 AM, "Flavio Junqueira"  wrote:
> >>
> >>> +1
> >>>
> >>>> On 29 Jan 2016, at 10:02, Ted Yu  wrote:
> >>>>
> >>>> ZOOKEEPER-2355 is in Open state as of now.
> >>>>
> >>>> My two cents:
> >>>>
> >>>> 3.4.7 has been retracted.
> >>>> It would be nice to get 3.4.8 out the door soon so that zookeeper
> users
> >>>> can
> >>>> pick up bug fixes in between 3.4.6 and 3.4 branch.
> >>>>
> >>>> On Thu, Jan 28, 2016 at 8:57 AM, Raúl Gutiérrez Segalés
> >>>>  >>>>> wrote:
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>> On 28 January 2016 at 07:07, Talluri, Chandra <
> >>>>> chandra.tall...@fmr.com.invalid> wrote:
> >>>>>
> >>>>>> Thanks for the updates.
> >>>>>>
> >>>>>> When can we expect 3.4.8?
> >>>>>>
> >>>>>
> >>>>> I think we need to decide if we want to include these patches:
> >>>>>
> >>>>> https://issues.apache.org/jira/browse/ZOOKEEPER-2355
> >>>>> https://issues.apache.org/jira/browse/ZOOKEEPER-2247
> >>>>>
> >>>>> They seem to be almost ready, though there might be some subtleties
> >>>>> left to
> >>>>> be addressed.
> >>>>>
> >>>>>
> >>>>>> What are the plans for 3.5.*  stable version release?
> >>>>>>
> >>>>>
> >>>>> The general plan for making 3.5 stable is here:
> >>>>>
> >>>>> http://markmail.org/message/ymxliy2rrwjc2pmo
> >>>>>
> >>>>> I believe Chris Nauroth will be the RM for the upcoming 3.5.2
> release.
> >>>>>
> >>>>>
> >>>>> -rgs
> >>>>>
> >>>
> >>>
> >>
> >>
>
>

Re: 3.4.8 release

[Raúl Gutiérrez Segalés]

Ok - lets punt them to 3.4.9 then.


-rgs

On 29 January 2016 at 10:10, Chris Nauroth  wrote:

> +1 for expediting the 3.4.8 release.  Our goal was simply to correct the
> critical bug discovered late in 3.4.7.  Any patches more than that can be
> deferred to a 3.4.9 at a later date.
>
> --Chris Nauroth
>
>
>
>
> On 1/29/16, 10:06 AM, "Flavio Junqueira"  wrote:
>
> >+1
> >
> >> On 29 Jan 2016, at 10:02, Ted Yu  wrote:
> >>
> >> ZOOKEEPER-2355 is in Open state as of now.
> >>
> >> My two cents:
> >>
> >> 3.4.7 has been retracted.
> >> It would be nice to get 3.4.8 out the door soon so that zookeeper users
> >>can
> >> pick up bug fixes in between 3.4.6 and 3.4 branch.
> >>
> >> On Thu, Jan 28, 2016 at 8:57 AM, Raúl Gutiérrez Segalés
> >> >>> wrote:
> >>
> >>> Hi,
> >>>
> >>> On 28 January 2016 at 07:07, Talluri, Chandra <
> >>> chandra.tall...@fmr.com.invalid> wrote:
> >>>
> >>>> Thanks for the updates.
> >>>>
> >>>> When can we expect 3.4.8?
> >>>>
> >>>
> >>> I think we need to decide if we want to include these patches:
> >>>
> >>> https://issues.apache.org/jira/browse/ZOOKEEPER-2355
> >>> https://issues.apache.org/jira/browse/ZOOKEEPER-2247
> >>>
> >>> They seem to be almost ready, though there might be some subtleties
> >>>left to
> >>> be addressed.
> >>>
> >>>
> >>>> What are the plans for 3.5.*  stable version release?
> >>>>
> >>>
> >>> The general plan for making 3.5 stable is here:
> >>>
> >>> http://markmail.org/message/ymxliy2rrwjc2pmo
> >>>
> >>> I believe Chris Nauroth will be the RM for the upcoming 3.5.2 release.
> >>>
> >>>
> >>> -rgs
> >>>
> >
> >
>
>

Re: 3.4.8 release

[Raúl Gutiérrez Segalés]

Hi,

On 28 January 2016 at 07:07, Talluri, Chandra <
chandra.tall...@fmr.com.invalid> wrote:

> Thanks for the updates.
>
> When can we expect 3.4.8?
>

I think we need to decide if we want to include these patches:

https://issues.apache.org/jira/browse/ZOOKEEPER-2355
https://issues.apache.org/jira/browse/ZOOKEEPER-2247

They seem to be almost ready, though there might be some subtleties left to
be addressed.


> What are the plans for 3.5.*  stable version release?
>

The general plan for making 3.5 stable is here:

http://markmail.org/message/ymxliy2rrwjc2pmo

I believe Chris Nauroth will be the RM for the upcoming 3.5.2 release.


-rgs

Re: Apache ZooKeeper Meetup - Jan 27, Cloudera HQ

[Raúl Gutiérrez Segalés]

Thanks for setting this up Flavio! See you all there!

On 20 January 2016 at 08:35, Flavio Junqueira  wrote:

> Hello!
>
> We are organizing a meetup in the Bay Area next week, and I'd love to see
> everyone who is the area there. Please check the event page and don't
> forget to RSVP:
>
> https://www.eventbrite.com/e/apache-zookeeper-meetup-tickets-20906479844 <
> https://www.eventbrite.com/e/apache-zookeeper-meetup-tickets-20906479844>
>
> Also, it'd be great to have folks speaking about stuff around ZK. If
> you're interested, let me know and I'll add you to the agenda.
>
> See you there!
>
> -Flavio

3.4.8 release

[Raúl Gutiérrez Segalés]

Hi,

I'd like to prepare an RC for 3.4.8 soonish (hopefully, this week). For
now, this is the only blocker I can see:

ZOOKEEPER-2355: Ephemeral node is never deleted if follower fails while
reading the proposal packet

Given the magnitude of that bug, I think it should go out with this
release.

Any other JIRA that should be included?


-rgs

Re: [VOTE] Remove release 3.4.7 from mirrors and Web site references

[Raúl Gutiérrez Segalés]

On 5 January 2016 at 01:44, Flavio Junqueira  wrote:

> With 4 +1 PMC votes(Flavio, Michi, Camille, Ivan) and one +1 committer
> vote (Chris), the vote passes. We'll remove 3.4.7 references from mirrors
> and web site as proposed.
>
> Thank you all for voting.
>

Thanks Flavio - I removed all the references to 3.4.7 (but left the docs
around, since the docs for 3.3.1 are still around as well).


-rgs

Re: [DISCUSS] Remove 3.4.7 from mirrors and the Web site references

[Raúl Gutiérrez Segalés]

Hi,

On 18 December 2015 at 01:49, Flavio Junqueira  wrote:

> The plan is indeed to cut an RC for 3.4.8 early January with this issue
> fixed. Raul volunteered to do it, but because folks will be away during the
> holidays, I'm suggesting we wait until after the holidays to bootstrap the
> process. But, if Raul wants to cut an RC now, I'm totally fine with it as
> long as we give enough time to folks to review it and vote.
>

I rather do it now than later. That is, assuming we have enough PMCs around
to make vote a pass...


>
> A slightly separate issue is what to do with 3.4.7. It is a bad release
> and we don't want folks using it, so I started this discussion to determine
> what to do with it. I'm suggesting we remove it from mirrors and from the
> web site, just like we did with 3.3.1 back in the day.
>

+1 on removing 3.4.7. If others speak up soon I can go ahead and remove
3.4.7 from the website/archive and get started with the RC..


-rgs

Re: Adding a new API to ZooKeeper 3.4? (ZOOKEEPER-1962/ZOOKEEPER-2260)

[Raúl Gutiérrez Segalés]

Hi Tim,

On 8 December 2015 at 18:58, Crowder Tim  wrote:

> Tangentially related question...
>
> I have a C++ cli for zookeeper modeled after unix shell.
> It has ls (with lots of options including recursive, long, and ACL
> listing),
> cp, touch, cat, etc. And command/filename completion and history.
>
> I've secured permission from work (Yahoo) to contribute it.
> How do I go about submitting it?
>

I have a similar utility (but for Python): https://github.com/rgs1/zk_shell

My initial thought was that keeping it out of tree gives you more liberty
with
releases.. Maybe it could start out of tree then we could merge it?


-rgs

[ANNOUNCE] Apache ZooKeeper 3.4.7

[Raúl Gutiérrez Segalés]

The Apache ZooKeeper team is proud to announce Apache ZooKeeper version
3.4.7

ZooKeeper is a high-performance coordination service for distributed
applications. It exposes common services - such as naming,
configuration management, synchronization, and group services - in a
simple interface so you don't have to write them from scratch. You can
use it off-the-shelf to implement consensus, group management, leader
election, and presence protocols. And you can build on it for your
own, specific needs.

For ZooKeeper release details and downloads, visit:
http://zookeeper.apache.org/releases.html

ZooKeeper 3.4.7 Release Notes are at:
http://zookeeper.apache.org/doc/r3.4.7/releasenotes.html

We would like to thank the contributors that made the release possible.

Regards,

The ZooKeeper Team

Re: PATCH: fix ZOOKEEPER-1929

[Raúl Gutiérrez Segalés]

On 20 November 2015 at 15:46, Raúl Gutiérrez Segalés 
wrote:

> Hi Charles,
>
> On 20 November 2015 at 15:41, Charles Strahan 
> wrote:
>
>> Hello,
>>
>> I'd like to provide the following fix for ZOOKEEPER-1929
>> (https://issues.apache.org/jira/browse/ZOOKEEPER-1929):
>>
>
> Thanks for the patch! Mind attaching it to the ticket? We require patches
> to be in JIRA
> before we merge them.. I'll review & merge it later today.
>

Merged - thanks Charles!


-rgs

Re: PATCH: fix ZOOKEEPER-1929

[Raúl Gutiérrez Segalés]

Hi Charles,

On 20 November 2015 at 15:41, Charles Strahan  wrote:

> Hello,
>
> I'd like to provide the following fix for ZOOKEEPER-1929
> (https://issues.apache.org/jira/browse/ZOOKEEPER-1929):
>

Thanks for the patch! Mind attaching it to the ticket? We require patches
to be in JIRA
before we merge them.. I'll review & merge it later today.


-rgs

Re: [VOTE] Apache ZooKeeper release 3.4.7 candidate 0

[Raúl Gutiérrez Segalés]

Yup, Michi is right! I signed with zookeeper-3.4.7.tar.gz.asc with the
wrong key. I have no updated that files. Thanks Michi!


-rgs

On 15 November 2015 at 15:59, Michi Mutsuzaki  wrote:

> But that's not the key that's listed here, right?
> http://www.apache.org/dist/zookeeper/KEYS
>
> On Sat, Nov 14, 2015 at 2:43 PM, Flavio Junqueira  wrote:
> > It works for me:
> >
> > $ gpg2 --verify zookeeper-3.4.7.tar.gz.asc
> > gpg: Signature made Wed Nov 11 06:47:13 2015 GMT using RSA key ID
> 9DED6870
> > gpg: Good signature from "Raul Gutierrez Segales "
> > gpg: WARNING: This key is not certified with a trusted signature!
> > gpg:  There is no indication that the signature belongs to the
> owner.
> > Primary key fingerprint: D9FE 7869 EF41 C33C 707B  2FF7 4F0D 80FB 9DED
> 6870
> >
> >
> >> On 14 Nov 2015, at 22:20, Michi Mutsuzaki  wrote:
> >>
> >> It looks like all the other files are signed with the right key. I'll
> >> +1 this once zookeeper-3.4.7.tar.gz.asc gets updated.
> >>
> >> - verified the signature and md5/sha1 checksums for zookeeper-3.4.7.jar
> >> - verified the signatures and md5/sha1 checksums for all the files
> >> under dist-maven/
> >> - reviewed docs/releasenotes.html
> >> - ran ant test on ubuntu 14.04
> >>
> >>
> >> On Sat, Nov 14, 2015 at 1:40 PM, Michi Mutsuzaki 
> wrote:
> >>> I'm getting this error verifying the signature:
> >>>
> >>> % gpg --verify zookeeper-3.4.7.tar.gz.asc
> >>> gpg: Signature made Tue 10 Nov 2015 10:47:13 PM PST using RSA key ID
> 9DED6870
> >>> gpg: Can't check signature: public key not found
> >>>
> >>> Isn't the key ID supposed to be 92BC2F2B?
> >>> http://www.apache.org/dist/zookeeper/KEYS
> >>>
> >>>
> >>> On Sat, Nov 14, 2015 at 10:03 AM, Rakesh Radhakrishnan
> >>>  wrote:
> >>>> +1(non-binding). I've built and tested with ant jar, ran few zkcli
> >>>> commands, four letter words, tested against Hadoop-2.7.1 small
> cluster env.
> >>>>
> >>>> On Wed, Nov 11, 2015 at 3:29 PM, Flavio Junqueira 
> wrote:
> >>>>
> >>>>> +1 (binding)
> >>>>>
> >>>>> I have checked LICENSE, NOTICE, hashes, and signature. I have run
> tests
> >>>>> and some simple smoke tests locally.
> >>>>>
> >>>>> -Flavio
> >>>>>
> >>>>>> On 11 Nov 2015, at 07:17, Raúl Gutiérrez Segalés <
> r...@itevenworks.net>
> >>>>> wrote:
> >>>>>>
> >>>>>> This is a bugfix release candidate for 3.4.7. It fixes 79 issues,
> >>>>> including
> >>>>>> issues that affect followers after elections, being unable to
> delete a
> >>>>> node
> >>>>>> when it has no children, crashes with random input from the network
> on
> >>>>> the
> >>>>>> QuorumCnxManager, deadlocks during bad network conditions and
> others.
> >>>>>>
> >>>>>> The full release notes is available at:
> >>>>>>
> >>>>>>
> >>>>>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310801&version=12325149
> >>>>>>
> >>>>>> *** Please download, test and vote by November 25th 2015, 23:59
> UTC+0.
> >>>>> ***
> >>>>>>
> >>>>>> Source files:
> >>>>>> http://people.apache.org/~rgs/zookeeper-3-4-7-rc0/
> >>>>>>
> >>>>>> Maven staging repo:
> >>>>>>
> >>>>>
> https://repository.apache.org/content/groups/staging/org/apache/zookeeper/zookeeper/3.4.7/
> >>>>>>
> >>>>>> The tag to be voted upon:
> >>>>>> https://svn.apache.org/repos/asf/zookeeper/tags/release-3.4.7-rc0
> >>>>>>
> >>>>>> ZooKeeper's KEYS file containing PGP keys we use to sign the
> release:
> >>>>>> http://www.apache.org/dist/zookeeper/KEYS
> >>>>>>
> >>>>>> Should we release this candidate?
> >>>>>>
> >>>>>> Note that the approval is by lazy majority according to the bylaws
> and
> >>>>> only
> >>>>>> PMC votes are binding.
> >>>>>
> >>>>>
> >
>

[VOTE] Apache ZooKeeper release 3.4.7 candidate 0

[Raúl Gutiérrez Segalés]

This is a bugfix release candidate for 3.4.7. It fixes 79 issues, including
issues that affect followers after elections, being unable to delete a node
when it has no children, crashes with random input from the network on the
QuorumCnxManager, deadlocks during bad network conditions and others.

The full release notes is available at:

https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310801&version=12325149

*** Please download, test and vote by November 25th 2015, 23:59 UTC+0. ***

Source files:
http://people.apache.org/~rgs/zookeeper-3-4-7-rc0/

Maven staging repo:
https://repository.apache.org/content/groups/staging/org/apache/zookeeper/zookeeper/3.4.7/

The tag to be voted upon:
https://svn.apache.org/repos/asf/zookeeper/tags/release-3.4.7-rc0

ZooKeeper's KEYS file containing PGP keys we use to sign the release:
http://www.apache.org/dist/zookeeper/KEYS

Should we release this candidate?

Note that the approval is by lazy majority according to the bylaws and only
PMC votes are binding.

Re: zookeeper-3.4.7 timeframe

[Raúl Gutiérrez Segalés]

On 22 October 2015 at 14:31, Flavio Junqueira  wrote:

> If you have a patch by the end of today for ZK-1029, I'll review it before
> you wake up tomorrow.
>

Flavio fixed this one, so we are good to go!

I will punt everything else to 3.4.8 and cut an RC afterwards :-) Thanks!


-rgs

Re: zookeeper-3.4.7 timeframe

[Raúl Gutiérrez Segalés]

On 22 October 2015 at 14:07, Flavio Junqueira  wrote:

> Raul,
>
> I'd need some time to dig into ZK-832, but from the description I don't
> think it is a blocker. As I understand this is happening because the server
> lost persistent state, and this is isn't a common scenario in a replicated
> deployment. I'm fine with downgrading it from blocker to major/critical.
>
> As for ZK-1029, if we know what the problem is, would be difficult to
> provide a patch?
>

Sure, we can rework the cleanup path in zookeeper_init(). I just wanted to
note that it's not what's causing pain for the Mesos project (which looked
very bad at first), so we shouldn't block on it.

But you are right, it shouldn't be a big patch. I'll propose one later
today. Hopefully we can have an RC later this week :-)


-rgs

Re: zookeeper-3.4.7 timeframe

[Raúl Gutiérrez Segalés]

On 5 October 2015 at 11:01, Raúl Gutiérrez Segalés 
wrote:

> On 8 September 2015 at 23:15, Raúl Gutiérrez Segalés 
> wrote:
>
>> Hi,
>>
>> On 23 August 2015 at 14:51, Raúl Gutiérrez Segalés 
>> wrote:
>>
>>> On 23 August 2015 at 14:44, Raúl Gutiérrez Segalés 
>>> wrote:
>>>
>>>> Hi all,
>>>>
>>>> sorry about dropping the ball here. So going over the unresolved
>>>> issues, I think these ones would be nice to tackle before cutting an RC:
>>>>
>>>> * ZOOKEEPER-1833: fix windows build (one sub-task still opened:
>>>> ZOOKEEPER-1868)
>>>> * ZOOKEEPER-1029: C client bug in zookeeper_init (if bad hostname is
>>>> given)
>>>>   (no one has this assigned, I'll try to get a patch out by tomorrow)
>>>> * ZOOKEEPER-832: Invalid session id causes infinite loop during
>>>> automatic reconnect
>>>>   (I've asked Rakesh if can wrap it up, if anyone else can help that
>>>> would be great)
>>>> * ZOOKEEPER-2033: zookeeper follower fails to start after a restart
>>>> immediately following a new epoch
>>>>   (pinged Flavio to get some feedback)
>>>>
>>>> Everything else can probably be punted for 3.4.8, unless anyone
>>>> disagrees.
>>>>
>>>
>>> One more, which needs to be back-ported from trunk:
>>>
>>> ZOOKEEPER-1506:  Re-try DNS hostname -> IP resolution if node connection
>>> fails
>>>
>>
>> There's been some movement in the bug tracker, but ZOOKEEPER-1506 and 
>> ZOOKEEPER-832
>> still need reviews (hopefully tomorrow, unless someone can beat me to it)
>> and I still need to get to ZOOKEEPER-1029.
>>
>
> So ZOOKEEPER-1506 is done. Still waiting on ZOOKEEPER-832 and I am hoping
> to finally get to ZOOKEEPER-1029 this week (unless someone beats me to it,
> which would be much appreciated).
>


Circling back, it turns out that  ZOOKEEPER-1029 is actually not the cause
for MESOS-2186. The fact that we are not properly checking if the locks
have been initialized before trying to get the locks is still wrong, but
ignoring the return codes from pthread_cond_broadcast and
pthread_mutex_lock (EINVAL) is not causing the reported crashers.

I propose we punt ZOOKEEPER-1029 and ZOOKEEPER-832 for 3.4.8, so that we
can keep moving with the release candidate.

Any objections?


-rgs

Re: zookeeper-3.4.7 timeframe

[Raúl Gutiérrez Segalés]

On 8 September 2015 at 23:15, Raúl Gutiérrez Segalés 
wrote:

> Hi,
>
> On 23 August 2015 at 14:51, Raúl Gutiérrez Segalés 
> wrote:
>
>> On 23 August 2015 at 14:44, Raúl Gutiérrez Segalés 
>> wrote:
>>
>>> Hi all,
>>>
>>> sorry about dropping the ball here. So going over the unresolved issues,
>>> I think these ones would be nice to tackle before cutting an RC:
>>>
>>> * ZOOKEEPER-1833: fix windows build (one sub-task still opened:
>>> ZOOKEEPER-1868)
>>> * ZOOKEEPER-1029: C client bug in zookeeper_init (if bad hostname is
>>> given)
>>>   (no one has this assigned, I'll try to get a patch out by tomorrow)
>>> * ZOOKEEPER-832: Invalid session id causes infinite loop during
>>> automatic reconnect
>>>   (I've asked Rakesh if can wrap it up, if anyone else can help that
>>> would be great)
>>> * ZOOKEEPER-2033: zookeeper follower fails to start after a restart
>>> immediately following a new epoch
>>>   (pinged Flavio to get some feedback)
>>>
>>> Everything else can probably be punted for 3.4.8, unless anyone
>>> disagrees.
>>>
>>
>> One more, which needs to be back-ported from trunk:
>>
>> ZOOKEEPER-1506:  Re-try DNS hostname -> IP resolution if node connection
>> fails
>>
>
> There's been some movement in the bug tracker, but ZOOKEEPER-1506 and 
> ZOOKEEPER-832
> still need reviews (hopefully tomorrow, unless someone can beat me to it)
> and I still need to get to ZOOKEEPER-1029.
>

So ZOOKEEPER-1506 is done. Still waiting on ZOOKEEPER-832 and I am hoping
to finally get to ZOOKEEPER-1029 this week (unless someone beats me to it,
which would be much appreciated).


-rgs

Re: zookeeper-3.4.7 timeframe

[Raúl Gutiérrez Segalés]

Hi,

On 23 August 2015 at 14:51, Raúl Gutiérrez Segalés 
wrote:

> On 23 August 2015 at 14:44, Raúl Gutiérrez Segalés 
> wrote:
>
>> Hi all,
>>
>> sorry about dropping the ball here. So going over the unresolved issues,
>> I think these ones would be nice to tackle before cutting an RC:
>>
>> * ZOOKEEPER-1833: fix windows build (one sub-task still opened:
>> ZOOKEEPER-1868)
>> * ZOOKEEPER-1029: C client bug in zookeeper_init (if bad hostname is
>> given)
>>   (no one has this assigned, I'll try to get a patch out by tomorrow)
>> * ZOOKEEPER-832: Invalid session id causes infinite loop during automatic
>> reconnect
>>   (I've asked Rakesh if can wrap it up, if anyone else can help that
>> would be great)
>> * ZOOKEEPER-2033: zookeeper follower fails to start after a restart
>> immediately following a new epoch
>>   (pinged Flavio to get some feedback)
>>
>> Everything else can probably be punted for 3.4.8, unless anyone disagrees.
>>
>
> One more, which needs to be back-ported from trunk:
>
> ZOOKEEPER-1506:  Re-try DNS hostname -> IP resolution if node connection
> fails
>

There's been some movement in the bug tracker, but ZOOKEEPER-1506 and
ZOOKEEPER-832
still need reviews (hopefully tomorrow, unless someone can beat me to it)
and I still need to get to ZOOKEEPER-1029.


-rgs

Re: zookeeper-3.4.7 timeframe

[Raúl Gutiérrez Segalés]

On 23 August 2015 at 14:44, Raúl Gutiérrez Segalés 
wrote:

> Hi all,
>
> sorry about dropping the ball here. So going over the unresolved issues, I
> think these ones would be nice to tackle before cutting an RC:
>
> * ZOOKEEPER-1833: fix windows build (one sub-task still opened:
> ZOOKEEPER-1868)
> * ZOOKEEPER-1029: C client bug in zookeeper_init (if bad hostname is given)
>   (no one has this assigned, I'll try to get a patch out by tomorrow)
> * ZOOKEEPER-832: Invalid session id causes infinite loop during automatic
> reconnect
>   (I've asked Rakesh if can wrap it up, if anyone else can help that would
> be great)
> * ZOOKEEPER-2033: zookeeper follower fails to start after a restart
> immediately following a new epoch
>   (pinged Flavio to get some feedback)
>
> Everything else can probably be punted for 3.4.8, unless anyone disagrees.
>

One more, which needs to be back-ported from trunk:

ZOOKEEPER-1506:  Re-try DNS hostname -> IP resolution if node connection
fails


-rgs

Re: zookeeper-3.4.7 timeframe

[Raúl Gutiérrez Segalés]

Hi all,

sorry about dropping the ball here. So going over the unresolved issues, I
think these ones would be nice to tackle before cutting an RC:

* ZOOKEEPER-1833: fix windows build (one sub-task still opened:
ZOOKEEPER-1868)
* ZOOKEEPER-1029: C client bug in zookeeper_init (if bad hostname is given)
  (no one has this assigned, I'll try to get a patch out by tomorrow)
* ZOOKEEPER-832: Invalid session id causes infinite loop during automatic
reconnect
  (I've asked Rakesh if can wrap it up, if anyone else can help that would
be great)
* ZOOKEEPER-2033: zookeeper follower fails to start after a restart
immediately following a new epoch
  (pinged Flavio to get some feedback)

Everything else can probably be punted for 3.4.8, unless anyone disagrees.


-rgs

On 16 May 2015 at 13:41, Michi Mutsuzaki  wrote:
>
> Hi Raul,
>
> There are 13 unresolved issues marked for 3.4.7: http://s.apache.org/95J
>
> We should triage them and decide whether they need to be fixed in
> 3.4.7 or then can be pushed out to 3.4.8.
>
> On Sat, May 16, 2015 at 9:43 AM, Raúl Gutiérrez Segalés
>  wrote:
> > On Apr 30, 2015 7:51 PM, "Raúl Gutiérrez Segalés" 
> > wrote:
> >>
> >> Hi all,
> >>
> >> I went over all the tickets and I think we should be able to close them
> > over the next week:
> >>
> >> http://goo.gl/6Jjtj1
> >>
> >> After that, I'll cut an RC if that sounds reasonable. Thanks!
> >
> > I'd like to add one more:
> > https://issues.apache.org/jira/browse/ZOOKEEPER-602. With that, I think
> > we should be ready to cut an RC unless anyone thinks differently.
> >
> >
> > -rgs

Re: Reg ZooKeeper documentation link

[Raúl Gutiérrez Segalés]

Hi Rakesh,

On 21 August 2015 at 00:07, Rakesh R  wrote:

> Hi All,
>
> It seems the trunk documentation http://zookeeper.apache.org/doc/trunk/
> is showing very old pages and last published on  10/08/2014 14:59:37.
> I could see the "Trunk" url link in http://zookeeper.apache.org  page is
> pointing to 'ZooKeeper 3.4 Documentation', instead it should point to the
> latest code changes in trunk, isn't it?
>
> Anyone has idea to correct these part. Thanks!
>

The repo for that site is (apparently) this one:
https://svn.apache.org/repos/asf/zookeeper/site/trunk.

Though, by looking at svn log in content/doc/trunk it was last updated by
Alex (i.e.: Reconfig stuff).

How shall we keep this up to date? A job/task that pushes new docs
everytime something
changes in trunk would be ideal. Manual updates will fall behind almost
immediately...


-rgs

Re: [VOTE] Apache ZooKeeper release 3.5.1-alpha candidate 3

[Raúl Gutiérrez Segalés]

+1

My testing was:
* 3 participants + 2 observers using systemd-nspawn
* triggered elections
* ran some smoke tests with zk-shell along with more elections

All looks good. Thanks Michi!


-rgs


On 9 July 2015 at 15:23, Hongchao Deng  wrote:

> +1.Ran unit test and some basic programs. It went pretty smooth.Thanks
> Michi!
>
> - Hongchao Deng
>
> > Date: Thu, 9 Jul 2015 12:09:44 -0700
> > Subject: Re: [VOTE] Apache ZooKeeper release 3.5.1-alpha candidate 3
> > From: mutsuz...@gmail.com
> > To: dev@zookeeper.apache.org
> >
> > Just a reminder, the vote is closing in about two days, and we haven't
> > received enough binding votes yet. Please vote when you get a chance.
> > Thanks!
> >
> > On Mon, Jul 6, 2015 at 10:58 PM, Michi Mutsuzaki 
> wrote:
> > > +1
> > >
> > > - Ran ant test on ubuntu.
> > > - Compiled the c client on mac.
> > >
> > > On Mon, Jul 6, 2015 at 2:26 AM, Flavio Junqueira
> > >  wrote:
> > >> +1, I ran tests, checked license and notice files, ran release audit
> to make sure that rat had no issues to report.
> > >>
> > >> -Flavio
> > >>
> > >>> On 28 Jun 2015, at 08:47, Michi Mutsuzaki 
> wrote:
> > >>>
> > >>> This is the fourth release candidate for 3.5.1-alpha. This candidate
> > >>> fixes the c client compilation error on os x found in the previous
> > >>> candidate. The full release notes is available at:
> > >>>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310801&version=12326786
> > >>>
> > >>> *** Please download, test and vote by July 11th 2015, 23:59 UTC+0.
> ***
> > >>>
> > >>> Source files:
> > >>> http://people.apache.org/~michim/zookeeper-3.5.1-alpha-candidate-3/
> > >>>
> > >>> Maven staging repo:
> > >>>
> https://repository.apache.org/content/groups/staging/org/apache/zookeeper/zookeeper/3.5.1-alpha/
> > >>>
> > >>> The tag to be voted upon:
> > >>> https://svn.apache.org/repos/asf/zookeeper/tags/release-3.5.1-rc3/
> > >>>
> > >>> ZooKeeper's KEYS file containing PGP keys we use to sign the release:
> > >>> http://www.apache.org/dist/zookeeper/KEYS
> > >>>
> > >>> Should we release this candidate?
> > >>
>
>

Re: ZOOKEEPER-1525

[Raúl Gutiérrez Segalés]

Hi,

On 24 June 2015 at 14:58, Crowder Tim  wrote:

> Hi All-
>
> Any chance of getting a review for:
>   https://issues.apache.org/jira/browse/ZOOKEEPER-1525
>
>   https://reviews.apache.org/r/33874/
>
> It's been idle for about 6 weeks.
>

I'll take a look - thanks for pinging the list.


-rgs

Re: [VOTE] Apache ZooKeeper release 3.5.1-alpha candidate 2

[Raúl Gutiérrez Segalés]

On 20 June 2015 at 17:07, Michi Mutsuzaki  wrote:

> I updated https://issues.apache.org/jira/browse/ZOOKEEPER-2210 to
> address feedback from Chris. Could somebody take a look? Thanks!
>

Merged - thanks!


-rgs

Re: [VOTE] Apache ZooKeeper release 3.5.1-alpha candidate 2

[Raúl Gutiérrez Segalés]

On 15 June 2015 at 15:18, Alexander Shraer  wrote:

> Should we get a fix for ZOOKEEPER-2212 in this release ?
>

Yeah - it would be nice. Is it ready to go?


-rgs

Re: [VOTE] Apache ZooKeeper release 3.5.1-alpha candidate 2

[Raúl Gutiérrez Segalés]

I can't confirm this since I don't have OS X, but I think the C library is
broken there because of this change:

https://github.com/apache/zookeeper/commit/41c9fcb3ca09cd3d05e59fe47f08ecf0b85532c8

(got some reports on #zookeeper today, not sure if that's a showstopper for
the RC - probably it is).


-rgs

On 8 June 2015 at 01:37, Michi Mutsuzaki  wrote:

> This is the third release candidate for 3.5.1-alpha. The full release
> notes is available at:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310801&version=12326786
>
> *** Please download, test and vote by June 26th 2015, 23:59 UTC+0. ***
>
> Source files:
> http://people.apache.org/~michim/zookeeper-3.5.1-alpha-candidate-2/
>
> Maven staging repo:
>
> https://repository.apache.org/content/groups/staging/org/apache/zookeeper/zookeeper/3.5.1-alpha/
>
> The tag to be voted upon:
> https://svn.apache.org/repos/asf/zookeeper/tags/release-3.5.1-rc2/
>
> ZooKeeper's KEYS file containing PGP keys we use to sign the release:
> http://www.apache.org/dist/zookeeper/KEYS
>
> Should we release this candidate?
>

Re: do we need a corresponding JIRA for each (github) PR?

[Raúl Gutiérrez Segalés]

On 8 June 2015 at 11:21, Raúl Gutiérrez Segalés  wrote:

> On 8 June 2015 at 11:13, Patrick Hunt  wrote:
>
>> Sounds reasonable. I have reached out personally in the past, but
>> having it be automated would be good. Perhaps you can discuss with the
>> apache infra team as to what is possible?
>>
>
> Yeah, I'll ping them and get back to this thread with what's possible.
>

Filed
https://issues.apache.org/jira/servicedesk/customer/portal/1/INFRA-9788 to
get the pull
request auto-responder going (
https://github.com/blog/144-pull-request-auto-responder).



-rgs

Re: do we need a corresponding JIRA for each (github) PR?

[Raúl Gutiérrez Segalés]

On 8 June 2015 at 11:13, Patrick Hunt  wrote:

> Sounds reasonable. I have reached out personally in the past, but
> having it be automated would be good. Perhaps you can discuss with the
> apache infra team as to what is possible?
>

Yeah, I'll ping them and get back to this thread with what's possible.


-rgs




>
> Patrick
>
> On Mon, Jun 8, 2015 at 10:40 AM, Raúl Gutiérrez Segalés
>  wrote:
> > One final note for posterity and people interested in using PRs for the
> > review process
> > at least (which I guess is ok) is that the ASF GitHub Bot will actually
> > ping the associated
> > JIRA if you reference it from your PR, i.e.;
> >
> > https://issues.apache.org/jira/browse/ZOOKEEPER-2168
> > https://github.com/apache/zookeeper/pull/33
> >
> > I guess it would be nice if the Bot also commented on PRs pointing out
> > to the `How to Contribute` link or simply saying that you need to create
> a
> > JIRA and
> > then you can reference it from your PR.
> >
> >
> > -rgs
> >
> > On 8 June 2015 at 10:09, Raúl Gutiérrez Segalés 
> wrote:
> >
> >> On 8 June 2015 at 10:07, Patrick Hunt  wrote:
> >>
> >>> Keep in mind that filing the jira, attaching the patch file, etc...
> >>> are all demonstrating intent of the author to contribute the changes
> >>> under the apache license conditions. Jira is part of IP tracking. If
> >>> you file the jira for them we lose that. We used to (olden days) have
> >>> a specific checkbox in jira that required the patch author to
> >>> explicitly specify intent, but at some point that was dropped.
> >>>
> >>> So don't file the jira for someone else. Let them create the jira,
> >>> attach the patch, etc... - regardless they are going to need to
> >>> interact with jira in order to work through the feedback, discussions,
> >>> etc...
> >>>
> >>
> >> Cool. Thanks Pat, Camille and Chris!
> >>
> >>
> >> -rgs
> >>
> >>
>

Re: do we need a corresponding JIRA for each (github) PR?

[Raúl Gutiérrez Segalés]

One final note for posterity and people interested in using PRs for the
review process
at least (which I guess is ok) is that the ASF GitHub Bot will actually
ping the associated
JIRA if you reference it from your PR, i.e.;

https://issues.apache.org/jira/browse/ZOOKEEPER-2168
https://github.com/apache/zookeeper/pull/33

I guess it would be nice if the Bot also commented on PRs pointing out
to the `How to Contribute` link or simply saying that you need to create a
JIRA and
then you can reference it from your PR.


-rgs

On 8 June 2015 at 10:09, Raúl Gutiérrez Segalés  wrote:

> On 8 June 2015 at 10:07, Patrick Hunt  wrote:
>
>> Keep in mind that filing the jira, attaching the patch file, etc...
>> are all demonstrating intent of the author to contribute the changes
>> under the apache license conditions. Jira is part of IP tracking. If
>> you file the jira for them we lose that. We used to (olden days) have
>> a specific checkbox in jira that required the patch author to
>> explicitly specify intent, but at some point that was dropped.
>>
>> So don't file the jira for someone else. Let them create the jira,
>> attach the patch, etc... - regardless they are going to need to
>> interact with jira in order to work through the feedback, discussions,
>> etc...
>>
>
> Cool. Thanks Pat, Camille and Chris!
>
>
> -rgs
>
>

Re: do we need a corresponding JIRA for each (github) PR?

[Raúl Gutiérrez Segalés]

On 8 June 2015 at 10:07, Patrick Hunt  wrote:

> Keep in mind that filing the jira, attaching the patch file, etc...
> are all demonstrating intent of the author to contribute the changes
> under the apache license conditions. Jira is part of IP tracking. If
> you file the jira for them we lose that. We used to (olden days) have
> a specific checkbox in jira that required the patch author to
> explicitly specify intent, but at some point that was dropped.
>
> So don't file the jira for someone else. Let them create the jira,
> attach the patch, etc... - regardless they are going to need to
> interact with jira in order to work through the feedback, discussions,
> etc...
>

Cool. Thanks Pat, Camille and Chris!


-rgs

Re: do we need a corresponding JIRA for each (github) PR?

[Raúl Gutiérrez Segalés]

Fair enough. I do agree that multiple sources of truth is not great (even
if avoiding it means some copy/pasta
between PRs and JIRAs).

For now, I guess we can just ask people to open JIRAs, or file them for the
casual contributors.

Thanks all!


-rgs



On 8 June 2015 at 09:27, Patrick Hunt  wrote:

> Agree with the single record of truth. All changes currently go
> through Jira. It's part of the process and documented in the "how to
> contribute" page:
> https://cwiki.apache.org/confluence/display/ZOOKEEPER/HowToContribute
>
> The git mirror at github is just that, a mirror of svn and meant to be
> a convenience. We don't use the PR process there, etc...
>
> Patrick
>
> On Mon, Jun 8, 2015 at 9:06 AM, Chris Nauroth 
> wrote:
> > FWIW, the JIRA requirement is typical of Apache projects.  Most projects
> > have a strong preference that this single record of truth lies on Apache
> > infrastructure, hence the use of Apache JIRA and Apache's hosted git
> > rather than GitHub.  The idea is that a full permanent record of all
> > project decisions resides in Apache infrastructure, maintained by the
> ASF,
> > and not subject to external forces like a company folding and needing to
> > shut down its site.  (I don't have any reason to suspect this of GitHub,
> > but the point is that it's something outside of ASF control.)
> >
> > I don't know for sure that this is a required policy, but I wanted to
> > point out that it's consistent with the Apache projects I've seen.
> >
> > --Chris Nauroth
> >
> >
> >
> >
> > On 6/8/15, 5:19 AM, "Camille Fournier"  wrote:
> >
> >>I personally don't think that having a single record of truth and asking
> >>people to use that record is asking too much. I'm not in favor at all of
> >>removing the requirement for tickets to track work. Perhaps if we were
> >>entirely in git hub it would be one thing but we aren't.
> >>
> >>C
> >>On Jun 8, 2015 12:42 AM, "Raúl Gutiérrez Segalés" 
> >>wrote:
> >>
> >>> Hi Camille,
> >>>
> >>> On 7 June 2015 at 14:59, Camille Fournier  wrote:
> >>>
> >>> > I personally think all PRs should have an associated JIRA. This is
> >>>also
> >>> the
> >>> > requirement I have on my engineering team at work, and it seems
> >>>totally
> >>> > reasonable to me.
> >>> >
> >>>
> >>> Thanks for sharing! Is it with a git pull request work flow though?
> Take
> >>> this ‹ small albeit important ‹
> >>> pull request for instance:
> >>>
> >>> https://github.com/apache/zookeeper/pull/32
> >>>
> >>> I think it would be nice to avoid asking casual contributors to file
> >>>JIRAs
> >>> for those small patches so
> >>> the impedance for contributing is reduced.
> >>>
> >>> Also, having the committer do the paperwork sounds like too much red
> >>>tape
> >>> given that
> >>> the pull request is already pretty well documented. I at least would be
> >>> very happy
> >>> if we could just push those patches by referencing the PR in the
> >>>comment,
> >>> instead of a JIRA.
> >>>
> >>> I also suspect that eventually we might end up moving to git, so I
> think
> >>> there is value in allowing
> >>> pull requests as a submission mechanism (for some cases?), since it'll
> >>>make
> >>> the eventual transition
> >>> smoother and with less unknowns.
> >>>
> >>>
> >>> -rgs
> >>>
> >>>
> >>>
> >>> > C
> >>> >
> >>> > On Sun, Jun 7, 2015 at 2:24 PM, Raúl Gutiérrez Segalés <
> >>> > r...@itevenworks.net>
> >>> > wrote:
> >>> >
> >>> > > Heya,
> >>> > >
> >>> > > there's an increasing number of pull requests (PRs) coming through
> >>> github
> >>> > > (great! more contributions!). How do we deal with them? Do we need
> >>>to
> >>> > file
> >>> > > a corresponding JIRA before we merge them or can we just reference
> >>>the
> >>> > PR?
> >>> > >
> >>> > > I rather not tax the contributors with having to file the JIRA, but
> >>> > taxing
> >>> > > the committer is also not great.. Thoughts?
> >>> > >
> >>> > >
> >>> > > -rgs
> >>> > >
> >>> >
> >>>
> >
>

Re: do we need a corresponding JIRA for each (github) PR?

[Raúl Gutiérrez Segalés]

Hi Camille,

On 7 June 2015 at 14:59, Camille Fournier  wrote:

> I personally think all PRs should have an associated JIRA. This is also the
> requirement I have on my engineering team at work, and it seems totally
> reasonable to me.
>

Thanks for sharing! Is it with a git pull request work flow though? Take
this — small albeit important —
pull request for instance:

https://github.com/apache/zookeeper/pull/32

I think it would be nice to avoid asking casual contributors to file JIRAs
for those small patches so
the impedance for contributing is reduced.

Also, having the committer do the paperwork sounds like too much red tape
given that
the pull request is already pretty well documented. I at least would be
very happy
if we could just push those patches by referencing the PR in the comment,
instead of a JIRA.

I also suspect that eventually we might end up moving to git, so I think
there is value in allowing
pull requests as a submission mechanism (for some cases?), since it'll make
the eventual transition
smoother and with less unknowns.


-rgs



> C
>
> On Sun, Jun 7, 2015 at 2:24 PM, Raúl Gutiérrez Segalés <
> r...@itevenworks.net>
> wrote:
>
> > Heya,
> >
> > there's an increasing number of pull requests (PRs) coming through github
> > (great! more contributions!). How do we deal with them? Do we need to
> file
> > a corresponding JIRA before we merge them or can we just reference the
> PR?
> >
> > I rather not tax the contributors with having to file the JIRA, but
> taxing
> > the committer is also not great.. Thoughts?
> >
> >
> > -rgs
> >
>

do we need a corresponding JIRA for each (github) PR?

[Raúl Gutiérrez Segalés]

Heya,

there's an increasing number of pull requests (PRs) coming through github
(great! more contributions!). How do we deal with them? Do we need to file
a corresponding JIRA before we merge them or can we just reference the PR?

I rather not tax the contributors with having to file the JIRA, but taxing
the committer is also not great.. Thoughts?


-rgs

Re: using utf-8 encoding on java files

[Raúl Gutiérrez Segalés]

On 31 May 2015 at 10:51, Michi Mutsuzaki  wrote:

> It sounds fine to me, but any reason why we shouldn't stick to ascii?
>

No strong reasons tbh, just the fact that utf-8 is sometimes useful for
comments and it's
probably becoming (if not already) the norm, etc.


-rgs



> On Sun, May 31, 2015 at 9:14 AM, Raúl Gutiérrez Segalés
>  wrote:
> > Heya,
> >
> > So in this issue:
> >
> > https://issues.apache.org/jira/browse/ZOOKEEPER-2197
> >
> > we ran into a problem with utf-8 chars. How what about we teach javac to
> > treat
> > all files as utf-8? Would that be a problem for anyone/any platform?
> > Something like
> > this in build.xml:
> >
> > 
> >  > includeantruntime="false"
> >target="${javac.target}" source="${javac.source}"
> debug="on"
> > encoding="UTF-8">
> > 
> > 
> > 
> > 
> > 
> >
> > Thoughts?
> >
> >
> > -rgs
>

using utf-8 encoding on java files

[Raúl Gutiérrez Segalés]

Heya,

So in this issue:

https://issues.apache.org/jira/browse/ZOOKEEPER-2197

we ran into a problem with utf-8 chars. How what about we teach javac to
treat
all files as utf-8? Would that be a problem for anyone/any platform?
Something like
this in build.xml:









Thoughts?


-rgs

Re: [discuss] migrating to git

[Raúl Gutiérrez Segalés]

On May 16, 2015 11:59 PM, "Michi Mutsuzaki"  wrote:
>
> I was reading an article about hadoop migrating from svn to git, and
> started wondering if we should consider migrating to git. Do you guys
> think it's worth all the hassle (I'm guessing the migration involves a
> fair amount of work) to migrate to git, or should we continue using
> svn? I'll open an official vote if there is enough interest to migrate
> to git.
>
>
https://www.linux.com/news/featured-blogs/196-zonker/787127-apache-hadoop-transitions-to-git

+1, git would ease up so many things (chunking up big reviews, streamlining
small pull requests, etc.).

-rgs

Re: zookeeper-3.4.7 timeframe

[Raúl Gutiérrez Segalés]

On Apr 30, 2015 7:51 PM, "Raúl Gutiérrez Segalés" 
wrote:
>
> Hi all,
>
> I went over all the tickets and I think we should be able to close them
over the next week:
>
> http://goo.gl/6Jjtj1
>
> After that, I'll cut an RC if that sounds reasonable. Thanks!

I'd like to add one more:
https://issues.apache.org/jira/browse/ZOOKEEPER-602. With that, I think
we should be ready to cut an RC unless anyone thinks differently.


-rgs

Re: Create2Request vs CreateRequest

[Raúl Gutiérrez Segalés]

On 8 May 2015 at 20:29, Raúl Gutiérrez Segalés  wrote:

> On 8 May 2015 at 16:57, Patrick Hunt  wrote:
>
>> I think it's more a consistency thing than anything.
>>
>
> Hmm, it does lead to some code duplication which makes the
> PrepRequestProcessor considerably longer. I'll propose this patch (written
> by Santtu) in a JIRA:
>
> https://gist.github.com/rgs1/1fd74c4d6e6223696a1a
>

For posterity: https://issues.apache.org/jira/browse/ZOOKEEPER-2187


-rgs

Re: Create2Request vs CreateRequest

[Raúl Gutiérrez Segalés]

On 8 May 2015 at 16:57, Patrick Hunt  wrote:

> I think it's more a consistency thing than anything.
>

Hmm, it does lead to some code duplication which makes the
PrepRequestProcessor considerably longer. I'll propose this patch (written
by Santtu) in a JIRA:

https://gist.github.com/rgs1/1fd74c4d6e6223696a1a


-rgs



>
> On Fri, May 8, 2015 at 3:24 PM, Jordan Zimmerman <
> jor...@jordanzimmerman.com
> > wrote:
>
> > But that could’ve been done with just the new opcode of
> > ZooDefs.OpCode.create2, right? I need to understand if I need a new
> Request
> > class for the container feature or not.
> >
> > -Jordan
> >
> >
> >
> > On May 8, 2015 at 4:58:37 PM, Patrick Hunt (ph...@apache.org) wrote:
> >
> > Pretty sure that's why we did it that way. Otw old clients could have
> > issues.
> >
> > Patrick
> >
> > On Fri, May 8, 2015 at 9:40 AM, Chris Nauroth 
> > wrote:
> >
> > > Looking at "git blame zookeeper.jute", I traced the change back to
> > > ZOOKEEPER-1297 (add stat information to create call). Comments in the
> > > jira and corresponding Review Board request indicate that a new
> > > request/response pair was introduced in order to preserve backwards
> > > compatibility with existing clients. Although CreateRequest and
> > > Create2Request are the same, CreateResponse and Create2Response are
> > > different. It looks like new clients sending Create2Request would
> > receive
> > > the new data, but old clients that still send CreateRequest would
> > continue
> > > to receive the old data, thus preserving compatibility.
> > >
> > > Disclaimer: I was not involved with any of this work. I'm just someone
> > > with a git log and a browser pointed at jira. :-) This does appear to
> be
> > > the rationale for Create2Request though.
> > >
> > > https://issues.apache.org/jira/browse/ZOOKEEPER-1297
> > >
> > >
> > > https://reviews.apache.org/r/7283/
> > >
> > >
> > > --Chris Nauroth
> > >
> > >
> > >
> > >
> > > On 5/8/15, 8:58 AM, "Jordan Zimmerman" 
> > wrote:
> > >
> > > >Why was it necessary to define the Create2Request class? It¹s exactly
> > the
> > > >same as CreateRequest. I¹m working on ZOOKEEPER-2163 and need to
> > > >understand the difference/need.
> > > >
> > > >-Jordan
> > > >
> > > >
> > >
> > >
> >
> >
>

Re: Create2Request vs CreateRequest

[Raúl Gutiérrez Segalés]

On 8 May 2015 at 15:24, Jordan Zimmerman  wrote:

> But that could’ve been done with just the new opcode of
> ZooDefs.OpCode.create2, right? I need to understand if I need a new Request
> class for the container feature or not.
>

Why would you need that for ZOOKEEPER-2163 if you'd just be using a bit
from flags in CreateRequest:

class CreateRequest {
ustring path;
buffer data;
vector acl;
int flags;
}

No new request type/class would be needed, no? Since you are just adding a
new mode (CreateMode.CONTAINER).


-rgs


> -Jordan
>
>
>
> On May 8, 2015 at 4:58:37 PM, Patrick Hunt (ph...@apache.org) wrote:
>
> Pretty sure that's why we did it that way. Otw old clients could have
> issues.
>
> Patrick
>
> On Fri, May 8, 2015 at 9:40 AM, Chris Nauroth 
> wrote:
>
> > Looking at "git blame zookeeper.jute", I traced the change back to
> > ZOOKEEPER-1297 (add stat information to create call). Comments in the
> > jira and corresponding Review Board request indicate that a new
> > request/response pair was introduced in order to preserve backwards
> > compatibility with existing clients. Although CreateRequest and
> > Create2Request are the same, CreateResponse and Create2Response are
> > different. It looks like new clients sending Create2Request would receive
> > the new data, but old clients that still send CreateRequest would
> continue
> > to receive the old data, thus preserving compatibility.
> >
> > Disclaimer: I was not involved with any of this work. I'm just someone
> > with a git log and a browser pointed at jira. :-) This does appear to be
> > the rationale for Create2Request though.
> >
> > https://issues.apache.org/jira/browse/ZOOKEEPER-1297
> >
> >
> > https://reviews.apache.org/r/7283/
> >
> >
> > --Chris Nauroth
> >
> >
> >
> >
> > On 5/8/15, 8:58 AM, "Jordan Zimmerman" 
> wrote:
> >
> > >Why was it necessary to define the Create2Request class? It¹s exactly
> the
> > >same as CreateRequest. I¹m working on ZOOKEEPER-2163 and need to
> > >understand the difference/need.
> > >
> > >-Jordan
> > >
> > >
> >
> >
>

Re: Create2Request vs CreateRequest

[Raúl Gutiérrez Segalés]

Hi,

On 8 May 2015 at 15:24, Jordan Zimmerman  wrote:

> But that could’ve been done with just the new opcode of
> ZooDefs.OpCode.create2, right? I need to understand if I need a new Request
> class for the container feature or not.
>

It should work, the structs are the same except for the opcode. So for Java
this would be enough:

 h.setType(ZooDefs.OpCode.create2);
-Create2Request request = new Create2Request();
+CreateRequest request = new CreateRequest();
 Create2Response response = new Create2Response();

Similarly, for the C library you would have something like:

struct RequestHeader h = { get_xid(), ZOO_CREATE_OP };

instead of:

struct RequestHeader h = { get_xid(), ZOO_CREATE2_OP };


-rgs

Re: Great post on PagerDuty today.

[Raúl Gutiérrez Segalés]

On 8 May 2015 at 09:46, Patrick Hunt  wrote:

> There's a great post on Pager Duty today,
>
> http://www.pagerduty.com/blog/the-discovery-of-apache-zookeepers-poison-packet/
> some good comments on hackernews too
> https://news.ycombinator.com/item?id=9509698
>
> If I understand correctly bug1 is already fixed:
> https://issues.apache.org/jira/browse/ZOOKEEPER-2146
> should be released in 3.4.7+
>
> However bug2
> https://issues.apache.org/jira/browse/ZOOKEEPER-602
> is just in 3.5 and not 3.4.x.  Note my push back in the comments on 602 re
> risk vs reward. Evan makes a good case for including it. :-)
>
> We should also recommend that folks run with
> -XX:-HeapDumpOnOutOfMemoryError
> I would think. That should have caused the jvm to restart when bug1 was
> hit.
>
> Thoughts? Hongchao can you confirm that 2146 fixes bug 1?
>

While we are at the topic of bad input:
https://issues.apache.org/jira/browse/ZOOKEEPER-2186.

I have an internal patch for trunk, will back-port to 3.4 as well.


-rgs

Re: Great post on PagerDuty today.

[Raúl Gutiérrez Segalés]

Hi,

On 8 May 2015 at 09:46, Patrick Hunt  wrote:

> There's a great post on Pager Duty today,
>
> http://www.pagerduty.com/blog/the-discovery-of-apache-zookeepers-poison-packet/
> some good comments on hackernews too
> https://news.ycombinator.com/item?id=9509698
>
> If I understand correctly bug1 is already fixed:
> https://issues.apache.org/jira/browse/ZOOKEEPER-2146
> should be released in 3.4.7+
>

Yup. The more the reason to get 3.4.7 out soon :-) We only need a few more
reviews to get there.


>
> However bug2
> https://issues.apache.org/jira/browse/ZOOKEEPER-602
> is just in 3.5 and not 3.4.x.  Note my push back in the comments on 602 re
> risk vs reward. Evan makes a good case for including it. :-)
>

I am, initially, -1 on the backport. It's too big and it's a bit of a
distraction towards getting  3.5.0 to stable status.


-rgs

Re: [VOTE] Apache ZooKeeper release 3.5.1-alpha candidate 0

[Raúl Gutiérrez Segalés]

On 3 May 2015 at 23:26, Raúl Gutiérrez Segalés  wrote:

>
> On 3 May 2015 at 23:07, Michi Mutsuzaki  wrote:
>
>> Thanks Raul, I'll review and commit ZOOKEEPER-2171.
>
>
> Test passed now:
> https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2674/
>
>
>> Please go ahead
>> and check in ZOOKEEPER-2124 for 3.5.1.
>>
>
> Sure.
>

Merged: http://svn.apache.org/viewvc?view=revision&revision=1677530


-rgs

Re: [VOTE] Apache ZooKeeper release 3.5.1-alpha candidate 0

[Raúl Gutiérrez Segalés]

On 3 May 2015 at 23:07, Michi Mutsuzaki  wrote:

> Thanks Raul, I'll review and commit ZOOKEEPER-2171.


Test passed now:
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2674/


> Please go ahead
> and check in ZOOKEEPER-2124 for 3.5.1.
>

Sure.


-rgs

Re: making CI a more pleasant experience

[Raúl Gutiérrez Segalés]

On 3 May 2015 at 20:53, Patrick Hunt  wrote:
(...)

> Trunk tests seem pretty stable - where I do see issues recently it's mostly
> a single test that seems to be intermittently failing:
> ReconfigRecoveryTest.testCurrentObserverIsParticipantInNewConfig
> I see someone opened a jira then closed it, perhaps it should be re-opened:
> https://issues.apache.org/jira/browse/ZOOKEEPER-2080
>

I'll re-open it, it just failed for me:

https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2671/testReport/


-rgs

Re: making CI a more pleasant experience

[Raúl Gutiérrez Segalés]

Hi,

On 3 May 2015 at 12:53, Chris Nauroth  wrote:

> ()
> 3. Tests are non-deterministic, such as by hard-coding a sleep time to
> wait for an asynchronous action to complete.  The solutions usually
> involve providing hooks into lower-layer logic, such as to receive a
> callback from the asynchronous action, so that the test can be
> deterministic.
>

Indeed:

~/src/zookeeper-svn/src/java/test/org/apache/zookeeper (master) ✔ git grep
-i 'sleep(' | wc -l
91

Making runs shorter would be very helpful as well. Currently it just takes
too long.

Also, adding to what Patrick said, I'll take a closer look at the runs
reported at:

https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/

to have a better grasp of what's going on. Thanks!


-rgs

Re: [VOTE] Apache ZooKeeper release 3.5.1-alpha candidate 0

[Raúl Gutiérrez Segalés]

On 2 May 2015 at 15:45, Patrick Hunt  wrote:

> I'd say if it's a blocker and it's ready (or close to ready) then wait. Otw
> let's get the release out. It's ok for the alphas to have blockers, we'll
> catch them up in the next release.
>

fwiw, ZOOKEEPER-2171 has a +1 from Rakesh and is ready to be merged
(though an unrelated build/test failure happened after I updated it to
address
some last nits/details). I just gave ZOOKEEPER-2124 a +1, so it can probably
be merged.


-rgs

making CI a more pleasant experience

[Raúl Gutiérrez Segalés]

Hi all,

This has probably come up before but do we have any thoughts on making CI
better? Is the problem jenkins? Is it flaky tests? Bad CI workers? All of
the above?

I see we waste loads of time with trivial (or unrelated to the actual
failures) patches triggering failed builds all the time. I'd like to spend
some time improving our experience here, but would love some
pointers/thoughts.

Ideas?


Cheers,
-rgs

Re: zookeeper-3.4.7 timeframe

[Raúl Gutiérrez Segalés]

Hi all,

I went over all the tickets and I think we should be able to close them
over the next week:

http://goo.gl/6Jjtj1

After that, I'll cut an RC if that sounds reasonable. Thanks!


-rgs

On 21 April 2015 at 21:22, Patrick Hunt  wrote:

> That's always going to be the case. There will be some changes you know
> about, and some that you don't. The job of the release manager is to cut
> the release via the release process (well documented steps). You don't
> necessarily know about every change - otw we'd never get out releases. ;-)
>
> Patrick
>
> On Sun, Apr 19, 2015 at 10:10 AM, Hongchao Deng 
> wrote:
>
> > By "strange" I mean "not familiar with" :)
> > - Hongchao Deng
> >
> > > Subject: Re: zookeeper-3.4.7 timeframe
> > > From: fpjunque...@yahoo.com.INVALID
> > > Date: Sun, 19 Apr 2015 17:26:34 +0100
> > > To: dev@zookeeper.apache.org
> > >
> > > What's strange about the issues resolved?
> > >
> > > -Flavio
> > >
> > > > On 18 Apr 2015, at 20:19, Hongchao Deng 
> > wrote:
> > > >
> > > > TBH the commits from 3.4.6 to latest look a little strange to me. I
> > don't think I could take that responsibility. I would like to do the RM
> job
> > for 3.5.2 :)
> > > > - Hongchao Deng
> > > >
> > > >> From: ph...@apache.org
> > > >> Date: Fri, 17 Apr 2015 08:30:13 -0700
> > > >> Subject: Re: zookeeper-3.4.7 timeframe
> > > >> To: dev@zookeeper.apache.org; fpjunque...@yahoo.com
> > > >>
> > > >> One of our new committers perhaps? Hongchao or Raul interested?
> > > >>
> > > >> Patrick
> > > >>
> > > >> On Fri, Apr 17, 2015 at 1:20 AM, Flavio Junqueira <
> > > >> fpjunque...@yahoo.com.invalid> wrote:
> > > >>
> > > >>> I have volunteered to RM 3.4.7, but I'm more than happy to pass if
> > anyone
> > > >>> else wants to do a release.
> > > >>> -Flavio
> > > >>>
> > > >>>
> > > >>> On Friday, April 17, 2015 8:22 AM, Michi Mutsuzaki <
> > > >>> mutsuz...@gmail.com> wrote:
> > > >>>
> > > >>>
> > > >>>
> > > >>> Hi Konstantin,
> > > >>>
> > > >>> Yes, I'd like us to start preparing for 3.4.7 soon. We have 36 out
> of
> > > >>> 44 issues resolved. Any volunteer to manage the 3.4.7 release? I'd
> > > >>> like to get more committers to get familiarized with the release
> > > >>> process.
> > > >>>
> > > >>> On Thu, Apr 16, 2015 at 4:25 PM, Konstantin Boudnik <
> c...@apache.org>
> > > >>> wrote:
> > >  Hello ZK team!
> > > 
> > >  We are looking into upgrading ZK to 3.4.6 in the coming Bigtop 1.0
> > > >>> release.
> > >  However, as expressed in BIGTOP-1468, we are concerned a bit about
> > > >>> deviating
> > >  from 'official release only' policy we had so far. But as
> explained
> > > >>> above,
> > >  there are a few issues that are we need to address if we want to
> > switch:
> > >    ZOOKEEPER-1911
> > >    ZOOKEEPER-2064
> > >    ZOOKEEPER-1506 (potentially)
> > > 
> > >  I was wondering if you guys are planning on releasing 3.4.7 soon,
> > that
> > > >>> will
> > >  hopefully address at least the top two issues? I am not subscribed
> > to
> > >  dev@zookeeper.a.o so I'd appreciate if you can include
> > dev@bigtop.a.o
> > > >>> into
> > >  your reply as well.
> > > 
> > >  Thanks in advance!
> > >  Cos
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >
> > >
> >
> >
>

Re: [VOTE] Apache ZooKeeper release 3.5.1-alpha candidate 0

[Raúl Gutiérrez Segalés]

Hi Michi,

On 26 April 2015 at 14:44, Michi Mutsuzaki  wrote:

> Thank you everybody for voting. We are *not* releasing this candidate.
> There are 2 things to fix:
>
> - Update winconfig.h and the notice file (Michi)
> - https://issues.apache.org/jira/browse/ZOOKEEPER-2171 (Raul?)
>

I'll get to  ZK-2171 tomorrow.


-rgs



> I'll create another candidate once these 2 issues are fixed.
>
>
> On Tue, Apr 21, 2015 at 11:09 AM, Michi Mutsuzaki 
> wrote:
> > Thanks Pat, I'll update winconfig.h and the notice file.
> >
> > On Tue, Apr 21, 2015 at 10:53 AM, Patrick Hunt  wrote:
> >> Looks like version strings are in src/c/include/winconfig.h that need
> to be
> >> updated. They are still listed as 3.5.0.
> >>
> >> I think you'll need to spin a new RC to address this.
> >>
> >> You might update the notice file to include 2015 at the same time (not a
> >> blocker typically though).
> >>
> >> Patrick
> >>
> >> On Mon, Apr 20, 2015 at 5:41 PM, Raúl Gutiérrez Segalés <
> r...@itevenworks.net
> >>> wrote:
> >>
> >>> On 20 April 2015 at 13:03, Raúl Gutiérrez Segalés  >
> >>> wrote:
> >>>
> >>> > -1, alas.
> >>> >
> >>> > I think ZOOKEEPER-1506 could be problematic for some setups. After a
> >>> > couple of elections with a cluster of 5 participants and one
> observer, I
> >>> > end up with a participant that's unable to find the leader because it
> >>> does
> >>> > a reverse lookup (IP -> hostname) and ends up with a bogus hostname
> that
> >>> it
> >>> > can't resolve:
> >>> >
> >>> > https://gist.github.com/rgs1/d11822799fdbbfa5d5f2
> >>> >
> >>> > I don't think the reverse lookup from QuorumCnxManager was done
> before,
> >>> > nor that it should be done. So it could cause issues in places where
> >>> > reverse lookups aren't fully working. Surely, we could argue that
> it's a
> >>> > DNS setup issue but I think we should avoid the extra lookup if
> possible.
> >>> >
> >>> > I'll dig in a bit deeper and try to come with a deterministic repro.
> >>> >
> >>>
> >>> Commented on ZOOKEEPER-1506: turns out that my issue was with reverse
> >>> lookup calls that were not introduced by that patch. They seem to have
> been
> >>> introduced by ZOOKEEPER-107, so they have been around for a while.
> >>>
> >>> The tl;dr is that if your resolvers give you bad reverse names, you'll
> have
> >>> issues. It would nice to avoid these reverse lookups, so I created:
> >>>
> >>> https://issues.apache.org/jira/browse/ZOOKEEPER-2171
> >>>
> >>> After sorting this issue, I tested the following:
> >>>
> >>> * many elections (which look quick)
> >>> * creating and deleting ephemerals in a loop (via zk-shell)
> >>> * phunt's smoke test scripts (comparable results to 3.5.0)
> >>> * partitioning and unpartioning an attached observer
> >>> * use zktraffic's fle-dump & zab-dump to inspect if there were any
> bogus
> >>> FLE votes or ZAB messages [0]
> >>>
> >>> All of this looks good! So +1 now :-)
> >>>
> >>>
> >>> -rgs
> >>>
> >>> p.s.: fwiw, here's my test setup: http://itevenworks.net/zk-releases
> >>>
> >>> [0] https://github.com/twitter/zktraffic
> >>>
> >>>
> >>>
> >>> >
> >>> > -rgs
> >>> >
> >>> >
> >>> >
> >>> >
> >>> > On 12 April 2015 at 14:58, Michi Mutsuzaki 
> >>> wrote:
> >>> >
> >>> >> This is a release candidate for 3.5.1-alpha. The full release notes
> is
> >>> >> available at:
> >>> >>
> >>> >>
> >>>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310801&version=12326786
> >>> >>
> >>> >> *** Please download, test and vote by April 25th 2015, 23:59 UTC+0.
> ***
> >>> >>
> >>> >> Source files:
> >>> >> http://people.apache.org/~michim/zookeeper-3.5.1-alpha-candidate-0/
> >>> >>
> >>> >> Maven staging repo:
> >>> >>
> >>> >>
> >>>
> https://repository.apache.org/content/groups/staging/org/apache/zookeeper/zookeeper/3.5.1-alpha/
> >>> >>
> >>> >> The tag to be voted upon:
> >>> >> https://svn.apache.org/repos/asf/zookeeper/tags/release-3.5.1-rc0/
> >>> >>
> >>> >> ZooKeeper's KEYS file containing PGP keys we use to sign the
> release:
> >>> >> http://www.apache.org/dist/zookeeper/KEYS
> >>> >>
> >>> >> Should we release this candidate?
> >>> >>
> >>> >> --Michi
> >>> >>
> >>> >
> >>> >
> >>>
>

Re: [VOTE] Apache ZooKeeper release 3.5.1-alpha candidate 0

[Raúl Gutiérrez Segalés]

On 20 April 2015 at 13:03, Raúl Gutiérrez Segalés 
wrote:

> -1, alas.
>
> I think ZOOKEEPER-1506 could be problematic for some setups. After a
> couple of elections with a cluster of 5 participants and one observer, I
> end up with a participant that's unable to find the leader because it does
> a reverse lookup (IP -> hostname) and ends up with a bogus hostname that it
> can't resolve:
>
> https://gist.github.com/rgs1/d11822799fdbbfa5d5f2
>
> I don't think the reverse lookup from QuorumCnxManager was done before,
> nor that it should be done. So it could cause issues in places where
> reverse lookups aren't fully working. Surely, we could argue that it's a
> DNS setup issue but I think we should avoid the extra lookup if possible.
>
> I'll dig in a bit deeper and try to come with a deterministic repro.
>

Commented on ZOOKEEPER-1506: turns out that my issue was with reverse
lookup calls that were not introduced by that patch. They seem to have been
introduced by ZOOKEEPER-107, so they have been around for a while.

The tl;dr is that if your resolvers give you bad reverse names, you'll have
issues. It would nice to avoid these reverse lookups, so I created:

https://issues.apache.org/jira/browse/ZOOKEEPER-2171

After sorting this issue, I tested the following:

* many elections (which look quick)
* creating and deleting ephemerals in a loop (via zk-shell)
* phunt's smoke test scripts (comparable results to 3.5.0)
* partitioning and unpartioning an attached observer
* use zktraffic's fle-dump & zab-dump to inspect if there were any bogus
FLE votes or ZAB messages [0]

All of this looks good! So +1 now :-)


-rgs

p.s.: fwiw, here's my test setup: http://itevenworks.net/zk-releases

[0] https://github.com/twitter/zktraffic



>
> -rgs
>
>
>
>
> On 12 April 2015 at 14:58, Michi Mutsuzaki  wrote:
>
>> This is a release candidate for 3.5.1-alpha. The full release notes is
>> available at:
>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310801&version=12326786
>>
>> *** Please download, test and vote by April 25th 2015, 23:59 UTC+0. ***
>>
>> Source files:
>> http://people.apache.org/~michim/zookeeper-3.5.1-alpha-candidate-0/
>>
>> Maven staging repo:
>>
>> https://repository.apache.org/content/groups/staging/org/apache/zookeeper/zookeeper/3.5.1-alpha/
>>
>> The tag to be voted upon:
>> https://svn.apache.org/repos/asf/zookeeper/tags/release-3.5.1-rc0/
>>
>> ZooKeeper's KEYS file containing PGP keys we use to sign the release:
>> http://www.apache.org/dist/zookeeper/KEYS
>>
>> Should we release this candidate?
>>
>> --Michi
>>
>
>

Re: [VOTE] Apache ZooKeeper release 3.5.1-alpha candidate 0

[Raúl Gutiérrez Segalés]

On 20 April 2015 at 13:18, Flavio Junqueira 
wrote:

> Please reopen ZK-1506, Raul.
>

Done - I'll post my (hopefully reproducible) setup in a bit. I guess that
patch might be triggering reverse lookups as an (undesired) side effect.


-rgs

Re: [VOTE] Apache ZooKeeper release 3.5.1-alpha candidate 0

[Raúl Gutiérrez Segalés]

-1, alas.

I think ZOOKEEPER-1506 could be problematic for some setups. After a couple
of elections with a cluster of 5 participants and one observer, I end up
with a participant that's unable to find the leader because it does a
reverse lookup (IP -> hostname) and ends up with a bogus hostname that it
can't resolve:

https://gist.github.com/rgs1/d11822799fdbbfa5d5f2

I don't think the reverse lookup from QuorumCnxManager was done before, nor
that it should be done. So it could cause issues in places where reverse
lookups aren't fully working. Surely, we could argue that it's a DNS setup
issue but I think we should avoid the extra lookup if possible.

I'll dig in a bit deeper and try to come with a deterministic repro.


-rgs




On 12 April 2015 at 14:58, Michi Mutsuzaki  wrote:

> This is a release candidate for 3.5.1-alpha. The full release notes is
> available at:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310801&version=12326786
>
> *** Please download, test and vote by April 25th 2015, 23:59 UTC+0. ***
>
> Source files:
> http://people.apache.org/~michim/zookeeper-3.5.1-alpha-candidate-0/
>
> Maven staging repo:
>
> https://repository.apache.org/content/groups/staging/org/apache/zookeeper/zookeeper/3.5.1-alpha/
>
> The tag to be voted upon:
> https://svn.apache.org/repos/asf/zookeeper/tags/release-3.5.1-rc0/
>
> ZooKeeper's KEYS file containing PGP keys we use to sign the release:
> http://www.apache.org/dist/zookeeper/KEYS
>
> Should we release this candidate?
>
> --Michi
>

Re: zookeeper-3.4.7 timeframe

[Raúl Gutiérrez Segalés]

On 17 April 2015 at 01:20, Flavio Junqueira 
wrote:

> I have volunteered to RM 3.4.7, but I'm more than happy to pass if anyone
> else wants to do a release.
>

I am interested in going through the release process as the RM, that way I
could then volunteer with the 3.5.x releases
as well.

I'll ping you offline to sort the details, if you all agree with me to be
the RM.


-rgs

Re: About commit bug fix

[Raúl Gutiérrez Segalés]

Hi Gil,

On 6 April 2015 at 18:12, ZhaoHui  wrote:

> Hi, Master,
> I am recently research zookeeper and its client. When I try to program
> with native C client, I found a bug on Windows (this issue is never shown
> on Linux). I would help fix the issue. Would you please let me know how to
> commit the fix?
>

If you could create a JIRA issue (at
https://issues.apache.org/jira/browse/ZOOKEEPER) and attach the patch
there, that would be great.

Thanks!


-rgs

Re: Time for a 3.5.1-alpha release?

[Raúl Gutiérrez Segalés]

+1

It would be nice, but they are not blockers, to get these in:

https://issues.apache.org/jira/browse/ZOOKEEPER-1998
https://issues.apache.org/jira/browse/ZOOKEEPER-2051
https://issues.apache.org/jira/browse/ZOOKEEPER-2098

thanks Patrick!


-rgs


On 5 February 2015 at 11:22, Michi Mutsuzaki  wrote:

> +1 I can check in ZOOKEEPER-1366 tonight.
>
> On Thu, Feb 5, 2015 at 10:57 AM, Rakesh Radhakrishnan
>  wrote:
> > +1 for 3.5.1-alpha release
> >
> > I think its good to include the following jira issues:
> >
> > ZOOKEEPER-1366 (so far we got two +1)
> > ZOOKEEPER-1907 (its not blocking, good to have imprv)
> >
> > Best Regards,
> > Rakesh
> >
> > On Thu, Feb 5, 2015 at 11:27 PM, Patrick Hunt  wrote:
> >
> >> Hi folks. 3.5.0-alpha has been out for a bit now, we've gotten some
> >> good feedback and a number of jira issues have been resolved. What do
> >> you think about putting out an updated 3.5.1-alpha release with the
> >> latest changes? Anything blocking us or that you feel important to
> >> include?
> >>
> >> Regards,
> >>
> >> Patrick
> >>
>

Re: [announce] release zk-shell 1.0.0

[Raúl Gutiérrez Segalés]

Oops, the release link was wrong:

On 24 December 2014 at 16:31, Raúl Gutiérrez Segalés 
wrote:

> Today I've released version 1.0.0:
>
> https://github.com/twitter/zktraffic/releases/tag/0.1.0
>

Meant: https://github.com/rgs1/zk_shell/releases/tag/v1.0.0


-rgs

[announce] release zk-shell 1.0.0

[Raúl Gutiérrez Segalés]

Hi all,

For some months now I've been using zk-shell, a powerful alternative to
zkCli, to operate & debug ZooKeeper clusters:

https://github.com/rgs1/zk_shell

Today I've released version 1.0.0:

https://github.com/twitter/zktraffic/releases/tag/0.1.0

It's also available via PyPI (i.e.: pip install zk-shell):

https://pypi.python.org/pypi/zk_shell

I guess it might be useful for other ZK devs & operators and it can also
provide some ideas as to future enhancements for zkCli. Happy holidays!


-rgs

Re: ZooKeeper Meetup

[Raúl Gutiérrez Segalés]

On 30 September 2014 09:31, Hongchao Deng  wrote:

> My first thought is to make it *Oct 30 or Nov 4*.
>
> So far I have Jordan, Michi, and Alex volunteer to present. Let me know if
> more people want to. I will work out more details within the company and
> create a meetup event later.
>

Those dates work for me, I'll be there! Thanks for setting this up!


-rgs

Re: Interesting new JDK feature - string dedup

[Raúl Gutiérrez Segalés]

On 30 August 2014 11:37, Patrick Hunt  wrote:

> JDK8 update 20 (just out) has a pretty cool new feature that might
> work great for us - string de-duplication at the GC level, check it
> out:
>
> https://twitter.com/phunt/status/505509298990891008
>

Very cool - have you (or someone) tried it with ZK? I'll give it a try
later on.


-rgs

Re: ZooKeeper 3.5.0-alpha planning

[Raúl Gutiérrez Segalés]

On 24 July 2014 09:47, Patrick Hunt  wrote:

> We've identified the issues with 1987, it would be good if folks could
> take a look.


Great - thanks Patrick. Added some comments to the patch.


> Nothing looks unsolvable, but we should tweak things a
> bit before 3.5.0, esp given the current upgrade experience. The new
> docs will help a lot - see
> https://issues.apache.org/jira/browse/ZOOKEEPER-1660 which we need to
> review and commit.
>

Reading the docs, will follow-up with comments.


-rgs

Re: ZooKeeper 3.5.0-alpha planning

[Raúl Gutiérrez Segalés]

On 23 July 2014 14:48, Patrick Hunt  wrote:

> FYI: Currently running some tests and I'm about to create the
> branch-3.5 branch.
>

w00t :-)


-rgs

Re: ZooKeeper 3.5.0-alpha planning

[Raúl Gutiérrez Segalés]

On 18 July 2014 10:32, Patrick Hunt  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 
> wrote:
> > I'll check in ZOOKEEPER-1683.
> >
> > On Thu, Jul 17, 2014 at 11:20 AM, Alexander Shraer 
> 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  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
> >>>  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  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/ZooKeeper-trunk/2372/
> >>> >>
> >>> >> Patrick
> >>> >>
> >>> >> On Mon, Jul 14, 2014 at 7:36 PM, Patrick Hunt 
> 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
> >>> >>>  wrote:
> >>> >>>> On Jul 11, 2014 6:37 AM, "Flavio Junqueira"
> >>> 
> >>> >>>> wrote:
> >>> >>>>>
> &g

Re: ZooKeeper 3.5.0-alpha planning

[Raúl Gutiérrez Segalés]

On 14 July 2014 19:36, Patrick Hunt  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)
>

+1, though it would be really nice to have the proposed patch for
ZOOKEEPER-1807 merged since otherwise I'll need to apply patches to the
alpha release to be able to test it in my environment (with many observers).


Cheers,
-rgs