Re: Contributing to Zookeeper as a newbie

[Patrick Hunt]

Hi, that was me that denied you - the infra team has been sensitive about
account creation. I just re-read through the latest guidelines though and
it seems they have updated, at least from what I remembered. Given that and
your interest I approved the request just now, you should see the
notification.

In terms of getting started, see the web site
, the wiki, and in particular:
https://cwiki.apache.org/confluence/display/ZOOKEEPER/HowToContribute

Regards,

Patrick

On Thu, Apr 11, 2024 at 8:29 AM tison  wrote:

> Hi Vivek,
>
> Welcome!
>
> Of course. If you find any certain ticket interesting, you can drop an
> email to this list and other community members would get and reply.
>
> Our development flow is moved to GitHub, so as long as you have a GH
> account, you can make a patch.
>
> If you have concrete issue to file a ticket on JIRA, or want to comment on
> a JIRA ticket for further discussion, you can re-request a JIRA ID with
> that concrete reason and I suppose we can approve such requests.
>
> Best,
> tison.
>
>
> Vivek S  于2024年4月11日周四 23:00写道：
>
> > Hi all,
> >
> > Hope all of you are doing good. I am new to Zookeeper, and would like to
> > learn and contribute to the project. I requested for a Jira account, but
> > the request was denied saying that they've run out of Jira IDs.
> > Is it possible to contribute to the project without a Jira account? Any
> > guidance on how to go about it would be very helpful.
> >
> > Thanks,
> > Vivek S.
> >
>

Re: Subscribe for contributing to Zookeeper

[Patrick Hunt]

On Fri, Mar 29, 2024 at 7:34 AM Rich Bowen  wrote:

> On 2024/03/13 18:30:56 Abhijeet Sinha wrote:
> > Hey
> >
> > I want to understand and contribute to Zookeeper.
> >
> > Thanks and Regards
> > Abhijeet Sinha
>
> Welcome aboard, Abhijeet.
>
> As with any open source project, the way to get involved is to find your
> spot and just start doing it. Is there any particular aspect of Zookeeper
> where you’re particularly interested in getting involved?
>
> I’d encourage you to have a look at the open issues -
> https://issues.apache.org/jira/projects/ZOOKEEPER/issues - and see if one
> of them strikes your interest.
>
> I’d also encourage you to have a look at the code repo -
> https://github.com/apache/zookeeper   Perhaps review some of the pull
> requests - that’s a great way to get more familiar with the code, and also
> what kinds of issues people are encountering with it.
>
> Those two things are typically the best two ways to familiarize yourself
> with the code, and to start doing useful things that will earn trust in the
> community.
>
>
I'd also recommend starting with our homepage
, it has lots of good info, including a link
to the wiki, this page in particular
https://cwiki.apache.org/confluence/display/ZOOKEEPER/HowToContribute

Regards,

Patrick


> —
> Rich Bowen
> rbo...@rcbowen.com
>
>
>
>
>

Re: Backport to active branches by default

[Patrick Hunt]

Yes, that's what I mean. 3.9 is "current" - it should track latest changes.
3.8 is "stable" - it should only get critical fixes.

Patrick

On Wed, Mar 20, 2024 at 1:50 PM Andor Molnar  wrote:

> Do you mean handle 3.9 and 3.8 slightly differently and be more strict
> on branch-3.8?
>
> I can agree with that, but 3.9 can still receive more patches.
>
> Andor
>
>
>
>
> On Wed, 2024-03-20 at 13:16 -0700, Patrick Hunt wrote:
> > Shouldn't we only backport critical fixes into the non-mainline
> > branch? The
> > whole idea is that that's the "stable" release while the mainline is
> > the
> > most current...
> >
> > Regards,
> >
> > Patrick
> >
> > On Wed, Mar 20, 2024 at 12:54 PM Andor Molnar 
> > wrote:
> >
> > > Hi ZK committers,
> > >
> > > I've come across recently that patch authors keep asking me to
> > > backport
> > > their patches to active branches, because it was only submitted to
> > > the
> > > master branch.
> > >
> > > I think we should get into the habit of submitting every accepted
> > > PRs
> > > to all active branches (today it's branch-3.8 and branch-3.9)
> > > unless
> > > it's explicitly asked otherwise.
> > >
> > > For example, in case of a big new feature which requires a major
> > > version upgrade, we should not do that automatically, but for
> > > everything else, like bug fixes, improvements, code cleanups, doc
> > > updates, etc. feel free and submit everywhere.
> > >
> > > If we don't do that, we'll end up not shipping anything in minor
> > > releases.
> > >
> > > What do you think?
> > >
> > > Regards,
> > > Andor
> > >
> > >
> > >
> > >
>
>

Re: Backport to active branches by default

[Patrick Hunt]

Shouldn't we only backport critical fixes into the non-mainline branch? The
whole idea is that that's the "stable" release while the mainline is the
most current...

Regards,

Patrick

On Wed, Mar 20, 2024 at 12:54 PM Andor Molnar  wrote:

> Hi ZK committers,
>
> I've come across recently that patch authors keep asking me to backport
> their patches to active branches, because it was only submitted to the
> master branch.
>
> I think we should get into the habit of submitting every accepted PRs
> to all active branches (today it's branch-3.8 and branch-3.9) unless
> it's explicitly asked otherwise.
>
> For example, in case of a big new feature which requires a major
> version upgrade, we should not do that automatically, but for
> everything else, like bug fixes, improvements, code cleanups, doc
> updates, etc. feel free and submit everywhere.
>
> If we don't do that, we'll end up not shipping anything in minor
> releases.
>
> What do you think?
>
> Regards,
> Andor
>
>
>
>

Re: Moving 3.7 to End-of-Life

[Patrick Hunt]

Markmail search for apache mail archive is gone? and unfortunately Apache
mail archive search seems to be broken (no results coming back...) I
managed to track this ref down
https://lists.apache.org/thread/b8sm8gxmohs9gl4vrltd2jr4slqvrg9n
but I distinctly remember seeing something about this, just can't find it.

According to this it's already eol:
https://endoflife.date/zookeeper

Our own release page makes it clear that folks should move given stable and
current have been out for a while. I think we can call it EOL at this point.

Regards,

Patrick

On Fri, Jan 26, 2024 at 7:33 AM Andor Molnar  wrote:

> Hi zk community,
>
> According to our Releases [1] page ZooKeeper 3.8.2 became the first
> stable version of 3.8.x line on 3 Aug, 2023 (when 3.9.0 was released).
>
> The previous stable version "in approximately half a year will be
> announced as End-of-Life". 6 months will pass on 3 Feb, 2024, so we
> should think about announcing EoL soon.
>
> What do you think?
>
> Regards,
> Andor
>
>
> [1] https://zookeeper.apache.org/releases.html
>
>
>
>

Re: Good first tickets for beginners

[Patrick Hunt]

Odd. I tried resubmitting your earlier request, approving it this time, and
it seemed to go through - did you get an approval email?

Patrick

On Sat, Dec 16, 2023 at 4:30 PM Muthuraj Ramalinga kumar <
muthu90t...@gmail.com> wrote:

> Ok it says the following, when I resubmit:
>
> There is already a pending Jira account request associated with this email
> address. Please wait for it to be processed
>
> On Sat, Dec 16, 2023 at 4:23 PM Muthuraj Ramalinga kumar <
> muthu90t...@gmail.com> wrote:
>
> > Cool thanks
> >
> > On Sat, Dec 16, 2023 at 4:23 PM Patrick Hunt  wrote:
> >
> >> Yes, that was me. :-) Your submission said "Start contributing to the
> >> zookeeper project regularly"  which could mean anything, perhaps not
> >> requiring a JIRA account. Resubmit and I'll approve it.
> >>
> >> Regards,
> >>
> >> Patrick
> >>
> >> On Sat, Dec 16, 2023 at 4:17 PM Muthuraj Ramalinga kumar <
> >> muthu90t...@gmail.com> wrote:
> >>
> >> > Yes I did that, but this is the response I got:
> >> >
> >> > Sorry, we've run out of JIRA IDs, and API access is very locked down.
> >> You
> >> > can still browse/search for issues without a login. Please join the
> >> > zookeeper developer mailing lists to begin. thanks
> >> >
> >> > On Sat, Dec 16, 2023 at 4:15 PM Patrick Hunt 
> wrote:
> >> >
> >> > > You can request an account here, mention that you need to submit a
> >> fix.
> >> > > https://selfserve.apache.org/jira-account.html
> >> > >
> >> > > Patrick
> >> > >
> >> > > On Sat, Dec 16, 2023 at 4:10 PM Muthuraj Ramalinga kumar <
> >> > > muthu90t...@gmail.com> wrote:
> >> > >
> >> > > > Thanks Patrick.
> >> > > >
> >> > > > I have spotted an opportunity for a very minor clean up in the
> >> > following
> >> > > > file:
> >> > > > org/apache/zookeeper/client/ZKClientConfigTest.java
> >> > > >
> >> > > > The unit tests are managing temp directory creation in the test
> and
> >> > > > creating them in the resources directory.
> >> > > >
> >> > > > Cleanup:
> >> > > > Use Junit TempDir annotation which will automatically create temp
> >> files
> >> > > in
> >> > > > system temp directory and clean them after test run.
> >> > > >
> >> > > > But I don't have a Jira ticket to work on that and donot have the
> >> > > > permission to create one.
> >> > > >
> >> > > > Is it possible to create a ticket on my behalf ?
> >> > > >
> >> > > > Thank you
> >> > > >
> >> > > >
> >> > > > On Sat, Dec 16, 2023 at 3:59 PM Patrick Hunt 
> >> wrote:
> >> > > >
> >> > > > > Try adding tests or fixing flakey tests? There are also some
> jira
> >> > which
> >> > > > > might be appropriate
> >> > > > > <
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20ZOOKEEPER%20AND%20labels%20in%20(newbie)%20AND%20resolution%20%3D%20unresolved%20ORDER%20BY%20created%20DESC
> >> > > > > >,
> >> > > > > I don't think it's been curated in a while though:
> >> > > > >
> >> > > > >
> >> > https://cwiki.apache.org/confluence/display/ZOOKEEPER/HowToContribute
> >> > > > >
> >> > > > > Regards,
> >> > > > >
> >> > > > > Patrick
> >> > > > >
> >> > > > > On Sat, Dec 16, 2023 at 3:34 PM Muthuraj Ramalinga kumar <
> >> > > > > muthu90t...@gmail.com> wrote:
> >> > > > >
> >> > > > > > Hi,
> >> > > > > > I would like to contribute to this project and looking for
> good
> >> > first
> >> > > > > > tickets to work on.
> >> > > > > >
> >> > > > > > Appreciate any pointers .
> >> > > > > >
> >> > > > > > Thank you
> >> > > > > > Muthuraj
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> >
>

Re: Good first tickets for beginners

[Patrick Hunt]

Yes, that was me. :-) Your submission said "Start contributing to the
zookeeper project regularly"  which could mean anything, perhaps not
requiring a JIRA account. Resubmit and I'll approve it.

Regards,

Patrick

On Sat, Dec 16, 2023 at 4:17 PM Muthuraj Ramalinga kumar <
muthu90t...@gmail.com> wrote:

> Yes I did that, but this is the response I got:
>
> Sorry, we've run out of JIRA IDs, and API access is very locked down. You
> can still browse/search for issues without a login. Please join the
> zookeeper developer mailing lists to begin. thanks
>
> On Sat, Dec 16, 2023 at 4:15 PM Patrick Hunt  wrote:
>
> > You can request an account here, mention that you need to submit a fix.
> > https://selfserve.apache.org/jira-account.html
> >
> > Patrick
> >
> > On Sat, Dec 16, 2023 at 4:10 PM Muthuraj Ramalinga kumar <
> > muthu90t...@gmail.com> wrote:
> >
> > > Thanks Patrick.
> > >
> > > I have spotted an opportunity for a very minor clean up in the
> following
> > > file:
> > > org/apache/zookeeper/client/ZKClientConfigTest.java
> > >
> > > The unit tests are managing temp directory creation in the test and
> > > creating them in the resources directory.
> > >
> > > Cleanup:
> > > Use Junit TempDir annotation which will automatically create temp files
> > in
> > > system temp directory and clean them after test run.
> > >
> > > But I don't have a Jira ticket to work on that and donot have the
> > > permission to create one.
> > >
> > > Is it possible to create a ticket on my behalf ?
> > >
> > > Thank you
> > >
> > >
> > > On Sat, Dec 16, 2023 at 3:59 PM Patrick Hunt  wrote:
> > >
> > > > Try adding tests or fixing flakey tests? There are also some jira
> which
> > > > might be appropriate
> > > > <
> > > >
> > >
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20ZOOKEEPER%20AND%20labels%20in%20(newbie)%20AND%20resolution%20%3D%20unresolved%20ORDER%20BY%20created%20DESC
> > > > >,
> > > > I don't think it's been curated in a while though:
> > > >
> > > >
> https://cwiki.apache.org/confluence/display/ZOOKEEPER/HowToContribute
> > > >
> > > > Regards,
> > > >
> > > > Patrick
> > > >
> > > > On Sat, Dec 16, 2023 at 3:34 PM Muthuraj Ramalinga kumar <
> > > > muthu90t...@gmail.com> wrote:
> > > >
> > > > > Hi,
> > > > > I would like to contribute to this project and looking for good
> first
> > > > > tickets to work on.
> > > > >
> > > > > Appreciate any pointers .
> > > > >
> > > > > Thank you
> > > > > Muthuraj
> > > > >
> > > >
> > >
> >
>

Re: Good first tickets for beginners

[Patrick Hunt]

You can request an account here, mention that you need to submit a fix.
https://selfserve.apache.org/jira-account.html

Patrick

On Sat, Dec 16, 2023 at 4:10 PM Muthuraj Ramalinga kumar <
muthu90t...@gmail.com> wrote:

> Thanks Patrick.
>
> I have spotted an opportunity for a very minor clean up in the following
> file:
> org/apache/zookeeper/client/ZKClientConfigTest.java
>
> The unit tests are managing temp directory creation in the test and
> creating them in the resources directory.
>
> Cleanup:
> Use Junit TempDir annotation which will automatically create temp files in
> system temp directory and clean them after test run.
>
> But I don't have a Jira ticket to work on that and donot have the
> permission to create one.
>
> Is it possible to create a ticket on my behalf ?
>
> Thank you
>
>
> On Sat, Dec 16, 2023 at 3:59 PM Patrick Hunt  wrote:
>
> > Try adding tests or fixing flakey tests? There are also some jira which
> > might be appropriate
> > <
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20ZOOKEEPER%20AND%20labels%20in%20(newbie)%20AND%20resolution%20%3D%20unresolved%20ORDER%20BY%20created%20DESC
> > >,
> > I don't think it's been curated in a while though:
> >
> > https://cwiki.apache.org/confluence/display/ZOOKEEPER/HowToContribute
> >
> > Regards,
> >
> > Patrick
> >
> > On Sat, Dec 16, 2023 at 3:34 PM Muthuraj Ramalinga kumar <
> > muthu90t...@gmail.com> wrote:
> >
> > > Hi,
> > > I would like to contribute to this project and looking for good first
> > > tickets to work on.
> > >
> > > Appreciate any pointers .
> > >
> > > Thank you
> > > Muthuraj
> > >
> >
>

Re: Good first tickets for beginners

[Patrick Hunt]

Try adding tests or fixing flakey tests? There are also some jira which
might be appropriate
,
I don't think it's been curated in a while though:

https://cwiki.apache.org/confluence/display/ZOOKEEPER/HowToContribute

Regards,

Patrick

On Sat, Dec 16, 2023 at 3:34 PM Muthuraj Ramalinga kumar <
muthu90t...@gmail.com> wrote:

> Hi,
> I would like to contribute to this project and looking for good first
> tickets to work on.
>
> Appreciate any pointers .
>
> Thank you
> Muthuraj
>

FYI: ZK owasp checks failing

[Patrick Hunt]

FYI all of the current codelines are failing owasp check with the
following. We should try to get it into the next release...
https://ci-hadoop.apache.org/view/ZooKeeper/job/zookeeper-multi-branch-owasp/

16:51:13  [ERROR] jetty-io-9.4.52.v20230823.jar: CVE-2023-44487(7.5),
CVE-2023-36478(7.5)
16:51:13  [ERROR] jetty-server-9.4.52.v20230823.jar: CVE-2023-44487(7.5),
CVE-2023-36478(7.5)
16:51:13  [ERROR] netty-transport-4.1.94.Final.jar: CVE-2023-44487(7.5)

It's been reported in JIRA, tracked here:

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

Regards,

Patrick

Re: [VOTE] Apache ZooKeeper release 3.7.2 candidate 0

[Patrick Hunt]

+1 - xsums validated, rat ran clean, was able to compile successfully,
owasp check is green, able to run multiple configurations/ensembles
successfully.

Patrick

On Fri, Oct 6, 2023 at 3:06 AM Andor Molnar  wrote:

> Hi ZK folks,
>
> This is a release candidate for 3.7.2.
>
> This is a bugfix release for the 3.7 release line. Includes important
> bugfixes and dependency upgrades to address CVEs.
>
> The full release notes is available at:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310801=12351732
>
>
> *** Please download, test and vote by October 9th 2023, 23:59 UTC+0.
> ***
>
>
> Source files:
>
> https://dist.apache.org/repos/dist/dev/zookeeper/zookeeper-3.7.2-candidate-0/
>
> Maven staging repo:
> https://repository.apache.org/content/repositories/orgapachezookeeper-1098/
>
> The release candidate tag in git to be voted upon: release-3.7.2-0
> https://github.com/apache/zookeeper/releases/tag/release-3.7.2-0
>
> ZooKeeper's KEYS file containing PGP keys we use to sign the release:
> https://www.apache.org/dist/zookeeper/KEYS
>
> The staging version of the website is:
>
> https://dist.apache.org/repos/dist/dev/zookeeper/zookeeper-3.7.2-candidate-0/website/index.html
>
>
> Should we release this candidate?
>
>
> Regards,
> Andor
>
>
>
>

Re: [VOTE] Apache ZooKeeper release 3.8.3 candidate 0

[Patrick Hunt]

+1 - xsums validated, rat ran clean, was able to compile successfully,
owasp check is green, able to run multiple configurations/ensembles
successfully.

Patrick

On Thu, Oct 5, 2023 at 3:50 AM Andor Molnar  wrote:

> Hi,
>
> This is a release candidate for 3.8.3.
>
> This is a bugfix release for the 3.8 release line. Includes important
> dependency upgrades to address CVEs.
>
> The full release notes is available at:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310801=12353400
>
>
> *** Please download, test and vote by October 9th 2023, 23:59 UTC+0.
> ***
>
>
> Source files:
>
> https://dist.apache.org/repos/dist/dev/zookeeper/zookeeper-3.8.3-candidate-0/
>
> Maven staging repo:
> https://repository.apache.org/content/repositories/orgapachezookeeper-1097/
>
> The release candidate tag in git to be voted upon: release-3.8.3-0
> https://github.com/apache/zookeeper/releases/tag/release-3.8.3-0
>
> ZooKeeper's KEYS file containing PGP keys we use to sign the release:
> https://www.apache.org/dist/zookeeper/KEYS
>
> The staging version of the website is:
>
> https://dist.apache.org/repos/dist/dev/zookeeper/zookeeper-3.8.3-candidate-0/website/index.html
>
>
> Should we release this candidate?
>
>
> Regards,
> Andor
>
>
>
>

Re: [VOTE] Apache ZooKeeper release 3.9.1 candidate 0

[Patrick Hunt]

+1 - xsums validated, rat ran clean, was able to compile successfully,
owasp check is green, able to run multiple configurations/ensembles
successfully.

Note: there are a few license files which don't have accompanying jars, I
think this is fine. For the jars/licenses we do carry they matched OK.

Patrick


On Wed, Oct 4, 2023 at 5:29 AM Andor Molnar  wrote:

> Hi team,
>
> This is a release candidate for 3.9.1.
>
> This is a bugfix release for the 3.9 release line. Includes important
> dependency upgrades to address CVEs.
>
>
> The full release notes is available at:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310801=12353480
>
> *** Please download, test and vote by October 6th 2023, 23:59 UTC+0.
> ***
>
> Source files:
>
> https://dist.apache.org/repos/dist/dev/zookeeper/zookeeper-3.9.1-candidate-0/
>
> Maven staging repo:
> https://repository.apache.org/content/repositories/orgapachezookeeper-1096/
>
> The release candidate tag in git to be voted upon: release-3.9.1-0
> https://github.com/apache/zookeeper/releases/tag/release-3.9.1-0
>
> ZooKeeper's KEYS file containing PGP keys we use to sign the release:
> https://www.apache.org/dist/zookeeper/KEYS
>
> The staging version of the website is:
>
> https://dist.apache.org/repos/dist/dev/zookeeper/zookeeper-3.9.1-candidate-0/website/index.html
>
>
> Should we release this candidate?
>
>
> Best regards,
>
> Andor
>
>
>
>

Re: [VOTE] Apache ZooKeeper release 3.9.0 candidate 1

[Patrick Hunt]

+1 - xsum/sig verified, rat ran clean, I was able to compile, run the owasp
checker, and start various ensemble sizes manually w/o issue. lgtm.

Patrick

On Wed, Jul 19, 2023 at 2:20 AM Andor Molnar  wrote:

> This is release candidate for ZooKeeper 3.9.0.
>
> It is a major release and it introduces a lot of new features, most
> notably:
> - Admin server API for taking snapshot and stream out the data
> - Communicate the Zxid that triggered a WatchEvent to fire
> - TLS - dynamic loading for client trust/key store
> - Add Netty-TcNative OpenSSL Support
> - Adding SSL support to Zktreeutil
> - Improve syncRequestProcessor performance
> - Updates to all the third party dependencies to get rid of every known
> CVE.
>
> The full release notes is available at:
>
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310801=12351304
>
> *** Please download, test and vote by July 30th 2023, 23:59 UTC+0. ***
>
> Source files:
>
> https://dist.apache.org/repos/dist/dev/zookeeper/zookeeper-3.9.0-candidate-1/
>
> Maven staging repo:
>
> https://repository.apache.org/content/groups/staging/org/apache/zookeeper/zookeeper/3.9.0/
>
> The release candidate tag in git to be voted upon: release-3.9.0-1
> https://github.com/apache/zookeeper/tree/release-3.9.0-1
>
> ZooKeeper's KEYS file containing PGP keys we use to sign the release:
> https://www.apache.org/dist/zookeeper/KEYS
>
> The staging version of the website is:
>
> https://dist.apache.org/repos/dist/dev/zookeeper/zookeeper-3.9.0-candidate-1/website/index.html
>
>
> Should we release this candidate?
>
> Regards,
> Andor
>
>
>
>

Re: FIPS: removing ZKTrustManager

[Patrick Hunt]

"remove ZKTrustManager entirely from the codebase" - what is the impact on
backward compatibility if this is done? Why wouldn't we keep this as an
option (not the default?) to ensure folks won't experience a "gap" when
migrating to new versions. We could phase it out over time as part of such
a plan (at least n-1 compatibility is something we have guaranteed in the
past)

Patrick

On Fri, Jun 9, 2023 at 9:29 AM Szalay-Bekő Máté 
wrote:

> yeah, I remember these tickets, thanks for picking them up!
> I agree and like the solution you proposed, in general in the long term it
> is good not to use a custom trust manager, but rely on the standard one.
>
> Máté
>
>
> On Fri, Jun 9, 2023 at 2:08 PM Enrico Olivelli 
> wrote:
>
> > Il giorno ven 9 giu 2023 alle ore 14:07 Andor Molnar
> >  ha scritto:
> > >
> > > I'd like to backport this to the 3.8 branch too.
> > >
> > > Let's say I'll add new "zookeeper.fips-mode" parameter which will be
> > > "false" by default in 3.8 and "true" for 3.9.0.
> >
> > I am +1
> > ZK 3.9 will take time to be adopted and this is an important security
> > related topic
> >
> > Enrico
> >
> > >
> > > Thoughts?
> > >
> > > Andor
> > >
> > >
> > >
> > > On Fri, 2023-06-09 at 13:55 +0200, Enrico Olivelli wrote:
> > > > I think that switching to
> > > > sslParameters.setEndpointIdentificationAlgorithm("HTTPS"); is a good
> > > > option.
> > > > The less tweaks we have about Security code the better.
> > > >
> > > >
> > > > It would be great to see this in 3.9.0.
> > > >
> > > > Enrico
> > > >
> > > > Il giorno ven 9 giu 2023 alle ore 13:42 Andor Molnar
> > > >  ha scritto:
> > > > > Hi zk folks,
> > > > >
> > > > > Problem(s)
> > > > > ==
> > > > >
> > > > > One problem that we're having with a custom Trust Manager in ZK is
> > > > > that
> > > > > FIPS doesn't allow that:
> > > > >
> > > > > https://issues.apache.org/jira/browse/ZOOKEEPER-4393
> > > > >
> > > > > In FIPS mode the only allowed TrustManager in the JDK is
> > > > > X509TrustManagerImpl which is the default implementation. The class
> > > > > is
> > > > > final, so extending it is not an option unfortunately.
> > > > >
> > > > > The intention behind implementing a custom trust manager in ZK was,
> > > > > I
> > > > > believe, the need for server and client-side hostname verification.
> > > > > Hostname verification officially is not part of the SSL/TLS
> > > > > protocol,
> > > > > it's the responsibility of an upper level protocol like HTTPS.
> > > > >
> > > > > Hacking hostname verification in the SSL handshake is nice and was
> > > > > working fine so far, but unfortunately breaks the FIPS standard.
> > > > >
> > > > > Another annoying issue with ZKTrustManager is the need for reverse
> > > > > DNS
> > > > > lookup. This is usually needed when the hostname of the certificate
> > > > > provider is not known at the time of handshake. For instance, when
> > > > > somebody connects the client via IP address, which is generally not
> > > > > recommended when TLS is active in the client-server protocol.
> > > > >
> > > > > The bigger problem I've found is in the leader election: when a
> > > > > peer
> > > > > connects with a smaller id, the node will close the existing
> > > > > connection
> > > > > and opens a new one in the other direction, based on the
> > > > > information
> > > > > received in the InitialMessage from the peer which only contains
> > > > > the IP
> > > > > address, not the hostname. Therefore TrustManager needs to perform
> > > > > reverse DNS lookup.
> > > > >
> > > > > Tickets about reverse DNS lookup issues:
> > > > > https://issues.apache.org/jira/browse/ZOOKEEPER-3860
> > > > > https://issues.apache.org/jira/browse/ZOOKEEPER-4268
> > > > >
> > > > > Proposal
> > > > > 
> > > > >
> > > > > I suggest to remove ZKTrustManager entirely from the codebase and
> > > > > use
> > > > > the built-in, FIPS-Enabled X509TrustManagerImpl instead. It has the
> > > > > downside of losing hostname verification, but we have an option to
> > > > > re-
> > > > > enable it in client-server communication: Netty has built-in
> > > > > support
> > > > > for it, we just need to do
> > > > >
> > > > > sslParameters.setEndpointIdentificationAlgorithm("HTTPS");
> > > > >
> > > > > when creating the SSLEngine and that will result in a behaviour
> > > > > very
> > > > > similar to what we provide currently. I can show some examples.
> > > > >
> > > > > What we will truly lose is the hostname verification option in the
> > > > > Quorum and Leader Election protocols. Since in these protocols we
> > > > > manipulate the sockets directly, we would need to implement the
> > > > > verification manually.
> > > > >
> > > > > What do you think about this trade-off?
> > > > >
> > > > > Of course, we can put this change behind a feature flag "fips-
> > > > > mode",
> > > > > which will lead to a new mode in ZooKeeper that is actually less
> > > > > strict
> > > > > as the original behaviour.
> > > > >
> > > > > Regards,
> > > 

Re: [VOTE] Apache ZooKeeper release 3.8.1 candidate 1

[Patrick Hunt]

+1 - xsums validated, rat ran clean, built/compiled fine and I was able to
run some manual tests on various cluster sizes.

Regards,

Patrick

On Wed, Jan 25, 2023 at 8:39 AM Enrico Olivelli  wrote:

> This is the second release candidate for 3.8.1.
>
> This is a bugfix release. The full release notes is available at:
>
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12351398=Html=12310801
>
> *** Please download, test and vote by Thursday 26th 2023, 23:59 UTC+0. ***
>
> Source files:
>
> https://dist.apache.org/repos/dist/dev/zookeeper/zookeeper-3.8.1-candidate-1/
>
> Maven staging repo:
> https://repository.apache.org/content/repositories/orgapachezookeeper-1088/
>
> The release candidate tag in git to be voted upon: release-3.8.1-1
> https://github.com/apache/zookeeper/tree/release-3.8.1-1
>
> ZooKeeper's KEYS file containing PGP keys we use to sign the release:
> https://www.apache.org/dist/zookeeper/KEYS
>
> The staging version of the website is:
>
> https://dist.apache.org/repos/dist/dev/zookeeper/zookeeper-3.8.1-candidate-1/website/index.html
>
>
> Should we release this candidate?
>
>
> Enrico Olivelli
>

Re: [VOTE] Apache ZooKeeper release 3.8.1 candidate 0

[Patrick Hunt]

Will do, thanks Enrico!

Patrick

On Tue, Jan 24, 2023 at 12:09 AM Enrico Olivelli 
wrote:

> Patrick
>
> Il giorno lun 23 gen 2023 alle ore 23:11 Patrick Hunt
>  ha scritto:
> >
> > Thanks Enrico - off the bat I did notice a couple license file
> mis-matches,
> > not sure how you want to handle those:
> >
> > -rw-r--r--   1 phunt  staff11366 Jan 23 05:25
> > netty-common-4.1.76.Final.LICENSE.txt
> > -rw-r--r--   1 phunt  staff   654571 Dec 16 05:34
> > netty-common-4.1.86.Final.jar
> > -rw-r--r--   1 phunt  staff11366 Jan 23 05:25
> > netty-transport-4.1.76.Final.LICENSE.txt
> > -rw-r--r--   1 phunt  staff   488341 Dec 16 05:34
> > netty-transport-4.1.86.Final.jar
> >
> > Should I continue verification or are you going to address/respin?
>
> I will fix them and send a new RC., after addressing Andrey's problem
> about the watcher
>
> Continuing the verification would help in order to find other problems
> earlier.
> But if you have limited time then you can hold on and wait for the new RC
>
> Enrico
>
>
> >
> > Patrick
> >
> >
> > On Mon, Jan 23, 2023 at 5:51 AM Enrico Olivelli 
> wrote:
> >
> > > This is a release candidate for 3.8.1.
> > >
> > > This is a bugfix release. The full release notes is available at:
> > >
> > >
> > >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12351398=Html=12310801
> > >
> > > *** Please download, test and vote by Thursday 26th 2023, 23:59 UTC+0.
> ***
> > >
> > > Source files:
> > >
> > >
> https://dist.apache.org/repos/dist/dev/zookeeper/zookeeper-3.8.1-candidate-0/
> > >
> > > Maven staging repo:
> > >
> https://repository.apache.org/content/repositories/orgapachezookeeper-1085/
> > >
> > > The release candidate tag in git to be voted upon: release-3.8.1-0
> > > https://github.com/apache/zookeeper/tree/release-3.8.1-0
> > >
> > > ZooKeeper's KEYS file containing PGP keys we use to sign the release:
> > > https://www.apache.org/dist/zookeeper/KEYS
> > >
> > > The staging version of the website is:
> > >
> > >
> https://dist.apache.org/repos/dist/dev/zookeeper/zookeeper-3.8.1-candidate-0/website/index.html
> > >
> > >
> > > Should we release this candidate?
> > >
> > >
> > > Enrico Olivelli
> > >
>

Re: [VOTE] Apache ZooKeeper release 3.8.1 candidate 0

[Patrick Hunt]

Thanks Enrico - off the bat I did notice a couple license file mis-matches,
not sure how you want to handle those:

-rw-r--r--   1 phunt  staff11366 Jan 23 05:25
netty-common-4.1.76.Final.LICENSE.txt
-rw-r--r--   1 phunt  staff   654571 Dec 16 05:34
netty-common-4.1.86.Final.jar
-rw-r--r--   1 phunt  staff11366 Jan 23 05:25
netty-transport-4.1.76.Final.LICENSE.txt
-rw-r--r--   1 phunt  staff   488341 Dec 16 05:34
netty-transport-4.1.86.Final.jar

Should I continue verification or are you going to address/respin?

Patrick


On Mon, Jan 23, 2023 at 5:51 AM Enrico Olivelli  wrote:

> This is a release candidate for 3.8.1.
>
> This is a bugfix release. The full release notes is available at:
>
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12351398=Html=12310801
>
> *** Please download, test and vote by Thursday 26th 2023, 23:59 UTC+0. ***
>
> Source files:
>
> https://dist.apache.org/repos/dist/dev/zookeeper/zookeeper-3.8.1-candidate-0/
>
> Maven staging repo:
> https://repository.apache.org/content/repositories/orgapachezookeeper-1085/
>
> The release candidate tag in git to be voted upon: release-3.8.1-0
> https://github.com/apache/zookeeper/tree/release-3.8.1-0
>
> ZooKeeper's KEYS file containing PGP keys we use to sign the release:
> https://www.apache.org/dist/zookeeper/KEYS
>
> The staging version of the website is:
>
> https://dist.apache.org/repos/dist/dev/zookeeper/zookeeper-3.8.1-candidate-0/website/index.html
>
>
> Should we release this candidate?
>
>
> Enrico Olivelli
>

Re: [VOTE] Apache ZooKeeper release 3.6.4 candidate 0

[Patrick Hunt]

Does the build/test pipeline need to be updated to verify this? Why make it
a manual/release step.

Patrick

On Thu, Dec 15, 2022 at 3:35 PM Szalay-Bekő Máté 
wrote:

> Thanks for checking!
>
> I don't have a strong opinion. It would make sense to support newer gcc
> versions in a new release. On the other hand, it is not a regression on the
> branch-3.6 (the c-client in this rc compiles with the same gcc versions
> which were compatible with 3.6 3).
>
> But I am OK to make a new RC. I don't have new gcc installed though to test
> it locally. Also, I wonder if installing a new gcc is enough, or the
> openssl or other library versions also matter?
>
> Could you maybe check if the current branch-3.6 compiles on your machine,
> with gcc 12.2.0? As you mentioned, the fix for ZOOKEEPER-4641 is already
> present there (I merged it after RC 0). If it works for you, then I can add
> this commit and cut RC 1.
>
> Unless someone disagree...
>
> Thanks,
> Máté
>
>
> On Thu, Dec 15, 2022, 6:45 PM Chris Nauroth  wrote:
>
> > Unfortunately, I can't compile the C client because of the FIPS_mode bug
> > (ZOOKEEPER-4641). I'm on a newer version of GCC: 12.2.0. I see that
> > ZOOKEEPER-4641 was committed to branch-3.6 with a fix version of 3.6.5.
> > However, we're intending that 3.6.4 is the final 3.6 release, so there
> > never will be a 3.6.5.
> >
> > Sorry for the churn, but I'd prefer if we could bring that fix into a new
> > release candidate. Let me know your thoughts on it.
> >
> > Chris Nauroth
> >
> >
> > On Wed, Dec 14, 2022 at 4:08 PM Szalay-Bekő Máté <
> > szalay.beko.m...@gmail.com>
> > wrote:
> >
> > > +1 (binding)
> > >
> > > I did the following tests for the release candidate:
> > > - verified checksum and gpg signature of the artifacts
> > > - I built the source code (incl. the C-client, using -Pfull-build) on
> > > Ubuntu 20.04.5 using OpenJDK 8u352, maven 3.6.3 and GCC version 9.4.0
> > > - all the unit tests passed (both Java and C-client)
> > > - I also built and executed unit tests for zkpython
> > > - I also built the java code (without -Pfull-build) using other JDK
> > > versions: 11.0.15, 17.0.3, 18.0.1, 19.0.1 (but didn't run the tests
> this
> > > time, just used 'clean install -DskipTests')
> > > - checkstyle and spotbugs passed
> > > - apache-rat passed
> > > - owasp (CVE check) passed
> > > - fatjar built
> > > - I executed quick rolling-upgrade tests (using
> > > https://github.com/symat/zk-rolling-upgrade-test):
> > >   - rolling upgrade from 3.5.10 to 3.6.4
> > >   - rolling upgrade from 3.6.3 to 3.6.4
> > >   - rolling upgrade from 3.6.4 to 3.7.1
> > >   - rolling upgrade from 3.6.4 to 3.8.0
> > > - checked the generated documentation (zookeeper-docs/target/html)
> > > - compared generated release notes (releasenotes.html) with Jira (
> > >
> > >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310801=12350076
> > > )
> > >
> > > Best regards,
> > > Máté
> > >
> > > On Thu, Dec 15, 2022 at 1:05 AM Szalay-Bekő Máté <
> > > szalay.beko.m...@gmail.com>
> > > wrote:
> > >
> > > > This is a bugfix release candidate for 3.6.4. It fixes 40 issues,
> > > > including CVE fixes,
> > > > log4j1 removal (using reload4j from now) and various other bug fixes
> > > > (thread leaks, data
> > > > corruption, snapshotting and SASL related fixes).
> > > >
> > > > Please note, that based on our Release Strategy (
> > > > https://zookeeper.apache.org/releases.html#release-strategy) branch
> > 3.6
> > > > should become end-of-life and most likely 3.6.4 will be our last 3.6
> > > > release.
> > > >
> > > > The full release notes is available at:
> > > >
> > > >
> > >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310801=12350076
> > > >
> > > > *** Please download, test and vote by December 23th 2022, 23:59
> UTC+0.
> > > ***
> > > >
> > > >
> > > > Source files:
> > > > https://people.apache.org/~symat/zookeeper-3.6.4-rc0/
> > > >
> > > > Maven staging repo:
> > > >
> > > >
> > >
> >
> https://repository.apache.org/content/groups/staging/org/apache/zookeeper/zookeeper/3.6.4/
> > > >
> > > > The release candidate tag in git to be voted upon: release-3.6.4-0
> > > > (please note, branch-3.6.4 will move here only after the vote)
> > > >
> > > > ZooKeeper's KEYS file containing PGP keys we use to sign the release:
> > > > https://www.apache.org/dist/zookeeper/KEYS
> > > >
> > > > The staging version of the website is:
> > > > https://people.apache.org/~symat/zookeeper-3.6.4-rc0/webpage/
> > > >
> > > >
> > > > Should we release this candidate?
> > > >
> > > >
> > > > Best regards,
> > > > Máté
> > > >
> > >
> >
>

Re: I would like to send a PR related to zookeeper C client

[Patrick Hunt]

This reminds me - I saw recently that Infra is sunsetting TravisCI. I think
we added support for that a while back? I'm not sure clear on the details
tbh. Whoever was involved - can you take a look? It seems like it's behind
a gated page on cwiki, which lists ZK explicitly, if you can't access the
page checkout this public ref I saw (the quoted section)
https://cwiki.apache.org/confluence/pages/viewpage.action?spaceKey=INFRA=Travis+Migrations
https://www.mail-archive.com/dev@calcite.apache.org/msg19987.html

Regards,

Patrick

On Tue, Dec 6, 2022 at 8:50 AM Enrico Olivelli  wrote:

> Christopher,
>
> Il giorno dom 4 dic 2022 alle ore 19:34 Christopher
>  ha scritto:
> >
> > It might be worth reconsidering the contributing "requirement" to make a
> > JIRA ticket. A lot of JIRA tickets don't have useful information in them
> > anyway... they are just being created because it's required, which is
> just
> > extra work without benefits. The PR usually has more relevant information
> > and can serve as its own ticket, in my opinion.
>
> I agree with you.
>
> Currently we require a JIRA  because we can easily create release notes.
> We could switch to GH issues, but that would require some help/work to
> prepare a new
> release procedure. (in my projects I am participating we switched to
> GH issues, and actually
> create release notes is quite a pain, even with some automation)
>
> Namjae
> This is the guide to create a JIRA account
> https://infra.apache.org/jira-guidelines.html#who
>
> We can create a JIRA account for you as soon as you provide the
> requested information as reported in the document
>
> in the meantime I create a JIRA ticket for you, this is all you need
> to tag your commit message propertly
> https://issues.apache.org/jira/browse/ZOOKEEPER-4640
>
> Enrico
>
> >
> > On Sun, Dec 4, 2022, 12:12 Enrico Olivelli  wrote:
> >
> > > Il Sab 3 Dic 2022, 18:57 Namjae Kim  ha scritto:
> > >
> > > > Hi, I am Namjae Kim.
> > > >
> > > > I want to add version information to the file names of the libraries
> of
> > > > zookeeper C client. I tried to create a JIRA ticket but it was not
> > > > possible.
> > > >
> > > > My suggestion is to change the filename from `libzookeeper_mt.so.2`
> to
> > > > `libzookeeper_mt-3.8.0.so.2`.
> > > >
> > > > How do I create a ticket or get a JIRA account?
> > > >
> > >
> > > This is a good question.
> > > Recently ASF JIRA disabled self subscribe due to too much spam.
> > >
> > > I can help you.
> > > In the meantime (that I figure out how to crate your JIRA account) you
> can
> > > send the PR
> > >
> > > Thanks
> > > Enrico
> > >
> > >
> > > > Thanks.
> > > >
> > > > Namjae Kim
> > > >
> > >
>

Re: Some ADs are in the bug list

[Patrick Hunt]

Thanks for the repor Guoxiongt, I filed
https://issues.apache.org/jira/browse/INFRA-23507

Regards,

Patrick

On Sat, Jul 23, 2022 at 4:48 AM Guoxiong Li  wrote:

> Hi all,
>
> I notice there are some ADs in the bug list. Could somebody handle this
> situation? Closing these bugs or putting the related account into something
> like `blacklist`? The related ADs are from ZOOKEEPER-4576 to
> ZOOKEEPER-4597.
>
> Best Regards,
> -- Guoxiong
>

Re: On-demand Backup and Restore with Streaming Capability

[Patrick Hunt]

On Mon, Jul 11, 2022 at 9:23 PM Li Wang  wrote:

> Thanks for the inputs, Patrick. They are very valuable.
>
> I have similar thoughts on some of them as I worked on the feature. I will
> respond to them in the JIRA ticket.
>
>
sg. I noticed later on that the PR on gh has links to other reference
material, etc... Perhaps you can update the JIRA to "link" to that
material? EOD whatever material content is there, much of it should be
added to the release docs. That said, having insight on eg a design
doc/design decisions is also helpful for folks that want to dig deeper both
during, and after, the feature lands. The JIRA ticket (epic?) is typically
our central source for this, which is why I'm asking. I've found that
having the design doc be a "living doc" (eg google docs during the initial
stages of development) is also helpful wrt capturing feedback. I can do it
through jira/email but it's hard to capture/reference context. This is a
big feature set, otw I wouldn't mention. :-)

Patrick


> Bests,
>
> Li
>
> On Mon, Jul 11, 2022 at 11:08 AM Patrick Hunt  wrote:
>
> > I think this could be a useful feature for folks. However it immediately
> > raises a number of concerns if we want to ship it as a "mainline"
> feature,
> > I briefly started capturing here:
> >
> >
> https://issues.apache.org/jira/browse/ZOOKEEPER-4570?focusedCommentId=17565127=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17565127
> >
> > Patrick
> >
> > On Mon, Jul 11, 2022 at 10:48 AM Li Wang  wrote:
> >
> > > Thanks Enrico for the feedback. This is awesome! Looking forward to
> more
> > > comments and discussions, so we can have a solution from and for
> > > the community.
> > >
> > > Best,
> > >
> > > Li
> > > On Sun, Jul 10, 2022 at 10:46 PM Enrico Olivelli 
> > > wrote:
> > >
> > > > Li,
> > > >
> > > > Il Lun 11 Lug 2022, 06:58 Li Wang  ha scritto:
> > > >
> > > > > Hello,
> > > > >
> > > > > We are working on on-demand backup and restore with streaming
> > > capability,
> > > > > so different databases such as zookeeper and etcd can be backed up
> > and
> > > > > restored via a generic external management platform.  We would like
> > to
> > > > > contribute it to the community to benefit more users.
> > > > >
> > > >
> > > > This is great.
> > > > I am following your work.
> > > >
> > >
> > >
> > > >
> > > > I hope that people who already worked on similar proposals can chime
> > in,
> > > > this way we can make it a community work
> > > >
> > > > Thanks
> > > >
> > > > Enrico
> > > >
> > > >
> > > > > I noticed that some great work has been done in the backup and
> > restore
> > > > > area, specifically the following open PRs are very interesting.
> > > > >
> > > > > 1. ZOOKEEPER-3499:Add a complete backup mechanism for zookeeper
> > > > > internal(admin server way) #1044  （
> > > > > https://github.com/apache/zookeeper/pull/1044）
> > > > >
> > > > > 2.  Add backup and restore with timetable #1883 （
> > > > > https://github.com/apache/zookeeper/pull/1883）
> > > > >
> > > > > Instead of building another variant solution, I would like to see
> if
> > we
> > > > can
> > > > > work together, combine different solutions and provide a generic
> one
> > > that
> > > > > supports different use cases.
> > > > >
> > > > > To facilitate the discussion, I opened the following two JIRA
> tickets
> > > for
> > > > > our use case. I  would appreciate it if you could provide inputs or
> > > > > comments.
> > > > >
> > > > > https://issues.apache.org/jira/browse/ZOOKEEPER-4570
> > > > > https://issues.apache.org/jira/browse/ZOOKEEPER-4571
> > > > >
> > > > > Best,
> > > > >
> > > > > Li
> > > > >
> > > >
> > >
> >
>

Re: [VOTE] Apache ZooKeeper release 3.5.10 candidate 1

[Patrick Hunt]

+1. xsum/sig are fine. rat ran clean. The build issue I encountered with
rc0 is now fixed. I did some manual testing with various cluster sizes and
it all came clean.

Patrick

On Sun, May 29, 2022 at 10:09 AM Szalay-Bekő Máté <
szalay.beko.m...@gmail.com> wrote:

> This is a bugfix release candidate for 3.5.10. It fixes 44 issues,
> including CVE fixes,
> log4j1 removal (using reload4j from now) and various other bug fixes
> (thread leaks, data
> corruption, snapshotting and SASL related fixes).
>
> Please note, we announced 3.5 to be EOL from June 1st 2022, so most likely
> this will be our
> last 3.5 release.
>
> The full release notes is available at:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310801=12349434
>
> *** Please download, test and vote by June 3rd 2022, 23:59 UTC+0. ***
>
>
> Source files:
> https://people.apache.org/~symat/zookeeper-3.5.10-rc1/
>
> Maven staging repo:
>
> https://repository.apache.org/content/groups/staging/org/apache/zookeeper/zookeeper/3.5.10/
>
> The release candidate tag in git to be voted upon: release-3.5.10-rc1
>
> ZooKeeper's KEYS file containing PGP keys we use to sign the release:
> https://www.apache.org/dist/zookeeper/KEYS
>
> The staging version of the website is:
> https://people.apache.org/~symat/zookeeper-3.5.10-rc1/website/
>
>
> Should we release this candidate?
>
>
> Best regards,
> Máté
>

Re: [VOTE] Apache ZooKeeper release 3.5.10 candidate 0

[Patrick Hunt]

maven build is failing for me - should it? I can't remember if we
"officially" supported maven in 3.5?

[phunt:apache-zookeeper-3.5.10] $ mvn --version
Apache Maven 3.8.5 (3599d3414f046de2324203b78ddcf9b5e4388aa0)
Maven home: /opt/homebrew/Cellar/maven/3.8.5/libexec
Java version: 18.0.1, vendor: Homebrew, runtime:
/opt/homebrew/Cellar/openjdk/18.0.1/libexec/openjdk.jdk/Contents/Home
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "12.3.1", arch: "aarch64", family: "mac"

mvn clean install -DskipTests

[ERROR] Failed to execute goal
org.apache.felix:maven-bundle-plugin:4.1.0:bundle (build bundle) on project
zookeeper-jute: Execution build bundle of goal
org.apache.felix:maven-bundle-plugin:4.1.0:bundle failed.:
ConcurrentModificationException -> [Help 1]

On Thu, May 26, 2022 at 7:56 AM Enrico Olivelli  wrote:

> Sorry for the late reply.
> I will test the RC tomorrow
>
> Enrico
>
> Il giorno gio 26 mag 2022 alle ore 16:29 Szalay-Bekő Máté
>  ha scritto:
> >
> > Hello All,
> >
> > Thank you Chris for the quick vote!
> >
> > Despite my earlier attempt to mislead everyone (I made a copy-paste error
> > and wrote 'non-binding' when I voted), we already have two binding +1 for
> > this release.
> > If some of you have the time, please test the RC and vote.
> >
> > Best regards,
> > Mate
> >
> >
> > On Fri, May 20, 2022 at 9:02 AM Szalay-Bekő Máté <
> szalay.beko.m...@gmail.com>
> > wrote:
> >
> > >
> > > +1 (non-binding)
> > >
> > > - I built the source code (-Pfull-build) on Ubuntu 20.04 using OpenJDK
> > > 8u212 and maven 3.6.3.
> > > - all the unit tests passed (both Java and C-client).
> > > - I also built and executed unit tests for zkpython
> > > - checkstyle and spotbugs passed
> > > - apache-rat passed
> > > - owasp (CVE check) passed
> > > - I executed quick rolling-upgrade tests (using
> > > https://github.com/symat/zk-rolling-upgrade-test):
> > >   - rolling upgrade from 3.5.9  to 3.5.10
> > >   - rolling upgrade from 3.5.10 to 3.6.3
> > >   - rolling upgrade from 3.5.10 to 3.7.1
> > >   - rolling upgrade from 3.7.0  to 3.8.0
> > > - check generated documentation
> > > - compared generated release notes (
> > >
> https://people.apache.org/~symat/zookeeper-3.5.10-rc0/website/releasenotes.html
> )
> > > with Jira (
> > >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310801=12349434
> > > )
> > > - check the signature and checksum of the artifacts
> > > - run some smoke tests using both the binary distribution
> > > (apache-zookeeper-3.5.10-bin.tar.gz) and on a freshly compiled version
> > > (based on apache-zookeeper-3.5.10.tar.gz)
> > >
> > > The C-client tests can be tricky (and annoying) sometimes. On docker
> some
> > > of them fail for me more frequently (also IPV6 tests can be tricky to
> setup
> > > on docker+mac). Also sometimes they leave ZooKeeper processes open
> after a
> > > test failure, and these are preventing later test runs to pass. Worth
> to
> > > take a look and kill these before running the C tests again. In the
> end I
> > > got all of them to pass on Ubuntu 20.04 and gcc 9.4.0 (using native
> ubuntu,
> > > not mac+docker), having all the recommended ubuntu packages installed (
> > > https://github.com/apache/zookeeper/blob/master/README_packaging.md).
> But
> > > would be nice to improve our test quality here... (unfortunately I
> don't
> > > think more recent branches would be in a much better shape)
> > >
> > > Best regards,
> > > Mate
> > >
> > > On Fri, May 20, 2022 at 12:10 AM Chris Nauroth 
> > > wrote:
> > >
> > >> +1 (binding)
> > >>
> > >> - Verified all checksums.
> > >> - Verified all signatures.
> > >> - Built from source, including native code on Linux.
> > >> - Tests passed.
> > >> - Ran several small samples successfully.
> > >>
> > >> I'm seeing failures in the cppunit tests in zookeeper-client-c. The
> same
> > >> failures reproduce on version 3.5.9 though, so it's not related to
> this
> > >> release. I assume this is a configuration issue I need to diagnose in
> my
> > >> environment.
> > >>
> > >> Chris Nauroth
> > >>
> > >>
> > >> On Thu, May 19, 2022 at 2:31 AM Szalay-Bekő Máté <
> > >> szalay.beko.m...@gmail.com>
> > >> wrote:
> > >>
> > >> > This is a bugfix release candidate for 3.5.10. It fixes 43 issues,
> > >> > including CVE fixes, log4j1 removal (by default using reload4j from
> now)
> > >> > and various other bug fixes (thread leaks, data corruption,
> snapshotting
> > >> > and SASL related fixes).
> > >> >
> > >> > Please note, we announced 3.5 to be EOL from June 1st 2022, so most
> > >> likely
> > >> > this will be our
> > >> > last 3.5 release.
> > >> >
> > >> > The full release notes is available at:
> > >> >
> > >> >
> > >>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310801=12349434
> > >> >
> > >> > *** Please download, test and vote by May 27th 2022, 23:59 UTC+0.
> ***
> > >> >
> > >> >
> > >> > Source files:
> > >> > 

Re: [VOTE] Apache ZooKeeper release 3.7.1 candidate 1

[Patrick Hunt]

+1 xsum/sigs are valid, rat ran clean as did the dep checks. I tested with
various sized clusters manually and it all ran fine.

Regards,

Patrick

On Sat, May 7, 2022 at 1:01 AM Mohammad Arshad  wrote:

> This is a bug fix release candidate for 3.7.1. It contains 64 fixes.
>
> The full release notes is available at:
>
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310801=12350030
>
> *** Please download, test and vote by Monday, 09 May, 2022, 23:59 UTC+0.
> ***
>
> Source files:
> https://dist.apache.org/repos/dist/dev/zookeeper/zookeeper-3.7.1-rc1/
>
> Maven staging repo:
> https://repository.apache.org/content/repositories/orgapachezookeeper-1076
>
> The release candidate tag in git to be voted upon: release-3.7.1-1
> https://github.com/apache/zookeeper/tree/release-3.7.1-1
>
> ZooKeeper's KEYS file containing PGP keys we use to sign the release:
> https://www.apache.org/dist/zookeeper/KEYS
>
> The staging version of the website is:
>
> https://dist.apache.org/repos/dist/dev/zookeeper/zookeeper-3.7.1-rc1/website/index.html
>
>
> Should we release this candidate?
>
> Thanks Regards
> -Arshad
>

Re: [VOTE] Apache ZooKeeper release 3.7.1 candidate 0

[Patrick Hunt]

The dependency checker is failing. We had a similar discussion about the
impact of this on a recent release candidate
. The
decision was to address the problem rather than push it downstream to end
users. iow this type of error results in all consumers having a question as
to whether there is a problem or not. Better to fix it now by spinning
another RC rather than have to deal with it magnified later.

[ERROR] One or more dependencies were identified with vulnerabilities that
have a CVSS score greater than or equal to '0.0':
[ERROR]
[ERROR] reload4j-1.2.19.jar: CVE-2020-9493, CVE-2022-23307
[ERROR]
[ERROR] See the dependency-check report for more details.

On Sun, Apr 24, 2022 at 6:25 PM Mohammad Arshad  wrote:

> This is a bug fix release candidate for 3.7.1. It contains 61 fixes.
>
> The full release notes is available at:
>
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310801=12350030
>
> *** Please download, test and vote by Sunday, 01 May, 2022, 23:59 UTC+0.
> ***
>
> Source files:
> https://dist.apache.org/repos/dist/dev/zookeeper/zookeeper-3.7.1-rc0/
>
> Maven staging repo:
> https://repository.apache.org/content/repositories/orgapachezookeeper-1075
>
> The release candidate tag in git to be voted upon: release-3.7.1-0
> https://github.com/apache/zookeeper/tree/release-3.7.1-0
>
> ZooKeeper's KEYS file containing PGP keys we use to sign the release:
> https://www.apache.org/dist/zookeeper/KEYS
>
> The staging version of the website is:
>
> https://dist.apache.org/repos/dist/dev/zookeeper/zookeeper-3.7.1-rc0/website/index.html
>
>
> Should we release this candidate?
>
>
> -Arshad
>

Re: [ANNOUNCE] new ZooKeeper PMC member: Mate Szalay-Beko

[Patrick Hunt]

Kudos Mate!

Regards,

Patrick

On Sun, Mar 27, 2022 at 11:42 PM Enrico Olivelli 
wrote:

> I am happy to announce that Mate Szalay-Beko has been invited to join
> the Apache ZooKeeper PMC and he accepted.
>
> Mate is doing great work for our community.
>
> Please join me in congratulating with him
>
> Congrats Mate !
>
>
> If you want to know more about the ASF works and what is a PMC you can
> read more here
> https://www.apache.org/foundation/how-it-works.html#pmc
>
> Enrico
>

Re: [RESULT] [VOTE] Apache ZooKeeper release 3.8.0 candidate 1

[Patrick Hunt]

Enrico - can you update the "news" section of the public site to reflect
the 3.8.0 release and give a brief overview of the changes?

It looks like this was missed in the release steps "Update the release news
in releases.md"

https://zookeeper.apache.org/releases.html#news

Thanks,

Patrick

On Sat, Mar 5, 2022 at 8:54 AM Chris Nauroth  wrote:

> Belated +1, and yes, thank you so much Enrico!
>
> Chris Nauroth
>
>
> On Thu, Mar 3, 2022 at 5:43 AM Szalay-Bekő Máté <
> szalay.beko.m...@gmail.com>
> wrote:
>
> > Thank you Enrico for managing this release! Nice job!! :)
> >
> > Best regards,
> > Mate
> >
> > On Thu, Mar 3, 2022 at 1:10 PM Enrico Olivelli 
> > wrote:
> >
> > > Hello,
> > > with 4 positive +1 votes (3 bindings):
> > > - Enrico Olivelli
> > > - Patrick Hunt
> > > - Andor Molnar
> > > - Szalay-Bekő Máté
> > >
> > > I am closing this VOTE as successful
> > >
> > > I will proceed with the next steps for the release
> > >
> > > Thanks to everyone who worked on this milestone !
> > >
> > > Enrico
> > >
> > >
> > > Il giorno gio 3 mar 2022 alle ore 12:02 Andor Molnar
> > >  ha scritto:
> > > >
> > > > +1 (binding)
> > > >
> > > > - checksum / signatures verified
> > > > - compiled the full build on Mac,
> > > > - unit test run on Java 11 - I had a few tests which was constantly
> > > failing on my Mac, but given that CI already passed all tests and
> others
> > > reported the same, I take it as passed,
> > > >
> > >
> >
> https://ci-hadoop.apache.org/view/ZooKeeper/job/zookeeper-multi-branch-build/job/branch-3.8.0/34/
> > > > - rat run clean
> > > > - spotbugs, owasp checks passed
> > > > - 3-node TLS quorum up and running with some basic manual tests
> > > >
> > > > Thanks,
> > > > Andor
> > > >
> > > >
> > > >
> > > >
> > > > > On 2022. Feb 28., at 22:02, Patrick Hunt  wrote:
> > > > >
> > > > > +1 - xsum/sig verified. Rat ran clean, compiled fine and I was able
> > to
> > > run
> > > > > some manual clusters successfully.
> > > > >
> > > > > Regards,
> > > > >
> > > > > Patrick
> > > > >
> > > > > On Fri, Feb 25, 2022 at 2:32 AM Enrico Olivelli <
> eolive...@gmail.com
> > >
> > > wrote:
> > > > >
> > > > >> This is the second release candidate for 3.8.0.
> > > > >>
> > > > >> It is a major release and it introduces a lot of new features,
> most
> > > > >> notably:
> > > > >> - Migration of the logging framework from Apache Log4j1 to LogBack
> > > > >> - Read Key/trust store password from file (and other security
> > related
> > > > >> improvements)
> > > > >> - Restored support for OSGI
> > > > >> - Reduced the performance impact of Prometheus metrics
> > > > >> - Official support for JDK17 (all tests are passing)
> > > > >> - Updates to all the third party dependencies to get rid of every
> > > known
> > > > >> CVE.
> > > > >>
> > > > >> The full release notes is available at:
> > > > >>
> > > > >>
> > > > >>
> > >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310801=12349587
> > > > >>
> > > > >> *** Please download, test and vote by February 28th 2022, 23:59
> > > UTC+0. ***
> > > > >>
> > > > >> Source files:
> > > > >>
> > > > >>
> > >
> >
> https://dist.apache.org/repos/dist/dev/zookeeper/zookeeper-3.8.0-candidate-1/
> > > > >>
> > > > >> Maven staging repo:
> > > > >>
> > >
> >
> https://repository.apache.org/content/repositories/orgapachezookeeper-1073/
> > > > >>
> > > > >> The release candidate tag in git to be voted upon: release-3.8.0-1
> > > > >> https://github.com/apache/zookeeper/tree/release-3.8.0-1
> > > > >>
> > > > >> ZooKeeper's KEYS file containing PGP keys we use to sign the
> > release:
> > > > >> https://www.apache.org/dist/zookeeper/KEYS
> > > > >>
> > > > >> The staging version of the website is:
> > > > >>
> > > > >>
> > >
> >
> https://dist.apache.org/repos/dist/dev/zookeeper/zookeeper-3.8.0-candidate-1/website/index.html
> > > > >>
> > > > >>
> > > > >> Should we release this candidate?
> > > > >> Enrico Olivelli
> > > > >>
> > > >
> > >
> >
>

Re: Can't assign jira ticket to myself

[Patrick Hunt]

I added you to the roll. Try now.

Patrick

On Fri, Mar 11, 2022 at 9:22 AM Mathew, Manu 
wrote:

> Thank you for responding.
>
> I don’t see jira ID in the profile.
> mnumtw is the username and manu.mat...@netapp.com manu.mat...@netapp.com> is the email address I have used to set up the
> jira account.
>
> -regards
> Manu Mathew
>
> From: Patrick Hunt 
> Date: Friday, March 11, 2022 at 12:10 PM
> To: DevZooKeeper 
> Subject: Re: Can't assign jira ticket to myself
> NetApp Security WARNING: This is an external email. Do not click links or
> open attachments unless you recognize the sender and know the content is
> safe.
>
>
>
>
> On Fri, Mar 11, 2022 at 8:12 AM Mathew, Manu  .invalid>
> wrote:
>
> > Hi,
> >
> > I have a fix for ClientX509Util keystore/truststore automatic reload, and
> > would like to contribute.
> > Going through the existing issues, I could see that
> > https://issues.apache.org/jira/browse/ZOOKEEPER-3806 is already reported
> > for the missing reload.
> >
> > I am unable to assign the ticket to my name, I assume I don’t have the
> > contributor permission; How do I get the needed permission?
> >
> >
> I can add you to the contributor role - what's your jira ID?
>
> Patrick
>
>
> > Manu Mathew
> >
> >
>

Re: Can't assign jira ticket to myself

[Patrick Hunt]

On Fri, Mar 11, 2022 at 8:12 AM Mathew, Manu 
wrote:

> Hi,
>
> I have a fix for ClientX509Util keystore/truststore automatic reload, and
> would like to contribute.
> Going through the existing issues, I could see that
> https://issues.apache.org/jira/browse/ZOOKEEPER-3806 is already reported
> for the missing reload.
>
> I am unable to assign the ticket to my name, I assume I don’t have the
> contributor permission; How do I get the needed permission?
>
>
I can add you to the contributor role - what's your jira ID?

Patrick


> Manu Mathew
>
>

Re: [VOTE] Apache ZooKeeper release 3.8.0 candidate 1

[Patrick Hunt]

+1 - xsum/sig verified. Rat ran clean, compiled fine and I was able to run
some manual clusters successfully.

Regards,

Patrick

On Fri, Feb 25, 2022 at 2:32 AM Enrico Olivelli  wrote:

> This is the second release candidate for 3.8.0.
>
> It is a major release and it introduces a lot of new features, most
> notably:
> - Migration of the logging framework from Apache Log4j1 to LogBack
> - Read Key/trust store password from file (and other security related
> improvements)
> - Restored support for OSGI
> - Reduced the performance impact of Prometheus metrics
> - Official support for JDK17 (all tests are passing)
> - Updates to all the third party dependencies to get rid of every known
> CVE.
>
> The full release notes is available at:
>
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310801=12349587
>
> *** Please download, test and vote by February 28th 2022, 23:59 UTC+0. ***
>
> Source files:
>
> https://dist.apache.org/repos/dist/dev/zookeeper/zookeeper-3.8.0-candidate-1/
>
> Maven staging repo:
> https://repository.apache.org/content/repositories/orgapachezookeeper-1073/
>
> The release candidate tag in git to be voted upon: release-3.8.0-1
> https://github.com/apache/zookeeper/tree/release-3.8.0-1
>
> ZooKeeper's KEYS file containing PGP keys we use to sign the release:
> https://www.apache.org/dist/zookeeper/KEYS
>
> The staging version of the website is:
>
> https://dist.apache.org/repos/dist/dev/zookeeper/zookeeper-3.8.0-candidate-1/website/index.html
>
>
> Should we release this candidate?
> Enrico Olivelli
>

Re: [VOTE] Apache ZooKeeper release 3.8.0 candidate 1

[Patrick Hunt]

The license file in the binary (which also comes from the src) doesn't
match the jar version:

  -rw-r--r--   1 phunt  staff   327135 Jan 16 23:54 commons-io-2.11.0.jar
  -rw-r--r--   1 phunt  staff11359 Feb 25 00:47
commons-io-2.7.LICENSE.txt

Is this something you want to fix, or not a release blocker, I can't
remember how we treat this...

Patrick

On Fri, Feb 25, 2022 at 2:32 AM Enrico Olivelli  wrote:

> This is the second release candidate for 3.8.0.
>
> It is a major release and it introduces a lot of new features, most
> notably:
> - Migration of the logging framework from Apache Log4j1 to LogBack
> - Read Key/trust store password from file (and other security related
> improvements)
> - Restored support for OSGI
> - Reduced the performance impact of Prometheus metrics
> - Official support for JDK17 (all tests are passing)
> - Updates to all the third party dependencies to get rid of every known
> CVE.
>
> The full release notes is available at:
>
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310801=12349587
>
> *** Please download, test and vote by February 28th 2022, 23:59 UTC+0. ***
>
> Source files:
>
> https://dist.apache.org/repos/dist/dev/zookeeper/zookeeper-3.8.0-candidate-1/
>
> Maven staging repo:
> https://repository.apache.org/content/repositories/orgapachezookeeper-1073/
>
> The release candidate tag in git to be voted upon: release-3.8.0-1
> https://github.com/apache/zookeeper/tree/release-3.8.0-1
>
> ZooKeeper's KEYS file containing PGP keys we use to sign the release:
> https://www.apache.org/dist/zookeeper/KEYS
>
> The staging version of the website is:
>
> https://dist.apache.org/repos/dist/dev/zookeeper/zookeeper-3.8.0-candidate-1/website/index.html
>
>
> Should we release this candidate?
> Enrico Olivelli
>

Re: Jira permission request

[Patrick Hunt]

On Mon, Feb 21, 2022 at 10:16 AM Enrico Olivelli 
wrote:

> Patrick,
>
> Il Lun 21 Feb 2022, 17:37 Patrick Hunt  ha scritto:
>
> > Actually we do have a "Contributor" role that allows eg jira assignment.
>
>
> I missed this asset
>

No worries at all. I think JIRA admin panel itself has changed pretty
significantly of late - I had to look for a while myself to grok how to do
it now.

Regards,

Patrick


>
> Thanks
> Enrico
>
> I
> > added Kezhu to the list.
> >
> > Regards,
> >
> > Patrick
> >
> >
> > On Sun, Feb 20, 2022 at 5:05 PM Kezhu Wang  wrote:
> >
> > > Hi Enrico,
> > >
> > > I will ping you at jira for issue assignment and discussion.
> > >
> > > Thanks.
> > >
> > > Best,
> > > Kezhu Wang
> > >
> > > On Mon, Feb 21, 2022 at 2:54 AM Enrico Olivelli 
> > > wrote:
> > >
> > > > Hello Kezhu,
> > > > Welcome to the project!
> > > >
> > > >
> > > > In this project we are used to grant jira permissions only to
> > committers.
> > > >
> > > > All you have to do is to add a comment on the ticket you want to pick
> > up.
> > > >
> > > > Use this mailing list to discuss about your ideas or share any
> > problems.
> > > >
> > > > We will be happy to help you
> > > >
> > > > Looking forward to your patches!
> > > >
> > > > Thanks
> > > >
> > > > Enrico
> > > >
> > > > Il Dom 20 Feb 2022, 14:19 Kezhu Wang  ha scritto:
> > > >
> > > > > Hi devs, I want to contribute to ZooKeeper.
> > > > >
> > > > > Could anyone here give me jira tickets permission ? My jira id is:
> > > kezhuw
> > > > >
> > > > > Thanks!
> > > > >
> > > > > Best,
> > > > > Kezhu Wang
> > > > >
> > > >
> > >
> >
>

Re: Jira permission request

[Patrick Hunt]

Actually we do have a "Contributor" role that allows eg jira assignment. I
added Kezhu to the list.

Regards,

Patrick


On Sun, Feb 20, 2022 at 5:05 PM Kezhu Wang  wrote:

> Hi Enrico,
>
> I will ping you at jira for issue assignment and discussion.
>
> Thanks.
>
> Best,
> Kezhu Wang
>
> On Mon, Feb 21, 2022 at 2:54 AM Enrico Olivelli 
> wrote:
>
> > Hello Kezhu,
> > Welcome to the project!
> >
> >
> > In this project we are used to grant jira permissions only to committers.
> >
> > All you have to do is to add a comment on the ticket you want to pick up.
> >
> > Use this mailing list to discuss about your ideas or share any problems.
> >
> > We will be happy to help you
> >
> > Looking forward to your patches!
> >
> > Thanks
> >
> > Enrico
> >
> > Il Dom 20 Feb 2022, 14:19 Kezhu Wang  ha scritto:
> >
> > > Hi devs, I want to contribute to ZooKeeper.
> > >
> > > Could anyone here give me jira tickets permission ? My jira id is:
> kezhuw
> > >
> > > Thanks!
> > >
> > > Best,
> > > Kezhu Wang
> > >
> >
>

Re: Moving 3.5 to EOL

[Patrick Hunt]

on server side,
> >- Previous version of ZooKeeper server is able to accept connections
> > from
> > clients as long as they don’t want to use new features.
> >
> > - Curator already supports later versions - Is it true for 3.6, 3.7?
> >
> > It’s February now, so if we nail down the above points, I don’t see any
> > objections against announcing 3.5 EoL for 1st of June, 2022 (2 years
> after
> > 3.4 EoL, providing 4 months to upgrade). Maybe we can also communicate
> that
> > we’re going to officially EoL the least recent ZK version every 2 years.
> >
> > Andor
> >
> >
> >
> >
> > > On 2022. Feb 9., at 20:28, Patrick Hunt  wrote:
> > >
> > > On Wed, Feb 9, 2022 at 3:07 AM Andor Molnar  wrote:
> > >
> > >> Hi Pat,
> > >>
> > >> Yeah, I asked for a more specific suggestion from you. If we avoid
> using
> > >> the LTS in ZooKeeper releases and stay with the stable/latest labels,
> > how
> > >> would you label the current maintained versions?
> > >>
> > >
> > > Ah, ok. No worries Andor, I misunderstood. My 0.02:
> > >
> > > We have "stable" and "current" already identified.
> > > https://dlcdn.apache.org/zookeeper/
> > > Stable was last updated in April of 2021. My recommendation is that we
> > > should change the process to notify EOL prior to updating e.g. "stable"
> > > reference. Stable is our indication w/o using the LTS label. As long as
> > we
> > > have a public policy & associated announcements, I think that's fine.
> > >
> > > I also bring your attention to this conversation thread from March 2020
> > for
> > > the previous EOL'd (3.4) release line:
> > > https://markmail.org/message/b2pqcztlb2ixoyjp
> > > Some good ideas in there from many folks, I think we settled on a
> > timeframe
> > > we felt comfortable with, at least at the time. Unfortunately we did
> not
> > > follow through with a plan for future releases. Perhaps we can do that
> > now.
> > >
> > > Regards,
> > >
> > > Patrick
> > >
> > >
> > >>
> > >> Enrico is about to release 3.8.0 soon, so we’ll end up having four
> > >> versions in maintenance. What should we do with it to reduce the
> > >> maintenance cost?
> > >>
> > >> Andor
> > >>
> > >>
> > >>
> > >>
> > >>> On 2022. Feb 4., at 17:58, Patrick Hunt  wrote:
> > >>>
> > >>> On Fri, Feb 4, 2022 at 8:19 AM Andor Molnar 
> wrote:
> > >>>
> > >>>> More specifically?
> > >>>>
> > >>>
> > >>> Are you asking me? :-)  "LTS" literally has a definition in
> wikipedia:
> > >>> https://en.wikipedia.org/wiki/Long-term_support
> > >>>
> > >>>
> > >>>>
> > >>>> Stable 3.5, 3.6, 3.7, 3.8 and EoL 3.5 at the end of the year (1st of
> > >> Jan,
> > >>>> 2023)?
> > >>>>
> > >>>> Andor
> > >>>>
> > >>>>
> > >>>>
> > >>>>> On 2022. Feb 1., at 16:41, Patrick Hunt  wrote:
> > >>>>>
> > >>>>> "LTS" typically has meaning for folks beyond just what the words
> say.
> > >> JDK
> > >>>>> LTS. Ubuntu LTS. etc... I think it would be less confusing to stay
> > with
> > >>>> the
> > >>>>> stable/latest labels we have had in the past and plan ahead a bit
> in
> > >>>> terms
> > >>>>> of giving notice when releases will be removed from support.
> > >>>>>
> > >>>>> Patrick
> > >>>>>
> > >>>>> On Tue, Feb 1, 2022 at 3:12 AM Andor Molnar 
> > wrote:
> > >>>>>
> > >>>>>> Hi Andrew,
> > >>>>>>
> > >>>>>> I think that wasn’t a general plan from the community at that
> time,
> > >> just
> > >>>>>> my opinion based on how long 3.4 was the stable release of
> ZooKeeper
> > >> (4
> > >>>>>> years). Since then the release schedule has become much faster and
> > to
> > >> be
> > >>>>>> honest I’m n

Re: [VOTE] Apache ZooKeeper release 3.8.0 candidate 0

[Patrick Hunt]

al exception(s) analyzing Apache
> > > > ZooKeeper: One or more exceptions occurred during analysis:
> > > > [ERROR] Unable to download meta file:
> > > > https://nvd.nist.gov/feeds/json/cve/1.1/nvdcve-1.1-2004.meta
> > > > [ERROR] No documents exist
> > > > [ERROR] -> [Help 1]
> > > >
> > > > Now I just re-run and this error disappeared, I assume nvd.nist.gov
> was
> > > > down for a while.
> > > > Now the owasp is failing for me with this error:
> > > >
> > > > [ERROR] Failed to execute goal
> > > org.owasp:dependency-check-maven:5.3.0:check
> > > > (default-cli) on project zookeeper:
> > > > [ERROR]
> > > > [ERROR] One or more dependencies were identified with vulnerabilities
> > > that
> > > > have a CVSS score greater than or equal to '0.0':
> > > > [ERROR]
> > > > [ERROR] netty-tcnative-2.0.48.Final.jar: CVE-2021-43797,
> CVE-2019-16869,
> > > > CVE-2015-2156, CVE-2021-37136, CVE-2014-3488, CVE-2021-37137,
> > > > CVE-2019-20445, CVE-2019-20444, CVE-2021-21295, CVE-2021-21409,
> > > > CVE-2021-21290
> > > > [ERROR]
> > > > [ERROR] See the dependency-check report for more details.
> > > >
> > > >
> > > > I still continue to test the RC, let me know if it gets cancelled.
> > > >
> > > >
> > > > On Tue, Feb 8, 2022 at 9:52 PM Patrick Hunt 
> wrote:
> > > >
> > > > > On Tue, Feb 8, 2022 at 12:36 PM Enrico Olivelli <
> eolive...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Any comments?
> > > > > >
> > > > >
> > > > > owasp is still red - as such I assumed this release candidate is on
> > > hold
> > > > > until that's fixed. Is that not the case?
> > > > >
> > > > > Patrick
> > > > >
> > > > >
> > > > > >
> > > > > > Il Ven 4 Feb 2022, 12:07 Enrico Olivelli 
> ha
> > > > > > scritto:
> > > > > >
> > > > > > > This is a release candidate for 3.8.0.
> > > > > > >
> > > > > > > It is a major release and it introduces a lot of new features,
> most
> > > > > > > notably:
> > > > > > > - Migration of the logging framework from Apache Log4j1 to
> LogBack
> > > > > > > - Read Key/trust store password from file (and other security
> > > related
> > > > > > > improvements)
> > > > > > > - Restored support for OSGI
> > > > > > > - Reduced the performance impact of Prometheus metrics
> > > > > > > - Official support for JDK17 (all tests are passing)
> > > > > > > - Updates to all the third party dependencies to get rid of
> every
> > > > known
> > > > > > > CVE.
> > > > > > >
> > > > > > > The full release notes is available at:
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310801=12349587
> > > > > > >
> > > > > > > *** Please download, test and vote by February 7th 2022, 23:59
> > > UTC+0.
> > > > > ***
> > > > > > >
> > > > > > > Source files:
> > > > > > >
> https://people.apache.org/~eolivelli/zookeeper-3.8.0-candidate-0/
> > > > > > >
> > > > > > > Maven staging repo:
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> https://repository.apache.org/content/repositories/orgapachezookeeper-1072/
> > > > > > >
> > > > > > > The release candidate tag in git to be voted upon:
> release-3.8.0-0
> > > > > > > https://github.com/apache/zookeeper/tree/release-3.8.0-0
> > > > > > >
> > > > > > > ZooKeeper's KEYS file containing PGP keys we use to sign the
> > > release:
> > > > > > > https://www.apache.org/dist/zookeeper/KEYS
> > > > > > >
> > > > > > > The staging version of the website is:
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> https://people.apache.org/~eolivelli/zookeeper-3.8.0-candidate-0/website/
> > > > > > >
> > > > > > >
> > > > > > > Should we release this candidate?
> > > > > > > Enrico Olivelli
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
>

Re: Moving 3.5 to EOL

[Patrick Hunt]

On Wed, Feb 9, 2022 at 3:07 AM Andor Molnar  wrote:

> Hi Pat,
>
> Yeah, I asked for a more specific suggestion from you. If we avoid using
> the LTS in ZooKeeper releases and stay with the stable/latest labels, how
> would you label the current maintained versions?
>

Ah, ok. No worries Andor, I misunderstood. My 0.02:

We have "stable" and "current" already identified.
https://dlcdn.apache.org/zookeeper/
Stable was last updated in April of 2021. My recommendation is that we
should change the process to notify EOL prior to updating e.g. "stable"
reference. Stable is our indication w/o using the LTS label. As long as we
have a public policy & associated announcements, I think that's fine.

I also bring your attention to this conversation thread from March 2020 for
the previous EOL'd (3.4) release line:
https://markmail.org/message/b2pqcztlb2ixoyjp
Some good ideas in there from many folks, I think we settled on a timeframe
we felt comfortable with, at least at the time. Unfortunately we did not
follow through with a plan for future releases. Perhaps we can do that now.

Regards,

Patrick


>
> Enrico is about to release 3.8.0 soon, so we’ll end up having four
> versions in maintenance. What should we do with it to reduce the
> maintenance cost?
>
> Andor
>
>
>
>
> > On 2022. Feb 4., at 17:58, Patrick Hunt  wrote:
> >
> > On Fri, Feb 4, 2022 at 8:19 AM Andor Molnar  wrote:
> >
> >> More specifically?
> >>
> >
> > Are you asking me? :-)  "LTS" literally has a definition in wikipedia:
> > https://en.wikipedia.org/wiki/Long-term_support
> >
> >
> >>
> >> Stable 3.5, 3.6, 3.7, 3.8 and EoL 3.5 at the end of the year (1st of
> Jan,
> >> 2023)?
> >>
> >> Andor
> >>
> >>
> >>
> >>> On 2022. Feb 1., at 16:41, Patrick Hunt  wrote:
> >>>
> >>> "LTS" typically has meaning for folks beyond just what the words say.
> JDK
> >>> LTS. Ubuntu LTS. etc... I think it would be less confusing to stay with
> >> the
> >>> stable/latest labels we have had in the past and plan ahead a bit in
> >> terms
> >>> of giving notice when releases will be removed from support.
> >>>
> >>> Patrick
> >>>
> >>> On Tue, Feb 1, 2022 at 3:12 AM Andor Molnar  wrote:
> >>>
> >>>> Hi Andrew,
> >>>>
> >>>> I think that wasn’t a general plan from the community at that time,
> just
> >>>> my opinion based on how long 3.4 was the stable release of ZooKeeper
> (4
> >>>> years). Since then the release schedule has become much faster and to
> be
> >>>> honest I’m not participating in it.
> >>>>
> >>>> As mentioned 3.6 and 3.7 releases are not much different. 3.6 is the
> >>>> “Facebook” version which is well tested and contains lots of patches
> >> that
> >>>> improves robustness. Both versions are good candidates for upgrade, so
> >>>> announcing 3.5 EoL (at least half year from now) is not necessarily
> bad.
> >>>>
> >>>> As an alternative, staying with the LT(S|M) / non-LT(S|M) terms, I
> think
> >>>> the following could also be considered for the community:
> >>>>
> >>>> Now:
> >>>>
> >>>> master
> >>>> --
> >>>> 3.7
> >>>> 3.6
> >>>> 3.5 LTS
> >>>> --
> >>>> 3.4 EoL
> >>>>
> >>>> Can become:
> >>>>
> >>>> master
> >>>> --
> >>>> 3.8 LTS
> >>>> 3.7
> >>>> 3.5 LTS
> >>>> --
> >>>> 3.6 EoL
> >>>> 3.4 EoL
> >>>>
> >>>> In order to keep the number of maintained branches low.
> >>>>
> >>>> What do you think?
> >>>>
> >>>> Andor
> >>>>
> >>>>
> >>>>
> >>>>> On 2022. Jan 31., at 19:41, Andrew Purtell 
> >> wrote:
> >>>>>
> >>>>> Just to be clear I meant 'you' as the ZooKeeper project as a whole,
> but
> >>>>> maybe I have misunderstood this response:
> >>>>>
> >>>>
> >>
> https://issues.apache.org/jira/browse/HADOOP-17612?focusedCommentId=17311792=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17311792
> &g

Re: [VOTE] Apache ZooKeeper release 3.8.0 candidate 0

[Patrick Hunt]

On Tue, Feb 8, 2022 at 12:36 PM Enrico Olivelli  wrote:

> Any comments?
>

owasp is still red - as such I assumed this release candidate is on hold
until that's fixed. Is that not the case?

Patrick


>
> Il Ven 4 Feb 2022, 12:07 Enrico Olivelli  ha
> scritto:
>
> > This is a release candidate for 3.8.0.
> >
> > It is a major release and it introduces a lot of new features, most
> > notably:
> > - Migration of the logging framework from Apache Log4j1 to LogBack
> > - Read Key/trust store password from file (and other security related
> > improvements)
> > - Restored support for OSGI
> > - Reduced the performance impact of Prometheus metrics
> > - Official support for JDK17 (all tests are passing)
> > - Updates to all the third party dependencies to get rid of every known
> > CVE.
> >
> > The full release notes is available at:
> >
> >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310801=12349587
> >
> > *** Please download, test and vote by February 7th 2022, 23:59 UTC+0. ***
> >
> > Source files:
> > https://people.apache.org/~eolivelli/zookeeper-3.8.0-candidate-0/
> >
> > Maven staging repo:
> >
> https://repository.apache.org/content/repositories/orgapachezookeeper-1072/
> >
> > The release candidate tag in git to be voted upon: release-3.8.0-0
> > https://github.com/apache/zookeeper/tree/release-3.8.0-0
> >
> > ZooKeeper's KEYS file containing PGP keys we use to sign the release:
> > https://www.apache.org/dist/zookeeper/KEYS
> >
> > The staging version of the website is:
> >
> https://people.apache.org/~eolivelli/zookeeper-3.8.0-candidate-0/website/
> >
> >
> > Should we release this candidate?
> > Enrico Olivelli
> >
>

Re: Cutting 3.8.0 release

[Patrick Hunt]

On Fri, Feb 4, 2022 at 2:29 PM Enrico Olivelli  wrote:

> Il Ven 4 Feb 2022, 19:27 Patrick Hunt  ha scritto:
>
> > The branches, including 3.8.0, are still failing the owasp check due to
> > netty-tcnative
> >
> >
> https://ci-hadoop.apache.org/view/ZooKeeper/job/zookeeper-multi-branch-owasp/job/branch-3.8.0/3/console
> > I see this jira was closed:
> > https://issues.apache.org/jira/browse/ZOOKEEPER-4462
> > and I can't find any other - what's the plan on addressing this? I'm not
> > familiar with this dependency, has anyone dug into this?
> >
>
> I am sorry.
> I saw the jenkins job and I did not report it to the list.
>
>
No worries at all Enrico, appreciate your efforts.


> I closed the issue without adding the exclusion.
>
> I checked some of those CVEs, and they seem to be not directly related to
> that version in particular.
>
> I have upgraded to the latest version that is available.
>
> Also I think that we are not using that library directly as we are not
> using Netty native TLS support. We should include the Netty Boring SSL
> library and activate time.
>
> We should add the exclusion.
>
> I believe that the release candidate is safe
>
> Thanks for reporting this
>
>
NP. I also see a number of JIRA that are now invalid, iiuc. Could you
review/close/address as appropriate? They are all relative to netty CVE in
ZK:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20ZOOKEEPER%20and%20resolution%20%3D%20unresolved%20and%20summary%20~%20%22netty%20cve*%22%20ORDER%20BY%20created%20DESC

Thanks!

Patrick



> Enrico
>
> >
> > *23:07:49*  One or more dependencies were identified with known
> > vulnerabilities in Apache ZooKeeper - Server:*23:07:49*  *23:07:49*
> > netty-tcnative-2.0.48.Final.jar
> > (pkg:maven/io.netty/netty-tcnative@2.0.48.Final,
> > cpe:2.3:a:netty:netty:2.0.48:*:*:*:*:*:*:*) : CVE-2014-3488,
> > CVE-2015-2156, CVE-2019-16869, CVE-2019-20444, CVE-2019-20445,
> > CVE-2021-21290, CVE-2021-21295, CVE-2021-21409, CVE-2021-37136,
> > CVE-2021-37137, CVE-2021-43797
> >
> >
> >
> > Patrick
> >
> > On Mon, Jan 31, 2022 at 4:22 AM Enrico Olivelli 
> > wrote:
> >
> > > updates..
> > > I am still waiting for CI on this Netty TCNative upgrade, that has a
> CVE
> > > report
> > > https://github.com/apache/zookeeper/pull/1810
> > >
> > > it also needs a reviewer please
> > >
> > > Enrico
> > >
> > > Il giorno lun 31 gen 2022 alle ore 11:33 Enrico Olivelli
> > >  ha scritto:
> > > >
> > > > Andor,
> > > > sorry, I misunderstood your question.
> > > >
> > > > Yes, we must name it 3.8.0 due to Lockback
> > > >
> > > > Enrico
> > > >
> > > > Il giorno lun 31 gen 2022 alle ore 11:24 Enrico Olivelli
> > > >  ha scritto:
> > > > >
> > > > > Il giorno lun 31 gen 2022 alle ore 10:49 Andor Molnar
> > > > >  ha scritto:
> > > > > >
> > > > > > What’s the reason for cutting a new minor release?
> > > > > > The logback migration?
> > > > > >
> > > > > > 3.7 only has a single patch release so far: 3.7.0
> > > > > >
> > > > > > Isn’t that too early?
> > > > >
> > > > > for 3.7.1 we have to merge the upgrades of the libraries with CVEs,
> > > like Netty
> > > > > and also we have the fix for the k8s users with
> NettyServerConnection
> > > > > factory, that is a blocker for people on k8s
> > > > >
> > > > > >
> > > > > > Andor
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > > On 2022. Jan 28., at 16:28, Enrico Olivelli <
> eolive...@gmail.com
> > >
> > > wrote:
> > > > > > >
> > > > > > > Sure.
> > > > > > >
> > > > > > > Il giorno ven 28 gen 2022 alle ore 14:19 Szalay-Bekő Máté
> > > > > > >  ha scritto:
> > > > > > >>
> > > > > > >> Great news, thanks for the work, Enrico!!
> > > > > > >>
> > > > > > >> I think we should wait for
> > > https://github.com/apache/zookeeper/pull/1807 (
> > > > > > >> https://issues.apache.org/jira/browse/ZOOKEEPER-4461) so that
> > we
> > > ca

Re: Cutting 3.8.0 release

[Patrick Hunt]

The branches, including 3.8.0, are still failing the owasp check due to
netty-tcnative
https://ci-hadoop.apache.org/view/ZooKeeper/job/zookeeper-multi-branch-owasp/job/branch-3.8.0/3/console
I see this jira was closed:
https://issues.apache.org/jira/browse/ZOOKEEPER-4462
and I can't find any other - what's the plan on addressing this? I'm not
familiar with this dependency, has anyone dug into this?

*23:07:49*  One or more dependencies were identified with known
vulnerabilities in Apache ZooKeeper - Server:*23:07:49*  *23:07:49*
netty-tcnative-2.0.48.Final.jar
(pkg:maven/io.netty/netty-tcnative@2.0.48.Final,
cpe:2.3:a:netty:netty:2.0.48:*:*:*:*:*:*:*) : CVE-2014-3488,
CVE-2015-2156, CVE-2019-16869, CVE-2019-20444, CVE-2019-20445,
CVE-2021-21290, CVE-2021-21295, CVE-2021-21409, CVE-2021-37136,
CVE-2021-37137, CVE-2021-43797



Patrick

On Mon, Jan 31, 2022 at 4:22 AM Enrico Olivelli  wrote:

> updates..
> I am still waiting for CI on this Netty TCNative upgrade, that has a CVE
> report
> https://github.com/apache/zookeeper/pull/1810
>
> it also needs a reviewer please
>
> Enrico
>
> Il giorno lun 31 gen 2022 alle ore 11:33 Enrico Olivelli
>  ha scritto:
> >
> > Andor,
> > sorry, I misunderstood your question.
> >
> > Yes, we must name it 3.8.0 due to Lockback
> >
> > Enrico
> >
> > Il giorno lun 31 gen 2022 alle ore 11:24 Enrico Olivelli
> >  ha scritto:
> > >
> > > Il giorno lun 31 gen 2022 alle ore 10:49 Andor Molnar
> > >  ha scritto:
> > > >
> > > > What’s the reason for cutting a new minor release?
> > > > The logback migration?
> > > >
> > > > 3.7 only has a single patch release so far: 3.7.0
> > > >
> > > > Isn’t that too early?
> > >
> > > for 3.7.1 we have to merge the upgrades of the libraries with CVEs,
> like Netty
> > > and also we have the fix for the k8s users with NettyServerConnection
> > > factory, that is a blocker for people on k8s
> > >
> > > >
> > > > Andor
> > > >
> > > >
> > > >
> > > >
> > > > > On 2022. Jan 28., at 16:28, Enrico Olivelli 
> wrote:
> > > > >
> > > > > Sure.
> > > > >
> > > > > Il giorno ven 28 gen 2022 alle ore 14:19 Szalay-Bekő Máté
> > > > >  ha scritto:
> > > > >>
> > > > >> Great news, thanks for the work, Enrico!!
> > > > >>
> > > > >> I think we should wait for
> https://github.com/apache/zookeeper/pull/1807 (
> > > > >> https://issues.apache.org/jira/browse/ZOOKEEPER-4461) so that we
> can
> > > > >> eliminate all references for log4j1 from our pom.xml files. What
> do
> > > > >> you think?
> > > > >
> > > > > good catch
> > > > >
> > > > > the patch looks good, let's commit it as soon as CI passes
> > > > >
> > > > > Enrico
> > > > >
> > > > >>
> > > > >> Regards,
> > > > >> Máté
> > > > >>
> > > > >>
> > > > >> On Fri, Jan 28, 2022 at 5:24 AM Chris Nauroth 
> wrote:
> > > > >>
> > > > >>> +1
> > > > >>>
> > > > >>> Thanks for driving this, Enrico!
> > > > >>>
> > > > >>> Chris Nauroth
> > > > >>>
> > > > >>>
> > > > >>> On Thu, Jan 27, 2022 at 7:08 AM Enrico Olivelli <
> eolive...@gmail.com>
> > > > >>> wrote:
> > > > >>>
> > > >  Hello ZooKeepers,
> > > >  I believe that the master branch is in good shape.
> > > > 
> > > >  I would like to start the release procedure for 3.8.0.
> > > > 
> > > >  This is the list of issues for 3.8.0
> > > > 
> > > > 
> > > > >>>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20ZOOKEEPER%20AND%20fixVersion%20%3D%203.8.0
> > > > 
> > > >  We recently addressed all of the CVEs by updating some key
> > > >  dependencies, like Netty, and moving away from Log4j1 (we
> switched to
> > > >  LogBack)
> > > > 
> > > >  If no one has objections I will start the release procedure on
> Monday
> > > > 
> > > >  Regards
> > > > 
> > > >  Enrico
> > > > 
> > > > >>>
> > > >
>

Re: Moving 3.5 to EOL

[Patrick Hunt]

On Fri, Feb 4, 2022 at 8:19 AM Andor Molnar  wrote:

> More specifically?
>

Are you asking me? :-)  "LTS" literally has a definition in wikipedia:
https://en.wikipedia.org/wiki/Long-term_support


>
> Stable 3.5, 3.6, 3.7, 3.8 and EoL 3.5 at the end of the year (1st of Jan,
> 2023)?
>
> Andor
>
>
>
> > On 2022. Feb 1., at 16:41, Patrick Hunt  wrote:
> >
> > "LTS" typically has meaning for folks beyond just what the words say. JDK
> > LTS. Ubuntu LTS. etc... I think it would be less confusing to stay with
> the
> > stable/latest labels we have had in the past and plan ahead a bit in
> terms
> > of giving notice when releases will be removed from support.
> >
> > Patrick
> >
> > On Tue, Feb 1, 2022 at 3:12 AM Andor Molnar  wrote:
> >
> >> Hi Andrew,
> >>
> >> I think that wasn’t a general plan from the community at that time, just
> >> my opinion based on how long 3.4 was the stable release of ZooKeeper (4
> >> years). Since then the release schedule has become much faster and to be
> >> honest I’m not participating in it.
> >>
> >> As mentioned 3.6 and 3.7 releases are not much different. 3.6 is the
> >> “Facebook” version which is well tested and contains lots of patches
> that
> >> improves robustness. Both versions are good candidates for upgrade, so
> >> announcing 3.5 EoL (at least half year from now) is not necessarily bad.
> >>
> >> As an alternative, staying with the LT(S|M) / non-LT(S|M) terms, I think
> >> the following could also be considered for the community:
> >>
> >> Now:
> >>
> >> master
> >> --
> >> 3.7
> >> 3.6
> >> 3.5 LTS
> >> --
> >> 3.4 EoL
> >>
> >> Can become:
> >>
> >> master
> >> --
> >> 3.8 LTS
> >> 3.7
> >> 3.5 LTS
> >> --
> >> 3.6 EoL
> >> 3.4 EoL
> >>
> >> In order to keep the number of maintained branches low.
> >>
> >> What do you think?
> >>
> >> Andor
> >>
> >>
> >>
> >>> On 2022. Jan 31., at 19:41, Andrew Purtell 
> wrote:
> >>>
> >>> Just to be clear I meant 'you' as the ZooKeeper project as a whole, but
> >>> maybe I have misunderstood this response:
> >>>
> >>
> https://issues.apache.org/jira/browse/HADOOP-17612?focusedCommentId=17311792=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17311792
> >>>
> >>>
> >>> On Sun, Jan 30, 2022 at 10:29 AM Enrico Olivelli 
> >>> wrote:
> >>>
> >>>> Il Dom 30 Gen 2022, 17:51 Andrew Purtell 
> ha
> >>>> scritto:
> >>>>
> >>>>> Previously in various contexts - specifically, I am thinking of a
> >> Hadoop
> >>>>> JIRA where we once had a conversation on this topic, but I believe
> >> there
> >>>>> have been others - you have declared 3.5 a long term stable (LTS)
> >>>> release.
> >>>>>
> >>>>> A sudden EOL of an LTS is jarring and makes future promise of LTS
> >>>>> untrustworthy. What I would recommend for what it’s worth is a
> >> timetable
> >>>> to
> >>>>> EOL of 3.5 that is reasonably long, like one or two years, should you
> >>>>> decide to EOL it.
> >>>>
> >>>>
> >>>> I am sorry,
> >>>> I forgot about such conversation.
> >>>>
> >>>> Can you share some pointers ?
> >>>>
> >>>> No problem from my side as soon as there is someone who needs 3.5 and
> >> that
> >>>> is willing to help.
> >>>>
> >>>> Our codebase is pretty stable and we usually pay much attention  to
> >>>> compatibility. So I am sure that 3.5 clients will be able to connect
> to
> >> new
> >>>> servers (and vice versa)
> >>>>
> >>>> I opened up this discussion to see how much interest is in the
> >> community,
> >>>> so from your response I understand that there is such interest.
> >>>>
> >>>> Thanks for answering
> >>>>
> >>>> Enrico
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>
> >>>>>
> >>>>>> On Jan 30, 2022, at 5:00 AM, Enrico Olivelli 
> >>>>> wrote:
> >>>>>>
> >>>>>> Hello,
> >>>>>> We are going to release 3.8.0.
> >>>>>> It is time to think about moving 3.5 to EOL.
> >>>>>>
> >>>>>> Key points:
> >>>>>> - we already have a few other "active" branches, 3.6 and 3.7
> >>>>>> - 3.5 still has "ant" files, and cherry picking libraries upgrade is
> >>>>>> awkward  (you always have to create a separate patch)
> >>>>>> - moving to 3.6 is quite easy, so people should not be stuck if
> >>>>>> requested to upgrade to 3.6
> >>>>>>
> >>>>>> Thoughts ?
> >>>>>>
> >>>>>>
> >>>>>> Enrico
> >>>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> Best regards,
> >>> Andrew
> >>>
> >>> Unrest, ignorance distilled, nihilistic imbeciles -
> >>>   It's what we’ve earned
> >>> Welcome, apocalypse, what’s taken you so long?
> >>> Bring us the fitting end that we’ve been counting on
> >>>  - A23, Welcome, Apocalypse
> >>
> >>
>
>

Re: Moving 3.5 to EOL

[Patrick Hunt]

"LTS" typically has meaning for folks beyond just what the words say. JDK
LTS. Ubuntu LTS. etc... I think it would be less confusing to stay with the
stable/latest labels we have had in the past and plan ahead a bit in terms
of giving notice when releases will be removed from support.

Patrick

On Tue, Feb 1, 2022 at 3:12 AM Andor Molnar  wrote:

> Hi Andrew,
>
> I think that wasn’t a general plan from the community at that time, just
> my opinion based on how long 3.4 was the stable release of ZooKeeper (4
> years). Since then the release schedule has become much faster and to be
> honest I’m not participating in it.
>
> As mentioned 3.6 and 3.7 releases are not much different. 3.6 is the
> “Facebook” version which is well tested and contains lots of patches that
> improves robustness. Both versions are good candidates for upgrade, so
> announcing 3.5 EoL (at least half year from now) is not necessarily bad.
>
> As an alternative, staying with the LT(S|M) / non-LT(S|M) terms, I think
> the following could also be considered for the community:
>
> Now:
>
> master
> --
> 3.7
> 3.6
> 3.5 LTS
> --
> 3.4 EoL
>
> Can become:
>
> master
> --
> 3.8 LTS
> 3.7
> 3.5 LTS
> --
> 3.6 EoL
> 3.4 EoL
>
> In order to keep the number of maintained branches low.
>
> What do you think?
>
> Andor
>
>
>
> > On 2022. Jan 31., at 19:41, Andrew Purtell  wrote:
> >
> > Just to be clear I meant 'you' as the ZooKeeper project as a whole, but
> > maybe I have misunderstood this response:
> >
> https://issues.apache.org/jira/browse/HADOOP-17612?focusedCommentId=17311792=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17311792
> >
> >
> > On Sun, Jan 30, 2022 at 10:29 AM Enrico Olivelli 
> > wrote:
> >
> >> Il Dom 30 Gen 2022, 17:51 Andrew Purtell  ha
> >> scritto:
> >>
> >>> Previously in various contexts - specifically, I am thinking of a
> Hadoop
> >>> JIRA where we once had a conversation on this topic, but I believe
> there
> >>> have been others - you have declared 3.5 a long term stable (LTS)
> >> release.
> >>>
> >>> A sudden EOL of an LTS is jarring and makes future promise of LTS
> >>> untrustworthy. What I would recommend for what it’s worth is a
> timetable
> >> to
> >>> EOL of 3.5 that is reasonably long, like one or two years, should you
> >>> decide to EOL it.
> >>
> >>
> >> I am sorry,
> >> I forgot about such conversation.
> >>
> >> Can you share some pointers ?
> >>
> >> No problem from my side as soon as there is someone who needs 3.5 and
> that
> >> is willing to help.
> >>
> >> Our codebase is pretty stable and we usually pay much attention  to
> >> compatibility. So I am sure that 3.5 clients will be able to connect to
> new
> >> servers (and vice versa)
> >>
> >> I opened up this discussion to see how much interest is in the
> community,
> >> so from your response I understand that there is such interest.
> >>
> >> Thanks for answering
> >>
> >> Enrico
> >>
> >>
> >>
> >>
> >>
> >>>
> >>>
>  On Jan 30, 2022, at 5:00 AM, Enrico Olivelli 
> >>> wrote:
> 
>  Hello,
>  We are going to release 3.8.0.
>  It is time to think about moving 3.5 to EOL.
> 
>  Key points:
>  - we already have a few other "active" branches, 3.6 and 3.7
>  - 3.5 still has "ant" files, and cherry picking libraries upgrade is
>  awkward  (you always have to create a separate patch)
>  - moving to 3.6 is quite easy, so people should not be stuck if
>  requested to upgrade to 3.6
> 
>  Thoughts ?
> 
> 
>  Enrico
> >>>
> >>
> >
> >
> > --
> > Best regards,
> > Andrew
> >
> > Unrest, ignorance distilled, nihilistic imbeciles -
> >It's what we’ve earned
> > Welcome, apocalypse, what’s taken you so long?
> > Bring us the fitting end that we’ve been counting on
> >   - A23, Welcome, Apocalypse
>
>

Re: Logback

[Patrick Hunt]

On Fri, Jan 7, 2022 at 12:10 PM Ted Dunning  wrote:

> I have been watching the private and public mailing lists for Apache
> Logging as part of $dayjob as well.
>
> I read the mood there differently. The most recent comment I remember was a
> confirmation that "no bugfixes or security patches are planned for log4j1".
>
> Log4j2 really is much larger than necessary. This is, in my opinion, the
> root cause of the recent farago.
>
> But having a cutaway by using slf4j is a very reasonable position to take
> there. Customers can use log4j2 if they want to or opt for simpler systems.
> Our default can be as simple as we like (even just util.logging).
>
>
That is a really good point Ted, one that came to mind a couple weeks ago
but I never circled back on - why are we not using util.logging by default?
Assuming end users can configure (slf4j) whatever they want. Perhaps we
could even ship "samples" for the various options if there is interest...

Regards,

Patrick


> On Fri, Jan 7, 2022 at 9:57 AM Patrick Hunt  wrote:
>
> > ...
> >
> > I also see that there is interest (upstream/apache I mean) in
> > resurrecting log4j1 - imo that could also be a good path for us.
> >
> >
> >
>

Re: Logback

[Patrick Hunt]

Thanks Chris, et. al. I have been monitoring this thread already, but I
appreciate you following up. :-)

I checked out the log4j2 source repo as part of my remediation efforts
inside my employer. tbh I was/am shocked at the amount of code and esp the
number of dependencies, for something that should be as simple as a logging
library. Hence my concern and why I commented on ZOOKEEPER-2342 recently -
I still have the same goal as that comment - that we review our use of
logging infra and make sure log4j2 is a good fit rather than moving to
something else. Given our close ties with the Hadoop community I think it
also makes sense to look at what they are doing before making any changes.
We have many "customers" - as such backward compatibility should be a
requirement.

I also see that there is interest (upstream/apache I mean) in
resurrecting log4j1 - imo that could also be a good path for us.

EOD I reflect what Enrico mentioned (and he covered well, hence you didn't
see me respond, "me too" it) - appreciate all the work on this - which is
already including thoughts/discussion on where to go, iow the heart of my
comment.

Regards,

Patrick

On Fri, Jan 7, 2022 at 9:35 AM Chris Nauroth  wrote:

> I just noticed that Patrick commented on ZOOKEEPER-2342 expressing doubt
> about sticking with Log4J, so I want to make sure his perspective gets
> included in our thread here. Specifically added him to the To: line.
>
> Chris Nauroth
>
>
> On Thu, Jan 6, 2022 at 11:16 PM Enrico Olivelli 
> wrote:
>
>> I believe that Chris points are valid.
>>
>> My understanding, especially after seeing Andor's patch is that we are
>> depending on an implementation in two cases:
>> - in some tests (we grab the logs)
>> - for the binary tarbal (for real users if the server)
>>
>> If we could rely on slf4j-simple for the tests (or write a little mock
>> binding) then switching will be only a matter of changing the slf4j
>> implementation and deal with the configuration files.
>>
>> I appreciate a lot Andor's work, and the fact that we are finally
>> addressing this long standing issue.
>>
>> Andor,
>> What do you think about moving to log4j2?
>>
>> Personally I don't have much time next week to help, so I am +1 to commit
>> Andor's patch and get rid of log4j1.
>>
>> Enrico
>>
>> Il Gio 6 Gen 2022, 20:38 Chris Nauroth  ha scritto:
>>
>> > Happy New Year, and thank you for driving this, Andor!
>> >
>> > I am somewhat hesitant about switching direction to Logback:
>> > - First, I agree with points already raised by Christopher.
>> > - A major reason that my prior work to migrate to Log4J 2 in
>> ZOOKEEPER-2342
>> > stalled out years ago is backward-incompatibility of the logging
>> > configuration files. However, I've just learned that Log4J 2 has added
>> > support for compatibility with Log4J 1 style configuration files, so it
>> > appears this blocker is now resolved. [1] (I have yet to test the
>> > compatibility feature myself.)
>> > - I don't think Logback supports compatibility with Log4J style
>> > configuration. (Please correct me if I'm wrong.) If we previously
>> > considered it important to preserve compatibility of configuration for
>> > system administrators, then it seems we are abandoning that goal now.
>> > Perhaps the escape hatch of swapping out the SLF4J provider during
>> > deployment is sufficient to address this.
>> > - It has taken a long time, but it appears that the wider big data
>> > ecosystem is coming around to Log4J 2. Discussion has renewed in Hadoop.
>> > Recent HBase releases use Log4J 2. Spark recently committed a Log4J 2
>> > migration patch for inclusion in a future release. While integration
>> with
>> > the big data ecosystem isn't the sole use case for Zookeeper, it's
>> > definitely a major one, and I think it's beneficial for big data
>> > deployments to have commonality in the logging infrastructure.
>> > - Logback is dual-licensed under LGPL and EPL. [2] LGPL is a category X
>> > license that would prevent shipping in Apache releases. [3] EPL is a
>> > category B license considered acceptable for inclusion. [4] I've
>> personally
>> > not dealt with a dual-licensing situation like this before, but my
>> > intuition is that we need careful handling in NOTICES.txt to indicate
>> that
>> > we choose to adopt the terms of EPL, not LGPL.
>> >
>> > I don't mean to impede progress, and I don't intend to -1 a Logback
>> patch
>> > if that's the overall community preference. I've already started code
>> > reviewing ZOOKEEPER-4427. I would only ask that we also provide clear
>> > documentation for administrators who want to swap to the Log4J 2
>> provider
>> > for compatibility with their existing configuration.
>> >
>> > Thank you again, Andor. The ZOOKEEPER-4427 patch is looking good so far!
>> >
>> > [1] https://logging.apache.org/log4j/2.x/manual/migration.html
>> > [2] https://github.com/qos-ch/logback/blob/master/LICENSE.txt
>> > [3] https://www.apache.org/legal/resolved.html#category-x
>> > [4] 

Re: ZooKeeper downloads and the new Apache CDN.

[Patrick Hunt]

On Thu, Oct 14, 2021 at 3:03 PM Enrico Olivelli  wrote:

> Patrick,
>
> Il Gio 14 Ott 2021, 21:36 Patrick Hunt  ha scritto:
>
> > I just noticed this Apache post:
> >
> >
> https://blogs.apache.org/foundation/entry/apache-software-foundation-moves-to
> > I haven't been tracking such infra changes of late.
> >
> > However I do notice that our download page is impacted:
> > https://zookeeper.apache.org/releases.html#download
> > clicking on a release binary/source download now takes you to a CDN
> > informational page, rather than downloading the actual archive. Not sure
> > what the original behaviour was, but is this what we want? I'm also not
> > sure what has happened with folks who tried to automate d/l as part of eg
> > ci/cd...
> >
>
> I am not aware of problems currently.
>
> The download page looks compliant with current rules/styles in the ASF.
> I am telling this because at any release we are scanned for proper download
> links and we recently fixed the download page.
>
>
Thanks Enrico, this is what you're referring to?
https://issues.apache.org/jira/browse/ZOOKEEPER-4265
It does look like we're in good shape then!

Patrick


> That said, if there is a better way of doing the redirection then let's do
> it
>
> Best regards
> Enrico
>
>
>
> > I see that httpd just has direct links:
> > https://httpd.apache.org/download.cgi#apache24
> >
> > Has anyone been following this and knows what we should do? :-) If not -
> > thoughts?
> >
> > Regards,
> >
> > Patrick
> >
>

ZooKeeper downloads and the new Apache CDN.

[Patrick Hunt]

I just noticed this Apache post:
https://blogs.apache.org/foundation/entry/apache-software-foundation-moves-to
I haven't been tracking such infra changes of late.

However I do notice that our download page is impacted:
https://zookeeper.apache.org/releases.html#download
clicking on a release binary/source download now takes you to a CDN
informational page, rather than downloading the actual archive. Not sure
what the original behaviour was, but is this what we want? I'm also not
sure what has happened with folks who tried to automate d/l as part of eg
ci/cd...

I see that httpd just has direct links:
https://httpd.apache.org/download.cgi#apache24

Has anyone been following this and knows what we should do? :-) If not -
thoughts?

Regards,

Patrick

Re: FYI: Snyk JVM Ecosystem Report 2021

[Patrick Hunt]

If you download the "detailed" pdf report it shows that 15 is on the uptake
already...

Patrick

On Fri, Jun 25, 2021 at 8:19 AM Christopher  wrote:

> The report says that over 60% of developers use Java 11 in
> *production*. That's higher than I would have expected. I figured most
> production users were still running 8. Nevertheless, if that many are
> using 11 in production, I can imagine the number of developers
> planning for 11 or higher in their *next* releases would be much
> higher. I think this gives real credibility to the idea that current
> main/master/next/develop branches for Java projects should probably be
> focusing on 11 or higher.
>
> On Thu, Jun 24, 2021 at 9:35 PM Patrick Hunt  wrote:
> >
> > Questions come up every so often on what jvm versions we should
> > support/test/etc... Granted this is larger than our community but I think
> > it provides some useful insight:
> > https://snyk.io/jvm-ecosystem-report-2021/
> >
> > Regards,
> >
> > Patrick
>

FYI: Snyk JVM Ecosystem Report 2021

[Patrick Hunt]

Questions come up every so often on what jvm versions we should
support/test/etc... Granted this is larger than our community but I think
it provides some useful insight:
https://snyk.io/jvm-ecosystem-report-2021/

Regards,

Patrick

Re: [VOTE] Apache ZooKeeper release 3.6.3 candidate 2

[Patrick Hunt]

+1 xsum/sig validate. rat ran clean. I ran dependency check and
launched/tested a few different cluster sizes manually and they all ran
fine.

Patrick

On Thu, Apr 8, 2021 at 10:19 AM Mohammad Arshad  wrote:

> This is a bug fix release candidate for 3.6.3. It fixes 52 issues,
> including multiple CVE fixes.
>
> The full release notes is available at:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310801=12348703
>
>  Please download, test and vote by Sunday, April 11th 2021, 23:59
> UTC+0. 
>
> Source and binary files:
> https://people.apache.org/~arshad/zookeeper-3.6.3-candidate-2/
>
> Maven staging repo:
> https://repository.apache.org/content/repositories/orgapachezookeeper-1071
>
> The release candidate tag in git to be voted upon: release-3.6.3-2
> https://github.com/apache/zookeeper/tree/release-3.6.3-2
>
> ZooKeeper's KEYS file containing PGP keys we use to sign the release:
> https://www.apache.org/dist/zookeeper/KEYS
>
> The staging version of the website is:
> https://people.apache.org/~arshad/zookeeper-3.6.3-candidate-2/website/
>
> Should we release this candidate?
>
> Thanks & Regards
> Arshad
>

Re: [VOTE] Apache ZooKeeper release 3.6.3 candidate 0

[Patrick Hunt]

+1 xsum/sig validate. rat ran clean. I manually tested a few cluster sizes
and everything worked fine for me (jdk11).

Regards,

Patrick

On Thu, Apr 1, 2021 at 6:31 AM Mohammad Arshad  wrote:

> This is a bug fix release candidate for 3.6.3. It contains 51 fixes.
>
> The full release notes is available at:
>
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310801=12348703
>
> *** Please download, test and vote by Tuesday, April 6th 2021, 23:59 UTC+0.
> ***
>
> Source and binary files:
> https://people.apache.org/~arshad/zookeeper-3.6.3-candidate-0/
>
> Maven staging repo:
> https://repository.apache.org/content/repositories/orgapachezookeeper-1068/
>
> The release candidate tag in git to be voted upon: release-3.6.3-0
> https://github.com/apache/zookeeper/tree/release-3.6.3-0
>
> ZooKeeper's KEYS file containing PGP keys we use to sign the release:
> https://www.apache.org/dist/zookeeper/KEYS
>
> The staging version of the website is:
> https://people.apache.org/~arshad/zookeeper-3.6.3-candidate-0/website/
>
> Should we release this candidate?
>
> Thanks & Regards
> Arshad
>

Re: [VOTE] Apache ZooKeeper release 3.7.0 candidate 2

[Patrick Hunt]

+1 xsum/sig validate. rat ran clean and I was able to compile (dep/cve
check passed) and manual verification of a few different cluster sizes was
successful.

Regards,

Patrick


On Wed, Mar 17, 2021 at 4:06 AM Damien Diederen 
wrote:

>
> Greetings, all!
>
> After a long delay, here is a third release candidate for ZooKeeper 3.7.0.
>
> Compared to RC1, it contains... quite a few changes.  It notably fixes
> the quota feature for multi transactions, repairs the test suite on
> macOS (Catalina), makes a few tests less flaky, and avoids a CVE.
>
> The complete set of changes can be obtained with the Git range
> expression 'release-3.7.0-1..release-3.7.0-2', or on GitHub at:
>
>
> https://github.com/apache/zookeeper/compare/release-3.7.0-1...release-3.7.0-2
>
> I cannot say that I find the state of the test suite satisfactory, but
> the failures which are often observed are due to timing and/or TCP/IP
> port assignment issues, and repeated runs are "sufficient" to clear
> them.
>
> I was hoping to contribute more on that front, but have been unable so
> far, and don't want to keep the 3.7 branch hostage—so here is a timid
> RC2.
>
>
> ZooKeeper 3.7.0 introduces a number of new features, notably:
>
>   * An API to start a ZooKeeper server from Java (ZOOKEEPER-3874);
>
>   * Quota enforcement (ZOOKEEPER-3301);
>
>   * Host name canonicalization in quorum SASL authentication
> (ZOOKEEPER-4030);
>
>   * Support for BCFKS key/trust store format (ZOOKEEPER-3950);
>
>   * A choice of mandatory authentication scheme(s) (ZOOKEEPER-3561);
>
>   * A "whoami" API and CLI command (ZOOKEEPER-3969);
>
>   * The possibility of disabling digest authentication (ZOOKEEPER-3979);
>
>   * Multiple SASL "superUsers" (ZOOKEEPER-3959);
>
>   * Fast-tracking of throttled requests (ZOOKEEPER-3683);
>
>   * Additional security metrics (ZOOKEEPER-3978);
>
>   * SASL support in the C and Perl clients (ZOOKEEPER-1112,
> ZOOKEEPER-3714);
>
>   * A new zkSnapshotComparer.sh tool (ZOOKEEPER-3427);
>
>   * Notes on how to benchmark ZooKeeper with the YCSB tool
> (ZOOKEEPER-3264).
>
>
> The release notes are available here:
>
>
> https://people.apache.org/~ddiederen/zookeeper-3.7.0-candidate-2/website/releasenotes.html
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310801=12346617
>
> *** Please download, test and vote by March 21st 2021, 23:59 UTC+0. ***
>
> Source files:
>
>   https://people.apache.org/~ddiederen/zookeeper-3.7.0-candidate-2/
>
> Maven staging repo:
>
>
> https://repository.apache.org/content/repositories/orgapachezookeeper-1067/
>
> The release candidate tag in git to be voted upon: release-3.7.0-2
>
>   https://github.com/apache/zookeeper/tree/release-3.7.0-2
>
> ZooKeeper's KEYS file containing PGP keys we use to sign the release:
>
>   https://www.apache.org/dist/zookeeper/KEYS
>
> The staging version of the website is:
>
>
> https://people.apache.org/~ddiederen/zookeeper-3.7.0-candidate-2/website/
>
>
> Should we release this candidate?
>
>
> Damien Diederen
>

Re: write performance issue in 3.6.2

[Patrick Hunt]

On Sun, Feb 21, 2021 at 3:28 PM Li Wang  wrote:

> Hi Enrico, Sushant,
>
> I re-run the perf test with the data consistency check feature disabled
> (i.e. -Dzookeeper.digest.enabled=false), the write performance issue of 3.6
> is still there.
>
> With everything exactly the same, the throughput of 3.6 was only 1/2 of 3.4
> and the max latency was more than 8 times.
>
> Any other points or thoughts?
>
>
In the past I've noticed a big impact of GC when doing certain performance
measurements. I assume you are using the same JVM version and GC when
running the two tests? Perhaps our memory footprint has expanded over time.
You should rule out GC by running with gc logging turned on with both
versions and compare the impact.

Regards,

Patrick


> Cheers,
>
> Li
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Sat, Feb 20, 2021 at 9:04 PM Li Wang  wrote:
>
> > Thanks Sushant and Enrico!
> >
> > This is a really good point.  According to the 3.6 documentation, the
> > feature is disabled by default.
> >
> https://zookeeper.apache.org/doc/r3.6.2/zookeeperAdmin.html#ch_administration
> .
> > However, checking the code, the default is enabled.
> >
> > Let me set the zookeeper.digest.enabled to false and see how the write
> > operation performs.
> >
> > Best,
> >
> > Li
> >
> >
> >
> >
> > On Fri, Feb 19, 2021 at 1:32 PM Sushant Mane 
> > wrote:
> >
> >> Hi Li,
> >>
> >> On 3.6.2 consistency checker (adhash based) is enabled by default:
> >>
> >>
> https://github.com/apache/zookeeper/blob/803c7f1a12f85978cb049af5e4ef23bd8b688715/zookeeper-server/src/main/java/org/apache/zookeeper/server/ZooKeeperServer.java#L136
> >> .
> >> It is not present in ZK 3.4.14.
> >>
> >> This feature does have some impact on write performance.
> >>
> >> Thanks,
> >> Sushant
> >>
> >>
> >> On Fri, Feb 19, 2021 at 12:50 PM Enrico Olivelli 
> >> wrote:
> >>
> >> > Li,
> >> > I wonder of we have some new throttling/back pressure mechanisms that
> is
> >> > enabled by default.
> >> >
> >> > Does anyone has some pointer to relevant implementations?
> >> >
> >> >
> >> > Enrico
> >> >
> >> > Il Ven 19 Feb 2021, 19:46 Li Wang  ha scritto:
> >> >
> >> > > Hi,
> >> > >
> >> > > We switched to Netty on both client side and server side and the
> >> > > performance issue is still there.  Anyone has any insights on what
> >> could
> >> > be
> >> > > the cause of higher latency?
> >> > >
> >> > > Thanks,
> >> > >
> >> > > Li
> >> > >
> >> > >
> >> > >
> >> > > On Mon, Feb 15, 2021 at 2:17 PM Li Wang  wrote:
> >> > >
> >> > > > Hi Enrico,
> >> > > >
> >> > > >
> >> > > > Thanks for the reply.
> >> > > >
> >> > > >
> >> > > > 1. We are using NIO based stack, not Netty based yet.
> >> > > >
> >> > > > 2. Yes, here are some metrics on the client side.
> >> > > >
> >> > > >
> >> > > > 3.6: throughput: 7K, failure: 81215228, Avg Latency: 57ms,  Max
> >> Latency
> >> > > 31s
> >> > > >
> >> > > > 3.4: throughput: 15k, failure: 0,  Avg Latency: 30ms,  Max
> Latency:
> >> > 1.6s
> >> > > >
> >> > > >
> >> > > > 3. Yes, the JVM and zoo.cfg config are the exact same
> >> > > >
> >> > > > 10G of Heap
> >> > > >
> >> > > > 13G of Memory
> >> > > >
> >> > > > 5 Participante
> >> > > >
> >> > > > 5 Observere
> >> > > >
> >> > > > Client session timeout: 3000ms
> >> > > >
> >> > > > Server min session time: 4000ms
> >> > > >
> >> > > >
> >> > > >
> >> > > > 4. Yes, there are two types of  WARN logs and many “Expiring
> >> session”
> >> > > > INFO log
> >> > > >
> >> > > >
> >> > > > 2021-02-15 22:04:36,506 [myid:4] - WARN
> >> > > > [NIOWorkerThread-7:NIOServerCnxn@365] - Unexpected exception
> >> > > >
> >> > > > EndOfStreamException: Unable to read additional data from client,
> it
> >> > > > probably closed the socket: address = /100.108.63.116:43366,
> >> session =
> >> > > > 0x400189fee9a000b
> >> > > >
> >> > > > at
> >> > > >
> >> > >
> >> >
> >>
> org.apache.zookeeper.server.NIOServerCnxn.handleFailedRead(NIOServerCnxn.java:164)
> >> > > >
> >> > > > at
> >> > org.apache.zookeeper.server.NIOServerCnxn.doIO(NIOServerCnxn.java:327)
> >> > > >
> >> > > > at
> >> > > >
> >> > >
> >> >
> >>
> org.apache.zookeeper.server.NIOServerCnxnFactory$IOWorkRequest.doWork(NIOServerCnxnFactory.java:522)
> >> > > >
> >> > > > at
> >> > > >
> >> > >
> >> >
> >>
> org.apache.zookeeper.server.WorkerService$ScheduledWorkRequest.run(WorkerService.java:154)
> >> > > >
> >> > > > at
> >> > > >
> >> > >
> >> >
> >>
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> >> > > >
> >> > > > at
> >> > > >
> >> > >
> >> >
> >>
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> >> > > >
> >> > > > at java.base/java.lang.Thread.run(Thread.java:834)
> >> > > >
> >> > > >
> >> > > > 2021-02-15 22:05:14,428 [myid:4] - WARN
> >> > > > [SyncThread:4:SyncRequestProcessor@188] - Too busy to snap,
> >> skipping
> >> > > >
> >> > > >
> >> > > > 2021-02-15 22:01:51,427 [myid:4] - INFO
> >> > > > [SessionTracker:ZooKeeperServer@610] - 

Re: [VOTE] Apache ZooKeeper release 3.7.0 candidate 1

[Patrick Hunt]

+1. xsum/sig verified. rat ran clean. built and dependency checks are fine.
Tried running some manual clusters and it was successful.

Regards,

Patrick


On Sun, Jan 24, 2021 at 12:11 PM Damien Diederen 
wrote:

>
> Dear all,
>
> This is a second release candidate for ZooKeeper 3.7.0.  Compared to
> RC0, it fixes a tarball generation issue, includes a description of the
> 'whoami' CLI command, and incorporates a contribution to ZooInspector.
>
> ZooKeeper 3.7.0 introduces a number of new features, notably:
>
>   * An API to start a ZooKeeper server from Java (ZOOKEEPER-3874);
>
>   * Quota enforcement (ZOOKEEPER-3301);
>
>   * Host name canonicalization in quorum SASL authentication
> (ZOOKEEPER-4030);
>
>   * Support for BCFKS key/trust store format (ZOOKEEPER-3950);
>
>   * A choice of mandatory authentication scheme(s) (ZOOKEEPER-3561);
>
>   * A "whoami" API and CLI command (ZOOKEEPER-3969);
>
>   * The possibility of disabling digest authentication (ZOOKEEPER-3979);
>
>   * Multiple SASL "superUsers" (ZOOKEEPER-3959);
>
>   * Fast-tracking of throttled requests (ZOOKEEPER-3683);
>
>   * Additional security metrics (ZOOKEEPER-3978);
>
>   * SASL support in the C and Perl clients (ZOOKEEPER-1112,
> ZOOKEEPER-3714);
>
>   * A new zkSnapshotComparer.sh tool (ZOOKEEPER-3427);
>
>   * Notes on how to benchmark ZooKeeper with the YCSB tool
> (ZOOKEEPER-3264).
>
> The release notes are available here:
>
>
> https://people.apache.org/~ddiederen/zookeeper-3.7.0-candidate-1/website/releasenotes.html
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310801=12346617
>
> *** Please download, test and vote by January 31st 2020, 23:59 UTC+0. ***
>
> Source files:
>
>   https://people.apache.org/~ddiederen/zookeeper-3.7.0-candidate-1/
>
> Maven staging repo:
>
>
> https://repository.apache.org/content/repositories/orgapachezookeeper-1066/
>
> The release candidate tag in git to be voted upon: release-3.7.0-1
>
>   https://github.com/apache/zookeeper/tree/release-3.7.0-1
>
> ZooKeeper's KEYS file containing PGP keys we use to sign the release:
>
>   https://www.apache.org/dist/zookeeper/KEYS
>
> The staging version of the website is:
>
>
> https://people.apache.org/~ddiederen/zookeeper-3.7.0-candidate-1/website/
>
> Should we release this candidate?
>
> Damien Diederen
>

Re: Re: [VOTE] Apache ZooKeeper release 3.7.0 candidate 0

[Patrick Hunt]

On Fri, Jan 22, 2021 at 6:55 PM Justin Ling Mao 
wrote:

> I create the ticket: ZOOKEEPER-4188: add a doc about whoami CLI for me to
> do. It's not a blocker. Let's go ahead:)
>
>
Thanks Justin. Note that a release can't be vetoed (also I did give
a +1) and as the RM Damien should make the final decision on the
seriousness of any issues found. Perhaps a good opportunity to review the
apache release voting guidelines:
https://www.apache.org/foundation/voting.html#ReleaseVotes
http://www.apache.org/legal/release-policy.html#release-approval

Regards,

Patrick


> - Original Message -
> From: Patrick Hunt 
> To: DevZooKeeper 
> Subject: Re: [VOTE] Apache ZooKeeper release 3.7.0 candidate 0
> Date: 2021-01-23 05:09
>
> +1 - xsum/sig validated. Compiles/runs fine on macos+jdk11. Verified some
> larger ensemble sizes manually and it worked ok.
> I looked at a few of the new features listed - they look great! I did
> notice some changes without documentation though (whoami eg), would be good
> for committers to ensure that docs get updated along the way...
> Thanks Damien for acting as RM. Regards,
> Patrick
> On Tue, Jan 19, 2021 at 4:40 AM Damien Diederen 
> wrote:
> >
> > Dear all,
> >
> > This is a first release candidate for ZooKeeper 3.7.0.
> >
> > It introduces a number of new features, notably:
> >
> >   * An API to start a ZooKeeper server from Java (ZOOKEEPER-3874);
> >
> >   * Quota enforcement (ZOOKEEPER-3301);
> >
> >   * Host name canonicalization in quorum SASL authentication
> > (ZOOKEEPER-4030);
> >
> >   * Support for BCFKS key/trust store format (ZOOKEEPER-3950);
> >
> >   * A choice of mandatory authentication scheme(s) (ZOOKEEPER-3561);
> >
> >   * A "whoami" API and CLI command (ZOOKEEPER-3969);
> >
> >   * The possibility of disabling digest authentication (ZOOKEEPER-3979);
> >
> >   * Multiple SASL "superUsers" (ZOOKEEPER-3959);
> >
> >   * Fast-tracking of throttled requests (ZOOKEEPER-3683);
> >
> >   * Additional security metrics (ZOOKEEPER-3978);
> >
> >   * SASL support in the C and Perl clients (ZOOKEEPER-1112,
> > ZOOKEEPER-3714);
> >
> >   * A new zkSnapshotComparer.sh tool (ZOOKEEPER-3427);
> >
> >   * Notes on how to benchmark ZooKeeper with the YCSB tool
> > (ZOOKEEPER-3264).
> >
> > The release notes are available here:
> >
> >
> >
> https://people.apache.org/~ddiederen/zookeeper-3.7.0-candidate-0/website/releasenotes.html
> >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310801=12346617
> >
> > *** Please download, test and vote by January 24th 2020, 23:59 UTC+0. ***
> >
> > Source files:
> >
> >   https://people.apache.org/~ddiederen/zookeeper-3.7.0-candidate-0/
> >
> > Maven staging repo:
> >
> >
> >
> https://repository.apache.org/content/repositories/orgapachezookeeper-1065/
> >
> > The release candidate tag in git to be voted upon: release-3.7.0-0
> >
> >   https://github.com/apache/zookeeper/tree/release-3.7.0-0
> >
> > ZooKeeper's KEYS file containing PGP keys we use to sign the release:
> >
> >   https://www.apache.org/dist/zookeeper/KEYS
> >
> > The staging version of the website is:
> >
> >
> >
> https://people.apache.org/~ddiederen/zookeeper-3.7.0-candidate-0/website/
> >
> > Should we release this candidate?
> >
> > Damien Diederen
> >
> >
>

Re: [VOTE] Apache ZooKeeper release 3.7.0 candidate 0

[Patrick Hunt]

+1 - xsum/sig validated. Compiles/runs fine on macos+jdk11. Verified some
larger ensemble sizes manually and it worked ok.

I looked at a few of the new features listed - they look great! I did
notice some changes without documentation though (whoami eg), would be good
for committers to ensure that docs get updated along the way...

Thanks Damien for acting as RM. Regards,

Patrick

On Tue, Jan 19, 2021 at 4:40 AM Damien Diederen 
wrote:

>
> Dear all,
>
> This is a first release candidate for ZooKeeper 3.7.0.
>
> It introduces a number of new features, notably:
>
>   * An API to start a ZooKeeper server from Java (ZOOKEEPER-3874);
>
>   * Quota enforcement (ZOOKEEPER-3301);
>
>   * Host name canonicalization in quorum SASL authentication
> (ZOOKEEPER-4030);
>
>   * Support for BCFKS key/trust store format (ZOOKEEPER-3950);
>
>   * A choice of mandatory authentication scheme(s) (ZOOKEEPER-3561);
>
>   * A "whoami" API and CLI command (ZOOKEEPER-3969);
>
>   * The possibility of disabling digest authentication (ZOOKEEPER-3979);
>
>   * Multiple SASL "superUsers" (ZOOKEEPER-3959);
>
>   * Fast-tracking of throttled requests (ZOOKEEPER-3683);
>
>   * Additional security metrics (ZOOKEEPER-3978);
>
>   * SASL support in the C and Perl clients (ZOOKEEPER-1112,
> ZOOKEEPER-3714);
>
>   * A new zkSnapshotComparer.sh tool (ZOOKEEPER-3427);
>
>   * Notes on how to benchmark ZooKeeper with the YCSB tool
> (ZOOKEEPER-3264).
>
> The release notes are available here:
>
>
> https://people.apache.org/~ddiederen/zookeeper-3.7.0-candidate-0/website/releasenotes.html
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310801=12346617
>
> *** Please download, test and vote by January 24th 2020, 23:59 UTC+0. ***
>
> Source files:
>
>   https://people.apache.org/~ddiederen/zookeeper-3.7.0-candidate-0/
>
> Maven staging repo:
>
>
> https://repository.apache.org/content/repositories/orgapachezookeeper-1065/
>
> The release candidate tag in git to be voted upon: release-3.7.0-0
>
>   https://github.com/apache/zookeeper/tree/release-3.7.0-0
>
> ZooKeeper's KEYS file containing PGP keys we use to sign the release:
>
>   https://www.apache.org/dist/zookeeper/KEYS
>
> The staging version of the website is:
>
>
> https://people.apache.org/~ddiederen/zookeeper-3.7.0-candidate-0/website/
>
> Should we release this candidate?
>
> Damien Diederen
>
>

Re: ZooKeeper Operator

[Patrick Hunt]

Hm. We occasionally get security reports for things like docker containers
(which we don't directly control). Perhaps we can club the two together, we
should be clear that these are refs and unsupported/unmaintained by Apache
and the PMC.

Patrick

On Mon, Jan 18, 2021 at 10:20 AM Flavio Junqueira  wrote:

> It sounds like a good idea to document it and add relevant pointers, Pat.
>
> -Flavio
>
> > On 18 Jan 2021, at 19:00, Patrick Hunt  wrote:
> >
> > FYI: The awesome operator list has a few including Pravega:
> > https://github.com/operator-framework/awesome-operators
> >
> > I've seen a few more while investigating kubebuilder, operator-sdk (rh)
> and
> > the like:
> > https://github.com/Ghostbaby/zookeeper-operator
> >
> > Perhaps the first thing we might consider is adding a wiki page detailing
> > the available options and insights from the community? Esp if folks are
> > using them. Similar to the client and tools pages:
> > https://cwiki.apache.org/confluence/display/ZOOKEEPER/ZKClientBindings
> > https://cwiki.apache.org/confluence/display/ZOOKEEPER/UsefulTools
> >
> > Patrick
> >
> > On Mon, Jan 18, 2021 at 2:36 AM Enrico Olivelli 
> wrote:
> >
> >> Thanks for sharing!
> >>
> >> We need more support for K8s in the OS community, this is a good step
> >>
> >> Enrico
> >>
> >> Il giorno lun 18 gen 2021 alle ore 11:18 Flavio Junqueira <
> f...@apache.org>
> >> ha scritto:
> >>
> >>> We've been getting questions and sometimes contributions to the
> ZooKeeper
> >>> Kubernetes Operator we originally did for Pravega, so I feel that it
> has
> >>> been useful more broadly. Perhaps this is something that others might
> be
> >>> interested in too, and I thought of mentioning here.
> >>>
> >>> https://github.com/pravega/zookeeper-operator
> >>>
> >>> Thanks,
> >>> -Flavio
> >>
>
>

Re: ZooKeeper Operator

[Patrick Hunt]

FYI: The awesome operator list has a few including Pravega:
https://github.com/operator-framework/awesome-operators

I've seen a few more while investigating kubebuilder, operator-sdk (rh) and
the like:
https://github.com/Ghostbaby/zookeeper-operator

Perhaps the first thing we might consider is adding a wiki page detailing
the available options and insights from the community? Esp if folks are
using them. Similar to the client and tools pages:
https://cwiki.apache.org/confluence/display/ZOOKEEPER/ZKClientBindings
https://cwiki.apache.org/confluence/display/ZOOKEEPER/UsefulTools

Patrick

On Mon, Jan 18, 2021 at 2:36 AM Enrico Olivelli  wrote:

> Thanks for sharing!
>
> We need more support for K8s in the OS community, this is a good step
>
> Enrico
>
> Il giorno lun 18 gen 2021 alle ore 11:18 Flavio Junqueira 
> ha scritto:
>
> > We've been getting questions and sometimes contributions to the ZooKeeper
> > Kubernetes Operator we originally did for Pravega, so I feel that it has
> > been useful more broadly. Perhaps this is something that others might be
> > interested in too, and I thought of mentioning here.
> >
> > https://github.com/pravega/zookeeper-operator
> >
> > Thanks,
> > -Flavio
>

Re: New committer: Justin Mao Ling

[Patrick Hunt]

Kudos Justin!

Patrick

On Mon, Jan 18, 2021 at 4:10 AM Szalay-Bekő Máté 
wrote:

> Congratulations Maoling!!! :))
>
> Regards,
> Mate
>
> On Mon, Jan 18, 2021 at 11:48 AM Norbert Kalmar
>  wrote:
>
> > Congratulations Maoling! Well-deserved!
> >
> > - Norbert
> >
> > On Mon, Jan 18, 2021 at 11:43 AM Andor Molnar  wrote:
> >
> > > Congrats Maoling!
> > >
> > >
> > >
> > >
> > > > On 2021. Jan 18., at 11:09, Enrico Olivelli 
> > wrote:
> > > >
> > > > The Project Management Committee (PMC) for Apache ZooKeeper
> > > >
> > > > has invited Justin Mao Long to become a committer and we are pleased
> > > >
> > > > to announce that he has accepted.
> > > >
> > > >
> > > > Justin has been following the Project for a long time,
> > > >
> > > > He is very active in the community with discussions and code reviews
> > > > and he contributed
> > > > many patches.
> > > >
> > > >
> > > > Being a committer enables easier contribution to the
> > > >
> > > > project since there is no need to go via the patch
> > > >
> > > > submission process. This should enable better productivity.
> > > >
> > > > Being a PMC member enables assistance with the management
> > > >
> > > > and to guide the direction of the project.
> > > >
> > > >
> > > >
> > > > Congratulations Justin !
> > > >
> > > >
> > > > Enrico
> > >
> > >
> >
>

Re: JIRA spammer

[Patrick Hunt]

I deleted them. Thanks Christopher.

Regards,

Patrick

On Sat, Jan 16, 2021 at 11:02 AM Christopher  wrote:

> Hi ZK Devs,
>
> I saw that a spammer had created a bunch of JIRA issues, between
> https://issues.apache.org/jira/browse/ZOOKEEPER-4059 and
> https://issues.apache.org/jira/browse/ZOOKEEPER-4073
>
> I notified INFRA on Slack, and @fluxo (Chris Lambertus) deactivated the
> user. However, a PMC member will probably need to actually close and/or
> delete the issues, since I do not have access. Alternatively, you can ask
> INFRA to delete them for you.
>
> Thanks,
> Christopher
>

Re: [VOTE] Apache ZooKeeper release 3.5.9 candidate 2

[Patrick Hunt]

+1. verified sig/xsum. rat ran clean. compiled and ran a few manual tests
successfully.

Patrick

On Wed, Jan 6, 2021 at 12:10 PM Norbert Kalmar  wrote:

> This is a bugfix release candidate for 3.5.9. It contains 25 fixes,
> including CVE fixes.
> (Note: rc1 had a third party CVE which was only noticed during the last
> check of the release, so it never made it for vote)
>
> The full release notes is available at:
>
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310801=12348201
>
> *** Please download, test and vote by January 11th 2020, 23:59 UTC+0. ***
>
> Source files:
> https://people.apache.org/~nkalmar/zookeeper-3.5.9-candidate-2/
>
> Maven staging repo:
>
> https://repository.apache.org/content/groups/staging/org/apache/zookeeper/zookeeper/3.5.9/
>
> The release candidate tag in git to be voted upon: release-3.5.9-rc2
>
> ZooKeeper's KEYS file containing PGP keys we use to sign the release:
> https://www.apache.org/dist/zookeeper/KEYS
>
> Should we release this candidate?
>
> - Norbert
>

Re: [VOTE] Apache ZooKeeper release 3.5.9 candidate 0

[Patrick Hunt]

Thanks Damien! I reviewed and it looks good except for one small comment I
hope we can also address (commented on PR).

Regards,

Patrick

On Sat, Dec 5, 2020 at 12:05 PM Damien Diederen 
wrote:

>
> Hi Patrick, all,
>
> > -1 - the dependency check is failing with a known CVE
> >
> > $ mvn clean package -DskipTests dependency-check:check
> > ...
> > [ERROR] One or more dependencies were identified with vulnerabilities
> that
> > have a CVSS score greater than or equal to '0.0':
> > [ERROR]
> > [ERROR] jetty-server-9.4.34.v20201102.jar: CVE-2020-27218
> > [ERROR] jetty-http-9.4.34.v20201102.jar: CVE-2020-27218
>
> For the (mailing list) record, I have created:
>
> https://issues.apache.org/jira/browse/ZOOKEEPER-4023
> https://github.com/apache/zookeeper/pull/1552
>
> Best, -D
>

Re: [VOTE] Apache ZooKeeper release 3.5.9 candidate 0

[Patrick Hunt]

More minor: I notice that
./zookeeper-server/src/main/resources/lib/jetty-client-9.4.34.v20201102.LICENSE.txt
is included in the release even though the jar is no longer used. It should
be removed.

Regards,

Patrick


On Fri, Dec 4, 2020 at 1:53 PM Patrick Hunt  wrote:

> -1 - the dependency check is failing with a known CVE
>
> $ mvn clean package -DskipTests dependency-check:check
> ...
> [ERROR] One or more dependencies were identified with vulnerabilities that
> have a CVSS score greater than or equal to '0.0':
> [ERROR]
> [ERROR] jetty-server-9.4.34.v20201102.jar: CVE-2020-27218
> [ERROR] jetty-http-9.4.34.v20201102.jar: CVE-2020-27218
> [ERROR]
>
> Patrick
>
>
> On Tue, Dec 1, 2020 at 8:58 AM Norbert Kalmar  wrote:
>
>> This is a bugfix release candidate for 3.5.9. It contains 24 fixes,
>> including 2 CVE fix.
>>
>> The full release notes is available at:
>>
>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310801=12348201
>>
>> *** Please download, test and vote by December 4th 2020, 23:59 UTC+0. ***
>>
>> Source files:
>> https://people.apache.org/~nkalmar/zookeeper-3.5.9-candidate-0/
>>
>> Maven staging repo:
>>
>> https://repository.apache.org/content/groups/staging/org/apache/zookeeper/zookeeper/3.5.9/
>>
>> The release candidate tag in git to be voted upon: release-3.5.9-rc0
>>
>> ZooKeeper's KEYS file containing PGP keys we use to sign the release:
>> https://www.apache.org/dist/zookeeper/KEYS
>>
>> Should we release this candidate?
>>
>> - Norbert
>>
>

Re: [VOTE] Apache ZooKeeper release 3.5.9 candidate 0

[Patrick Hunt]

-1 - the dependency check is failing with a known CVE

$ mvn clean package -DskipTests dependency-check:check
...
[ERROR] One or more dependencies were identified with vulnerabilities that
have a CVSS score greater than or equal to '0.0':
[ERROR]
[ERROR] jetty-server-9.4.34.v20201102.jar: CVE-2020-27218
[ERROR] jetty-http-9.4.34.v20201102.jar: CVE-2020-27218
[ERROR]

Patrick


On Tue, Dec 1, 2020 at 8:58 AM Norbert Kalmar  wrote:

> This is a bugfix release candidate for 3.5.9. It contains 24 fixes,
> including 2 CVE fix.
>
> The full release notes is available at:
>
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310801=12348201
>
> *** Please download, test and vote by December 4th 2020, 23:59 UTC+0. ***
>
> Source files:
> https://people.apache.org/~nkalmar/zookeeper-3.5.9-candidate-0/
>
> Maven staging repo:
>
> https://repository.apache.org/content/groups/staging/org/apache/zookeeper/zookeeper/3.5.9/
>
> The release candidate tag in git to be voted upon: release-3.5.9-rc0
>
> ZooKeeper's KEYS file containing PGP keys we use to sign the release:
> https://www.apache.org/dist/zookeeper/KEYS
>
> Should we release this candidate?
>
> - Norbert
>

Re: [DISCUSS][PROPOSAL] Require JDK 11 to build for 3.7

[Patrick Hunt]

On Wed, Oct 21, 2020 at 9:03 AM Andor Molnar  wrote:

> As far as I know Hbase, Solr and Kafka are already Java 11 ready.
>
> IMHO contributors of those projects should also put efforts into moving
> forward.
>
> We’re not saying that you _have_ to move to Java 11.
> Staying on Java 8? No problem, 3.6 is for you.
> Want the fancy new features of 3.7? Work on it on your side too.
>
>
ppl want things like security fixes. I believe the highlighted downside is
that we would need to continue to maintain 3.6.x rather than allowing
users, and ourselves, to focus on trunk for production -"64 percent" would
be blocked.

Patrick


> Andor
>
>
>
> > On 2020. Oct 21., at 17:52, Enrico Olivelli  wrote:
> >
> > Il giorno mer 21 ott 2020 alle ore 17:49 Andor Molnar 
> ha
> > scritto:
> >
> >> Correct me if I'm wrong, but Oracle gets paid for extended support.
> >> Java 8 support until 2030 is not free of charge.
> >>
> >> "ZK may end up with a lot of users potentially locking themselves to
> >> 3.6.x for a while as Enrico mentioned."
> >>
> >> That's true. What's the downside of that which we should invest in to
> >> avoid?
> >>
> >
> > I see ZooKeeper used in many many projects, all of the
> > HBase/Pulsar/Kafka/Solr ecosystem...
> > they will have to move to JDK11 in order to move to the new ZK version
> > so probably they will stay on ZK 3.6
> >
> > Probably with Java 17 LTS released the cards will change on the table
> >
> > Enrico
> >
> >
> >
> >>
> >> Andor
> >>
> >>
> >>
> >> On Wed, 2020-10-21 at 08:03 -0700, Brent wrote:
> >>> As a slightly different consideration, if you look at the Long-Term
> >>> Support
> >>> (LTS) roadmaps for Java, currently Java 8 is set to have full support
> >>> until
> >>> 2030 from Oracle and at least 2026 from OpenJDK & Corretto:
> >>>
> >>> https://www.oracle.com/java/technologies/java-se-support-roadmap.html
> >>> https://en.wikipedia.org/wiki/Java_version_history
> >>>
> >>> My guess is that a number of companies are still heavily invested at
> >>> the
> >>> Java 8 level (I know a few) and with that kind of time horizon, they
> >>> have
> >>> no real motivation to upgrade for quite a while.  If the recent
> >>> Python 2
> >>> deprecation is anything to go by, they won't do it until they have
> >>> to.
> >>>
> >>> Not saying Java 8 isn't *very* old (2014 release it seems like?)  and
> >>> I'm
> >>> not invested heavily either way, but this might suggest that ZK may
> >>> end up
> >>> with a lot of users potentially locking themselves to 3.6.x for a
> >>> while as
> >>> Enrico mentioned.
> >>>
> >>> (Not a major contributor, but wanted to chime in since I just had
> >>> this
> >>> conversation with a bunch of people professionally recently)
> >>>
> >>> Brent
> >>>
> >>> On Wed, Oct 21, 2020 at 2:07 AM Andor Molnar 
> >>> wrote:
> >>>
>  Thanks for the summary.
> 
>  I still vote for option 1). Move 3.7.0 to JDK 11 fully. Other
>  projects
>  will upgrade once they’re JDK11 compliant, otherwise they will stay
>  on 3.5
>  or 3.6. Both version are quite recent in ZooKeeper-terms, we
>  already
>  planned big changes for 3.7.0 and JDK 11 could be one of them.
> 
>  Don’t put extra burden on the ZK community to help others staying
>  on
>  ancient Java versions.
> 
>  Andor
> 
> 
> 
> > On 2020. Oct 21., at 10:57, Enrico Olivelli 
> > wrote:
> >
> > Let me recap
> > - Christopher is proposing to move to JDK11
> > - ZooKeeper client and server are bundled and coded and tested
> > together
>  in
> > zookeeper-server
> > - Enrico is concerned about the need of testing ZooKeeper client
> > on JDK8
> > (not a problem to move the server to JDK11)
> >
> > ZooKeeper client is used by tons of users and unfortunately many
> > projects
> > are still on JDK8, if we move ZooKeeper to JDK11 the risk is to
> > block
>  users
> > from the adoption,
> > that is that we will see the world to stay on 3.6.x and we will
> > have
>  again
> > a long lived release line, like 3.4.
> >
> > Testing the client on JDK8 would be possible if we create some
> > kind of
> > additional module with system tests, then we can start the server
> > on
>  docker
> > on JDK11+ and start a client on JDK8
> > with Maven toolchain it should possible to run surefire tests
> > using a
> > separate JVM.
> >
> > So in my vision 2 options:
> > 1) fully JDK11 - drop JDK8 at all
> > 2) build with JDK11 - server only on JDK11 - add system tests
> > with docker
> > and toolchains that ensure the ZooKeeper client (and all
> > dependencies)
> > still work on JDK8
> >
> > From my point of view about the ZooKeeper ecosystem option 2)
> > will be far
> > better, but we need resources to work on a new test suite.
> >
> > Enrico
> >
> >
> > Il giorno mer 21 ott 2020 alle ore 

Re: [DISCUSS][PROPOSAL] Require JDK 11 to build for 3.7

[Patrick Hunt]

On Wed, Oct 21, 2020 at 8:04 AM Brent  wrote:

> As a slightly different consideration, if you look at the Long-Term Support
> (LTS) roadmaps for Java, currently Java 8 is set to have full support until
> 2030 from Oracle and at least 2026 from OpenJDK & Corretto:
>
> https://www.oracle.com/java/technologies/java-se-support-roadmap.html
> https://en.wikipedia.org/wiki/Java_version_history
>
> My guess is that a number of companies are still heavily invested at the
> Java 8 level (I know a few) and with that kind of time horizon, they have
> no real motivation to upgrade for quite a while.  If the recent Python 2
> deprecation is anything to go by, they won't do it until they have to.
>
> Not saying Java 8 isn't *very* old (2014 release it seems like?)  and I'm
> not invested heavily either way, but this might suggest that ZK may end up
> with a lot of users potentially locking themselves to 3.6.x for a while as
> Enrico mentioned.
>
> (Not a major contributor, but wanted to chime in since I just had this
> conversation with a bunch of people professionally recently)
>
>
I had similar thoughts as to what Brent has mentioned. Also there are
reports such as this one from inforworld in May of this year:
https://www.infoworld.com/article/3532358/oracle-extends-extended-support-for-java-8.html

"64 percent of Java users polled are using Java SE (Standard Edition) 8 for
their main application in production"

Given Oracle themselves have seen fit to continue supporting java8 I don't
see how we should drop it. In many cases there may be a corporate mandate
in place which keeps folks from utilizing a newer version - iow not a
technical decision.

Regards,

Patrick



> Brent
>
> On Wed, Oct 21, 2020 at 2:07 AM Andor Molnar  wrote:
>
> > Thanks for the summary.
> >
> > I still vote for option 1). Move 3.7.0 to JDK 11 fully. Other projects
> > will upgrade once they’re JDK11 compliant, otherwise they will stay on
> 3.5
> > or 3.6. Both version are quite recent in ZooKeeper-terms, we already
> > planned big changes for 3.7.0 and JDK 11 could be one of them.
> >
> > Don’t put extra burden on the ZK community to help others staying on
> > ancient Java versions.
> >
> > Andor
> >
> >
> >
> > > On 2020. Oct 21., at 10:57, Enrico Olivelli 
> wrote:
> > >
> > > Let me recap
> > > - Christopher is proposing to move to JDK11
> > > - ZooKeeper client and server are bundled and coded and tested together
> > in
> > > zookeeper-server
> > > - Enrico is concerned about the need of testing ZooKeeper client on
> JDK8
> > > (not a problem to move the server to JDK11)
> > >
> > > ZooKeeper client is used by tons of users and unfortunately many
> projects
> > > are still on JDK8, if we move ZooKeeper to JDK11 the risk is to block
> > users
> > > from the adoption,
> > > that is that we will see the world to stay on 3.6.x and we will have
> > again
> > > a long lived release line, like 3.4.
> > >
> > > Testing the client on JDK8 would be possible if we create some kind of
> > > additional module with system tests, then we can start the server on
> > docker
> > > on JDK11+ and start a client on JDK8
> > > with Maven toolchain it should possible to run surefire tests using a
> > > separate JVM.
> > >
> > > So in my vision 2 options:
> > > 1) fully JDK11 - drop JDK8 at all
> > > 2) build with JDK11 - server only on JDK11 - add system tests with
> docker
> > > and toolchains that ensure the ZooKeeper client (and all dependencies)
> > > still work on JDK8
> > >
> > > From my point of view about the ZooKeeper ecosystem option 2) will be
> far
> > > better, but we need resources to work on a new test suite.
> > >
> > > Enrico
> > >
> > >
> > > Il giorno mer 21 ott 2020 alle ore 10:43 Andor Molnar <
> an...@apache.org>
> > ha
> > > scritto:
> > >
> > >> Tamas, Enrico,
> > >>
> > >> Sorry I don’t follow. Why do we have to test the client with JDK 8 in
> > >> version 3.7.0?
> > >>
> > >> Andor
> > >>
> > >>
> > >>
> > >>
> > >>> On 2020. Oct 20., at 22:29, Tamas Penzes  >
> > >> wrote:
> > >>>
> > >>> Hi Enrico,
> > >>>
> > >>> Separating ZooKeeper client and server is a huge work, but we might
> not
> > >>> need it.
> > >>> As you mentioned we have to test ZK client with Java 8, what about
> > >>> separating only the test cases which we need to run with Java8 too?
> > >>> In Curator we have the ZK compatibility tests where we run a limited
> > >> amount
> > >>> of Curator's jUnit tests with a different ZK version.
> > >>> We might be able to do the same here, tag tests which are testing ZK
> > >> client
> > >>> and run them separately with Java 8. The only limitation is that
> these
> > >>> tests must stay JDK8 compatible.
> > >>> But from the tags we will see which ones are those.
> > >>>
> > >>> What do you think?
> > >>>
> > >>> Regards, Tamaas
> > >>>
> > >>> On Sat, Oct 17, 2020 at 7:45 AM Enrico Olivelli  >
> > >> wrote:
> > >>>
> >  Christopher
> >  I appreciate your idea and I also moved lots of my projects to work
> > the
> > >> 

Re: [DISCUSS] Log4j2 in ZooKeeper

[Patrick Hunt]

On Tue, Oct 20, 2020 at 1:18 PM Tamas Penzes 
wrote:

> Hi Patrick,
>
> I've read the ticket you have linked and also have used my time to ask
> after log4j2 backward compatibility and got quite negative feedback.
>
> It looks like we don't have a proper solution for it. We are (most
> probably) able to provide runtime selection of the logging framework, but
> we would still need a new log4j2 configuration file.
> There is a bw-compatibility layer of log4j configuration, but my sources
> told me not to use it as its functionality is very limited and it never
> became stable enough to use it in production.
>
> So the users must create a new log4j config file for log4j2, but I don't
> think it's a huge problem for ZooKeeper as it is small and its logging
> configuration isn't complex either.
> Doing it at the same time as updating ZooKeeper looks feasible and this is
> why I think we should not invest into the log4j version runtime selection.
>
> One day we have to do this step, my question is when?
> Should we wait for version 4 or can we do it in a "minor release", like
> 3.7. But ZK minor releases are like major releases on other Apache
> components.
>
>
What would a migration look like? Could we provide sufficient help for
people to easily migrate? It's not clear to me - if someone is using zk as
a client library and we upgrade log4j to log4j2 do they also need to
upgrade the code they are writing? (the code depending/using the zk jars).
I suspect embedding of zk server is also a possibility, although less
common, what would the impact be there? I believe the answer should be only
the configs but perhaps we should experiment, say by doing a poc with hbase
(any project relying on zk) and then comparing the impact?

Patrick


> Regards, Tamaas
>
>
> On Thu, Oct 8, 2020 at 8:24 PM Patrick Hunt  wrote:
>
> > On Thu, Oct 8, 2020 at 11:00 AM Tamas Penzes  >
> > wrote:
> >
> > > Hi All,
> > >
> > > I would open a discussion about log4j2 update.
> > > Would we consider going up to log4j2 in a minor release (e.g. 3.7) or
> > only
> > > in a major one, like 4.0?
> > > The latest log4j1 version (1.2.17) is really old and vulnerable, but
> > log4j2
> > > has a different config format, which means users should adopt their
> > config
> > > files when updating ZooKeeper.
> > > Afaik we are compatible with both of them because of slf4j, but the
> > default
> > > is log4j1 at the moment.
> > >
> > > What do you think about going up to log4j2 with 3.7?
> > >
> > >
> > Tamaas there's lots of background on this jira:
> > https://issues.apache.org/jira/browse/ZOOKEEPER-2342
> > In particular concern with b/w compat. There is also a patch attached.
> >
> > Is there a way we can provide run time selection without impacting code
> in
> > a non-bw compatible way? Have other projects been able to solve this?
> >
> > Patrick
> >
> >
> > > Thanks, Tamaas
> > >
> >
>

Re: [DISCUSS] Log4j2 in ZooKeeper

[Patrick Hunt]

On Thu, Oct 8, 2020 at 11:00 AM Tamas Penzes 
wrote:

> Hi All,
>
> I would open a discussion about log4j2 update.
> Would we consider going up to log4j2 in a minor release (e.g. 3.7) or only
> in a major one, like 4.0?
> The latest log4j1 version (1.2.17) is really old and vulnerable, but log4j2
> has a different config format, which means users should adopt their config
> files when updating ZooKeeper.
> Afaik we are compatible with both of them because of slf4j, but the default
> is log4j1 at the moment.
>
> What do you think about going up to log4j2 with 3.7?
>
>
Tamaas there's lots of background on this jira:
https://issues.apache.org/jira/browse/ZOOKEEPER-2342
In particular concern with b/w compat. There is also a patch attached.

Is there a way we can provide run time selection without impacting code in
a non-bw compatible way? Have other projects been able to solve this?

Patrick


> Thanks, Tamaas
>

Re: CI build issues

[Patrick Hunt]

On Tue, Sep 15, 2020 at 2:46 PM Andor Molnar  wrote:

> "What's the process for making changes now?”
>
> Like for any code changes: open Github PR.
>
>
Sure I know how to submit a PR, but what's the process for creating one for
jenkins? I'm familiar with manually editing jobs, but not whatever else is
required.

Patrick


> "How do I verify a job before submitting it via git?”
>
> Create a personal job which is pointing to your repo like mine:
>
> https://ci-hadoop.apache.org/view/ZooKeeper/job/zookeeper-master-maven-multipipeline-andor/
>
> Not so nice, but that’s what we have for now.
>
> Andor
>
>
>
> > On 2020. Sep 15., at 22:54, Patrick Hunt  wrote:
> >
> > On Tue, Sep 15, 2020 at 12:55 PM Andor Molnar  wrote:
> >
> >> Hi Michael,
> >>
> >> I was working on the CI migration and there’re still a few things which
> is
> >> not available in the new system. I haven’t found any solution for the
> >> “retest” trigger, but I’ll take another look tomorrow. I need to dig the
> >> builds@ list if there’s anything happened since I’ve last checked e.g.
> >> new plugins installed, etc.
> >>
> >> I’m not sure I understand your concern about dead links. Here’s the link
> >> of the pre-commit job for your PR:
> >>
> >>
> https://ci-hadoop.apache.org/view/ZooKeeper/job/zookeeper-precommit-github-pr/view/change-requests/job/PR-1380/
> >>
> >> From the Github PR page I can see the following link:
> >>
> >>
> https://ci-hadoop.apache.org/blue/organizations/jenkins/zookeeper-precommit-github-pr/detail/PR-1380/4/pipeline
> >>
> >> Which takes me to the Pipeline Report and definitely not dead. (This
> must
> >> be some new thing, but looks quite cool.)
> >>
> >> OWASP Build - Good point Patrick, that’s still missing.
> >> I’ve created the branch and PreCommit jobs as Jenkins pipelines, nicely
> >> committed and tracked in Git. I believe that’s how we should do CI in
> the
> >> future. But I was reluctant do the same with flaky-test job which is
> just a
> >> copy-and-paste Jenkins job atm.
> >>
> >>
> > What's the process for making changes now? How do I verify a job before
> > submitting it via git?
> >
> > Patrick
> >
> >
> >> Feel free to choose your way for the Owasp build, if you’re willing to
> >> migrate it, but I think at the end of the way we should have everything
> in
> >> source control to be perfect.
> >>
> >> We still don’t have Windows build either, but I’m not sure if
> >> Windows-based nodes are available.
> >>
> >> Andor
> >>
> >>
> >>
> >>> On 2020. Sep 13., at 23:02, Michael Han  wrote:
> >>>
> >>> Folks,
> >>>
> >>> I am seeing some CI build issues. Specifically:
> >>>
> >>> * Comment on github PR with "retest maven build" does not trigger a
> >> rebuild
> >>> of JenkinsMaven. This used to work. Is this a known issue?
> >>>
> >>> * Tons of pre-merge job links on PRs are broken: they actually link to
> a
> >>> deleted ci job I created a few days ago to test the new CI system. Here
> >> is
> >>> a broken link
> >>> <
> >>
> https://ci-hadoop.apache.org/job/zookeeper_hanm_tests/job/PR-1380/1/display/redirect
> >>>
> >>> for reference. Do we know how we can trigger a new pre-merge job on
> >>> existing PRs so these links can be fixed?
>
>

Re: CI build issues

[Patrick Hunt]

On Tue, Sep 15, 2020 at 12:55 PM Andor Molnar  wrote:

> Hi Michael,
>
> I was working on the CI migration and there’re still a few things which is
> not available in the new system. I haven’t found any solution for the
> “retest” trigger, but I’ll take another look tomorrow. I need to dig the
> builds@ list if there’s anything happened since I’ve last checked e.g.
> new plugins installed, etc.
>
> I’m not sure I understand your concern about dead links. Here’s the link
> of the pre-commit job for your PR:
>
> https://ci-hadoop.apache.org/view/ZooKeeper/job/zookeeper-precommit-github-pr/view/change-requests/job/PR-1380/
>
> From the Github PR page I can see the following link:
>
> https://ci-hadoop.apache.org/blue/organizations/jenkins/zookeeper-precommit-github-pr/detail/PR-1380/4/pipeline
>
> Which takes me to the Pipeline Report and definitely not dead. (This must
> be some new thing, but looks quite cool.)
>
> OWASP Build - Good point Patrick, that’s still missing.
> I’ve created the branch and PreCommit jobs as Jenkins pipelines, nicely
> committed and tracked in Git. I believe that’s how we should do CI in the
> future. But I was reluctant do the same with flaky-test job which is just a
> copy-and-paste Jenkins job atm.
>
>
What's the process for making changes now? How do I verify a job before
submitting it via git?

Patrick


> Feel free to choose your way for the Owasp build, if you’re willing to
> migrate it, but I think at the end of the way we should have everything in
> source control to be perfect.
>
> We still don’t have Windows build either, but I’m not sure if
> Windows-based nodes are available.
>
> Andor
>
>
>
> > On 2020. Sep 13., at 23:02, Michael Han  wrote:
> >
> > Folks,
> >
> > I am seeing some CI build issues. Specifically:
> >
> > * Comment on github PR with "retest maven build" does not trigger a
> rebuild
> > of JenkinsMaven. This used to work. Is this a known issue?
> >
> > * Tons of pre-merge job links on PRs are broken: they actually link to a
> > deleted ci job I created a few days ago to test the new CI system. Here
> is
> > a broken link
> > <
> https://ci-hadoop.apache.org/job/zookeeper_hanm_tests/job/PR-1380/1/display/redirect
> >
> > for reference. Do we know how we can trigger a new pre-merge job on
> > existing PRs so these links can be fixed?
>
>

Re: CI build issues

[Patrick Hunt]

Also - how do we get the owasp check added back? Are we manually adding
jobs through the UI or is there a new process?

Patrick

On Sun, Sep 13, 2020 at 2:02 PM Michael Han  wrote:

> Folks,
>
> I am seeing some CI build issues. Specifically:
>
> * Comment on github PR with "retest maven build" does not trigger a rebuild
> of JenkinsMaven. This used to work. Is this a known issue?
>
> * Tons of pre-merge job links on PRs are broken: they actually link to a
> deleted ci job I created a few days ago to test the new CI system. Here is
> a broken link
> <
> https://ci-hadoop.apache.org/job/zookeeper_hanm_tests/job/PR-1380/1/display/redirect
> >
> for reference. Do we know how we can trigger a new pre-merge job on
> existing PRs so these links can be fixed?
>

Re: [VOTE] Apache ZooKeeper 3.6.2 candidate 1

[Patrick Hunt]

+1. xsum/sig validate. RAT ran clean. Was able to build and do manual
testing with various ensemble sizes successfully. lgtm.

Patrick

On Fri, Sep 4, 2020 at 6:01 AM Enrico Olivelli  wrote:

> This is a release candidate for 3.6.2.
>
> It is a minor release and it fixes a few critical issues and brings a few
> dependencies upgrades.
>
> The full release notes is available at:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310801=12347809
>
> *** Please download, test and vote by September 7th 2020, 23:59 UTC+0. ***
>
> Source files:
> https://people.apache.org/~eolivelli/zookeeper-3.6.2-candidate-1/
>
> Maven staging repo:
> https://repository.apache.org/content/repositories/orgapachezookeeper-1061/
>
> The release candidate tag in git to be voted upon: release-3.6.2-1
> https://github.com/apache/zookeeper/tree/release-3.6.2-1
>
> ZooKeeper's KEYS file containing PGP keys we use to sign the release:
> https://www.apache.org/dist/zookeeper/KEYS
>
> The staging version of the website is:
> https://people.apache.org/~eolivelli/zookeeper-3.6.2-candidate-1/website/
>
> Should we release this candidate?
> Enrico Olivelli
>

Re: [CANCEL] [VOTE] Apache ZooKeeper release 3.6.2 candidate 0

[Patrick Hunt]

On Fri, Sep 4, 2020 at 4:47 AM Enrico Olivelli  wrote:

> I am cancelling this VOTE.
>
> I will send RC1 soon, the problem about license files has been fixed.
>
>
The cli issue is 100% reproducible for me with 3.6/3.5 but not 3.4. I tried
a bunch of other stuff (turned off vpn, etc...) with no luck. Tried
increasing the log level but that isn't shedding light either. I'll try and
dig into it deeper if I have time but I'd recommend not blocking any
release activities given I'm the only one to report it. Thanks for the f/b
Ted/Michael/et.al. Very odd. :-)

Patrick


> Stay tuned
> Enrico
>
> Il giorno ven 4 set 2020 alle ore 02:35 Michael Han  ha
> scritto:
>
> > Haven't fully tested the RC but I didn't experience any of the lag
> through
> > the cli.
> >
> > On Thu, Sep 3, 2020 at 3:15 PM Ted Dunning 
> wrote:
> >
> > > On Thu, Sep 3, 2020 at 1:58 PM Patrick Hunt  wrote:
> > >
> > > > On Thu, Sep 3, 2020 at 1:54 PM Ted Dunning 
> > > wrote:
> > > >
> > > > > OK. Did it with the correct version this time. I saw no typing
> delays
> > > in
> > > > > zkCli.sh.
> > > > ...
> > > > Hm, no idea - I tried the regular mac terminal (I use iterm2) and
> also
> > > > tried launching from sh vs bash but no changes. Very odd.
> > >
> > >
> > > I use the normal terminal on my mac so our environments are very
> similar.
> > >
> >
>

Re: [VOTE] Apache ZooKeeper release 3.6.2 candidate 0

[Patrick Hunt]

On Thu, Sep 3, 2020 at 1:54 PM Ted Dunning  wrote:

> OK. Did it with the correct version this time. I saw no typing delays in
> zkCli.sh.
>
> $ git checkout release-3.6.2-0
>
> $
>
>
Hm, no idea - I tried the regular mac terminal (I use iterm2) and also
tried launching from sh vs bash but no changes. Very odd.

Patrick


>
>
>
> On Thu, Sep 3, 2020 at 12:28 PM Ted Dunning  wrote:
>
> >
> > Argh.
> >
> > Will check again.
> >
> >
> >
> > On Thu, Sep 3, 2020 at 11:10 AM Enrico Olivelli 
> > wrote:
> >
> >> Ted
> >> The branch is release-3.6.2 and not 3.6.1
> >> Thanks foe testing
> >> Enrico
> >>
> >> Il Gio 3 Set 2020, 19:50 Ted Dunning  ha
> scritto:
> >>
> >> > On Thu, Sep 3, 2020 at 9:23 AM Patrick Hunt  wrote:
> >> >
> >> > > ...
> >> > > > > Il giorno mer 2 set 2020 alle ore 22:03 Patrick Hunt <
> >> > ph...@apache.org
> >> > > >
> >> > > > > ha scritto:
> >> > > > >
> >> > > > >> I'm also noticing a very long lag when using the cli
> >> > > >
> >> > > > I am not experiencing this problem, I am on Mac, tested on
> >> branch-3.6
> >> > and
> >> > > > current master
> >> > > >
> >> > > > Do you have any another clue ?
> >> > > >
> >> > >
> >> > > Interesting. I tried with the bin artifact for this rc and
> >> > > zoo_sample.cfg/zkServer/zkCli and it reproduces. I can type "ls /"
> in
> >> the
> >> > > cli before it starts echoing back the command to the command line
> for
> >> me
> >> > to
> >> > > see. I then pulled the bin from 3.5.8 (jline 1.11) and it reproduces
> >> the
> >> > > issue as well. I pulled/built 3.4.14 (jline 0.9.94) and that one is
> >> fine,
> >> > > no issue. It's odd that I never noticed it before though. I'm on
> >> java11
> >> > on
> >> > > a mac also. If no one but me is seeing it then perhaps we should
> keep
> >> an
> >> > > eye on it but not block the release.
> >> > >
> >> >
> >> >
> >> > I just cloned, checked out release-3.6.1-1
> >> > Compiled using mvn package (love the maven build, btw)
> >> > Using java OpenJDK 64-Bit Server VM AdoptOpenJDK (build 12.0.2+10,
> mixed
> >> > mode, sharing)
> >> >
> >> > I did small tests from the zkCli and observed no lag whatsoever.
> >> >
> >>
> >
>

Re: [VOTE] Apache ZooKeeper release 3.6.2 candidate 0

[Patrick Hunt]

On Thu, Sep 3, 2020 at 5:19 AM Enrico Olivelli  wrote:

> Patrick,
>
> Il giorno gio 3 set 2020 alle ore 08:48 Enrico Olivelli <
> eolive...@gmail.com>
> ha scritto:
>
> >
> >
> > Il giorno mer 2 set 2020 alle ore 22:03 Patrick Hunt 
> > ha scritto:
> >
> >> I'm also noticing a very long lag when using the cli. I tried with both
> >> java8 and java11 and in both cases the cli is very laggy - even for
> basic
> >> stuff like typing a command (not running the command) the echo back of
> >> each
> >> key typed is incurring significant lag. I have not noticed this before -
> >> likely resulting from the change to jline?
> >>
> >
> > Yet is it possible, let me debug this issue, I didn't notice it.
> > Probably there is some "flush" to be called
> >
>
>
> I am not experiencing this problem, I am on Mac, tested on branch-3.6 and
> current master
>
> Do you have any another clue ?
>

Interesting. I tried with the bin artifact for this rc and
zoo_sample.cfg/zkServer/zkCli and it reproduces. I can type "ls /" in the
cli before it starts echoing back the command to the command line for me to
see. I then pulled the bin from 3.5.8 (jline 1.11) and it reproduces the
issue as well. I pulled/built 3.4.14 (jline 0.9.94) and that one is fine,
no issue. It's odd that I never noticed it before though. I'm on java11 on
a mac also. If no one but me is seeing it then perhaps we should keep an
eye on it but not block the release.

Patrick


>
>
> >
> > Enrico
> >
> >
> >>
> >> Patrick
> >>
> >> On Wed, Sep 2, 2020 at 12:55 PM Patrick Hunt  wrote:
> >>
> >> > -1 - the license files are inconsistent for both jline and netty
> >> libraries.
> >> >
> >> > Patrick
> >> >
> >> > On Tue, Sep 1, 2020 at 2:35 AM Enrico Olivelli 
> >> > wrote:
> >> >
> >> >> This is a release candidate for 3.6.2.
> >> >>
> >> >> It is a minor release and it fixes a few critical issues and brings a
> >> few
> >> >> dependencies upgrades.
> >> >>
> >> >> The full release notes is available at:
> >> >>
> >> >>
> >>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310801=12347809
> >> >>
> >> >> *** Please download, test and vote by September 4th 2020, 23:59
> UTC+0.
> >> ***
> >> >>
> >> >> Source files:
> >> >> https://people.apache.org/~eolivelli/zookeeper-3.6.2-candidate-0/
> >> >>
> >> >> Maven staging repo:
> >> >>
> >> >>
> >>
> https://repository.apache.org/content/repositories/orgapachezookeeper-1060/
> >> >>
> >> >> The release candidate tag in git to be voted upon: release-3.6.2-0
> >> >> https://github.com/apache/zookeeper/tree/release-3.6.2-0
> >> >>
> >> >> ZooKeeper's KEYS file containing PGP keys we use to sign the release:
> >> >> https://www.apache.org/dist/zookeeper/KEYS
> >> >>
> >> >> The staging version of the website is:
> >> >>
> >>
> https://people.apache.org/~eolivelli/zookeeper-3.6.2-candidate-0/website/
> >> >>
> >> >> Should we release this candidate?
> >> >>
> >> >> Enrico Olivelli
> >> >>
> >> >
> >>
> >
>

Re: [VOTE] Apache ZooKeeper release 3.6.2 candidate 0

[Patrick Hunt]

I'm also noticing a very long lag when using the cli. I tried with both
java8 and java11 and in both cases the cli is very laggy - even for basic
stuff like typing a command (not running the command) the echo back of each
key typed is incurring significant lag. I have not noticed this before -
likely resulting from the change to jline?

Patrick

On Wed, Sep 2, 2020 at 12:55 PM Patrick Hunt  wrote:

> -1 - the license files are inconsistent for both jline and netty libraries.
>
> Patrick
>
> On Tue, Sep 1, 2020 at 2:35 AM Enrico Olivelli 
> wrote:
>
>> This is a release candidate for 3.6.2.
>>
>> It is a minor release and it fixes a few critical issues and brings a few
>> dependencies upgrades.
>>
>> The full release notes is available at:
>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310801=12347809
>>
>> *** Please download, test and vote by September 4th 2020, 23:59 UTC+0. ***
>>
>> Source files:
>> https://people.apache.org/~eolivelli/zookeeper-3.6.2-candidate-0/
>>
>> Maven staging repo:
>>
>> https://repository.apache.org/content/repositories/orgapachezookeeper-1060/
>>
>> The release candidate tag in git to be voted upon: release-3.6.2-0
>> https://github.com/apache/zookeeper/tree/release-3.6.2-0
>>
>> ZooKeeper's KEYS file containing PGP keys we use to sign the release:
>> https://www.apache.org/dist/zookeeper/KEYS
>>
>> The staging version of the website is:
>> https://people.apache.org/~eolivelli/zookeeper-3.6.2-candidate-0/website/
>>
>> Should we release this candidate?
>>
>> Enrico Olivelli
>>
>

Re: [VOTE] Apache ZooKeeper release 3.6.2 candidate 0

[Patrick Hunt]

-1 - the license files are inconsistent for both jline and netty libraries.

Patrick

On Tue, Sep 1, 2020 at 2:35 AM Enrico Olivelli  wrote:

> This is a release candidate for 3.6.2.
>
> It is a minor release and it fixes a few critical issues and brings a few
> dependencies upgrades.
>
> The full release notes is available at:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310801=12347809
>
> *** Please download, test and vote by September 4th 2020, 23:59 UTC+0. ***
>
> Source files:
> https://people.apache.org/~eolivelli/zookeeper-3.6.2-candidate-0/
>
> Maven staging repo:
> https://repository.apache.org/content/repositories/orgapachezookeeper-1060/
>
> The release candidate tag in git to be voted upon: release-3.6.2-0
> https://github.com/apache/zookeeper/tree/release-3.6.2-0
>
> ZooKeeper's KEYS file containing PGP keys we use to sign the release:
> https://www.apache.org/dist/zookeeper/KEYS
>
> The staging version of the website is:
> https://people.apache.org/~eolivelli/zookeeper-3.6.2-candidate-0/website/
>
> Should we release this candidate?
>
> Enrico Olivelli
>

Re: jUnit5 migration review

[Patrick Hunt]

What's the impact of such a change on projects incorporating//depending
upon ZK test libraries? Is that still a thing?

Patrick

On Wed, Jul 29, 2020 at 2:32 PM Tamas Penzes 
wrote:

> Hi All,
>
> If you have (a lot of) free time and would like to review my pull request I
> would be over the seventh heaven.
> It can be found here: https://github.com/apache/zookeeper/pull/1417
> That's the next step of jUnit4 to 5 migration.
>
> Thanks, Tamaas
>

Re: [IMPORTANT] - Migration to ci-builds.a.o

[Patrick Hunt]

On Fri, Jul 24, 2020 at 3:05 AM Andor Molnar  wrote:

> Hi,
>
> Jenkinsfile is now committed to master, 3.5 and 3.6 branches. Build is
> running here:
>
> https://ci-hadoop.apache.org/view/ZooKeeper/job/zookeeper-master-maven-multipipeline/
>
> I use standard Git interface to access the repo, because using GitHub
> means that branch discovery has to run through the github API. The problem
> with this is that I haven’t specified credentials and anonymous access is
> limited by some quota, meaning the discovery process takes ages (1-2 hours).
>
> Builds are running fine except I see a lot of concurrent builds on master
> without any meaningful SCM change. Odd. I will change pollSCM trigger to
> run @hourly and will see how it goes.
>
> What’s outstanding?
>
> - JDKs: currently only two: 8, 11 (LTS versions). What other JDKs would
> you like to run against?
>
> - GitHub Pull Requests precommit job: I have no idea how to do this, but I
> suspect we have to use the GitHub Api for this to work.
>
>
Not sure if this is helpful but I saw it recently:

> we need ability to trigger builds on pull request creation/updates which

> requires the plug-in below or similar:

> https://plugins.jenkins.io/ghprb/



That plugin is deprecated and not recommended for use .


I have installed the *branch source plugin instead*, hopefully that works
for

you.


If not, let's investigate further what else we can do



> - Windows build: there’s no Windows agent available currently in the new
> instance.
>
> - Ant builds: do we need this?
>
> Please share your thoughts.
>
> Regards,
> Andor
>
>
>
>
> > On 2020. Jul 23., at 22:08, Andor Molnar  wrote:
> >
> > Hi folks,
> >
> > PR is available: https://github.com/apache/zookeeper/pull/1409
> >
> > Andor
> >
> >
> >
> > On Thu, 2020-07-23 at 11:32 +0200, Andor Molnar wrote:
> >> Created a Jira for the task:
> >>
> >> https://issues.apache.org/jira/browse/ZOOKEEPER-3896
> >>
> >> Andor
> >>
> >>
> >>
> >>> On 2020. Jul 21., at 12:10, Andor Molnar  wrote:
> >>>
> >>> Where’s that example…?
> >>>
> >>>
> >>>
> >>>> On 2020. Jul 20., at 20:02, Enrico Olivelli 
> >>>> wrote:
> >>>>
> >>>> Il Lun 20 Lug 2020, 19:40 Andor Molnar  ha
> >>>> scritto:
> >>>>
> >>>>> Hi Enrico,
> >>>>>
> >>>>> No worries, I only created a few jobs to make some progress,
> >>>>> but feel free
> >>>>> to ignore that and do it in a better way. The “View” or
> >>>>> “Folder” that I was
> >>>>> adding jobs is
> >>>>>
> >>>>> https://ci-hadoop.apache.org/view/ZooKeeper/
> >>>>>
> >>>>>
> >>>>> Andor
> >>>>>
> >>>>
> >>>> This is an example from Apache Maven  project. It is very complex
> >>>> because
> >>>> tests are in another repo and for lots if other reasons. We just
> >>>> have to
> >>>> create a simpler file.
> >>>>
> >>>> If nobody volunteers I can try to spend some time but I won't
> >>>> have a fast
> >>>> pace these weeks
> >>>>
> >>>>
> >>>> Enrico
> >>>>
> >>>>
> >>>>
> >>>>>
> >>>>>> On 2020. Jul 20., at 19:34, Enrico Olivelli <
> >>>>>> eolive...@gmail.com> wrote:
> >>>>>>
> >>>>>> Il Lun 20 Lug 2020, 19:02 Patrick Hunt  ha
> >>>>>> scritto:
> >>>>>>
> >>>>>>> On Mon, Jul 20, 2020 at 9:47 AM Enrico Olivelli <
> >>>>>>> eolive...@gmail.com>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> Il Lun 20 Lug 2020, 18:41 Patrick Hunt 
> >>>>>>>> ha scritto:
> >>>>>>>>
> >>>>>>>>> On Sat, Jul 18, 2020 at 12:20 PM Andor Molnar <
> >>>>>>>>> an...@apache.org>
> >>>>>>> wrote:
> >>>>>>>>>> Hi Pat,
> >>>>>>>>>>
> >>>>>>>>>> I have admin rights in the new system too and
> >>>>>>>>&g

Re: [IMPORTANT] - Migration to ci-builds.a.o

[Patrick Hunt]

On Mon, Jul 20, 2020 at 9:47 AM Enrico Olivelli  wrote:

> Il Lun 20 Lug 2020, 18:41 Patrick Hunt  ha scritto:
>
> > On Sat, Jul 18, 2020 at 12:20 PM Andor Molnar  wrote:
> >
> > > Hi Pat,
> > >
> > > I have admin rights in the new system too and probably can work on this
> > on
> > > Monday.
> > > What’s “matrix” config? Shouldn’t we just replicate the same jobs on
> the
> > > new instance?
> > >
> > >
> > Not sure on the exact name/feature but "matrix" is basically the ability
> to
> > say "run this build/test across a set of JDK versions" rather than a
> single
> > version. As a result, instead of 3 jobs for zk3.6.0, jdk 1/2/3 you end up
> > with a single job which runs three times, one for each jdk type and
> > summarizes the results. I've seen this before, I assume it's a feature of
> > jenkins itself?
> >
>
> We should use Jenkins files and this configuration will be easy and
> committed to git
>

The ability to do "gitops" would be amazing!

Patrick


>
> Enrico
>
>
>
> > Patrick
> >
> >
> > > Andor
> > >
> > >
> > >
> > > > On 2020. Jul 17., at 2:51, Patrick Hunt  wrote:
> > > >
> > > > I updated the job I linked earlier based on what's the latest on the
> > > legacy
> > > > jenkins. It ran successfully
> > > > https://ci-hadoop.apache.org/job/zookeeper-master-maven/215/
> > > >
> > > > I didn't replicate every config setting - main gap is the spotbugs
> > > > post-build, which seems to be missing from the new jenkins plugins.
> > > >
> > > > That's just maven master though. Not sure about the rest. Can we do
> > more
> > > of
> > > > a "matrix" config in the new system vs cloning all the time?
> > > >
> > > > Patrick
> > > >
> > > > On Thu, Jul 16, 2020 at 3:31 PM Patrick Hunt 
> wrote:
> > > >
> > > >>
> > > >> On Thu, Jul 16, 2020 at 3:22 PM Patrick Hunt 
> > wrote:
> > > >>
> > > >>>
> > > >>>
> > > >>> On Thu, Jul 16, 2020 at 12:56 PM Enrico Olivelli <
> > eolive...@gmail.com>
> > > >>> wrote:
> > > >>>
> > > >>>> FYI
> > > >>>>
> > > >>>
> > > >>> Fun. I do notice it says "Hadoop and related projects have their
> own
> > > >>> migration path to follow" - any insight on that? We are or are not
> > > lumped
> > > >>> in? I would assume we are?
> > > >>>
> > > >>> This (eventual migration) came up a while back on the Hadoop PMC
> and
> > I
> > > >>> volunteered to try for us (ZK). I was never able to get it to
> work, I
> > > >>> provided feedback to infra  but they never got back, as such we
> have
> > a
> > > >>> project here that's not working with some basic dependencies
> missing:
> > > >>> https://ci-hadoop.apache.org/job/zookeeper-master-maven/
> > > >>>
> > > >>> That said, we can try again. Can we verify where ZK is supposed to
> > > land?
> > > >>> Perhaps we can try to delete and recreate the POC job I created at
> > that
> > > >>> link to see if we can get it working?
> > > >>>
> > > >>>
> > > >> I see another email thread on the list saying that we are part of
> said
> > > >> "related projects". We are expected to move to
> > > >> http://ci-hadoop.apache.org/ within 4 weeks. Seems nodes are
> already
> > > >> being removed/migrated from the "H#" pool.
> > > >>
> > > >> Also this:
> > > >>
> > > >> There are over 400 plugins on the current builds.apache.org - most
> of
> > > which
> > > >> we don't need any more, or are replaced with different plugins on
> the
> > > new
> > > >> system. I expect there may be some plugins we still need to install
> to
> > > get
> > > >> you going again, which is why it is vitally important that you start
> > > >> testing and migrating your jobs over *now*. You should all have
> auth.
> > > >>
> > > >> Any questions, feel free to email the hadoop-migrati...@apache.org
&

Re: [IMPORTANT] - Migration to ci-builds.a.o

[Patrick Hunt]

On Sat, Jul 18, 2020 at 12:20 PM Andor Molnar  wrote:

> Hi Pat,
>
> I have admin rights in the new system too and probably can work on this on
> Monday.
> What’s “matrix” config? Shouldn’t we just replicate the same jobs on the
> new instance?
>
>
Not sure on the exact name/feature but "matrix" is basically the ability to
say "run this build/test across a set of JDK versions" rather than a single
version. As a result, instead of 3 jobs for zk3.6.0, jdk 1/2/3 you end up
with a single job which runs three times, one for each jdk type and
summarizes the results. I've seen this before, I assume it's a feature of
jenkins itself?

Patrick


> Andor
>
>
>
> > On 2020. Jul 17., at 2:51, Patrick Hunt  wrote:
> >
> > I updated the job I linked earlier based on what's the latest on the
> legacy
> > jenkins. It ran successfully
> > https://ci-hadoop.apache.org/job/zookeeper-master-maven/215/
> >
> > I didn't replicate every config setting - main gap is the spotbugs
> > post-build, which seems to be missing from the new jenkins plugins.
> >
> > That's just maven master though. Not sure about the rest. Can we do more
> of
> > a "matrix" config in the new system vs cloning all the time?
> >
> > Patrick
> >
> > On Thu, Jul 16, 2020 at 3:31 PM Patrick Hunt  wrote:
> >
> >>
> >> On Thu, Jul 16, 2020 at 3:22 PM Patrick Hunt  wrote:
> >>
> >>>
> >>>
> >>> On Thu, Jul 16, 2020 at 12:56 PM Enrico Olivelli 
> >>> wrote:
> >>>
> >>>> FYI
> >>>>
> >>>
> >>> Fun. I do notice it says "Hadoop and related projects have their own
> >>> migration path to follow" - any insight on that? We are or are not
> lumped
> >>> in? I would assume we are?
> >>>
> >>> This (eventual migration) came up a while back on the Hadoop PMC and I
> >>> volunteered to try for us (ZK). I was never able to get it to work, I
> >>> provided feedback to infra  but they never got back, as such we have a
> >>> project here that's not working with some basic dependencies missing:
> >>> https://ci-hadoop.apache.org/job/zookeeper-master-maven/
> >>>
> >>> That said, we can try again. Can we verify where ZK is supposed to
> land?
> >>> Perhaps we can try to delete and recreate the POC job I created at that
> >>> link to see if we can get it working?
> >>>
> >>>
> >> I see another email thread on the list saying that we are part of said
> >> "related projects". We are expected to move to
> >> http://ci-hadoop.apache.org/ within 4 weeks. Seems nodes are already
> >> being removed/migrated from the "H#" pool.
> >>
> >> Also this:
> >>
> >> There are over 400 plugins on the current builds.apache.org - most of
> which
> >> we don't need any more, or are replaced with different plugins on the
> new
> >> system. I expect there may be some plugins we still need to install to
> get
> >> you going again, which is why it is vitally important that you start
> >> testing and migrating your jobs over *now*. You should all have auth.
> >>
> >> Any questions, feel free to email the hadoop-migrati...@apache.org
> list if
> >> you are one of the projects listed below. The rest of you, not listed, a
> >> similar email to this one will be posted for you shortly on builds@a.o.
> >>
> >>
> >> full details
> >>
> https://lists.apache.org/thread.html/r21c9d40cdbf5461143dd7eb4ff48a200c2fd20c50e946884f61318fd%40%3Cbuilds.apache.org%3E
> >>
> >> Patrick
> >>
> >>
> >>
> >>> Patrick
> >>>
> >>>
> >>>>
> >>>> -- Forwarded message -
> >>>> Da: Gavin McDonald 
> >>>> Date: Gio 16 Lug 2020, 18:33
> >>>> Subject: [IMPORTANT] - Migration to ci-builds.a.o
> >>>> To: builds 
> >>>>
> >>>>
> >>>> Hi All,
> >>>>
> >>>> This NOTICE is for everyone on builds.apache.org. We are migrating
> to a
> >>>> new
> >>>> Cloudbees based Client Master called https://ci-builds.apache.org.
> The
> >>>> migrations of all jobs needs to be done before the switch off date of
> >>>> 15th
> >>>> August 2020, so you have a maximum of 4 weeks.
> >>>>
> >>>> There is

Re: [IMPORTANT] - Migration to ci-builds.a.o

[Patrick Hunt]

I updated the job I linked earlier based on what's the latest on the legacy
jenkins. It ran successfully
https://ci-hadoop.apache.org/job/zookeeper-master-maven/215/

I didn't replicate every config setting - main gap is the spotbugs
post-build, which seems to be missing from the new jenkins plugins.

That's just maven master though. Not sure about the rest. Can we do more of
a "matrix" config in the new system vs cloning all the time?

Patrick

On Thu, Jul 16, 2020 at 3:31 PM Patrick Hunt  wrote:

>
> On Thu, Jul 16, 2020 at 3:22 PM Patrick Hunt  wrote:
>
>>
>>
>> On Thu, Jul 16, 2020 at 12:56 PM Enrico Olivelli 
>> wrote:
>>
>>> FYI
>>>
>>
>> Fun. I do notice it says "Hadoop and related projects have their own
>> migration path to follow" - any insight on that? We are or are not lumped
>> in? I would assume we are?
>>
>> This (eventual migration) came up a while back on the Hadoop PMC and I
>> volunteered to try for us (ZK). I was never able to get it to work, I
>> provided feedback to infra  but they never got back, as such we have a
>> project here that's not working with some basic dependencies missing:
>> https://ci-hadoop.apache.org/job/zookeeper-master-maven/
>>
>> That said, we can try again. Can we verify where ZK is supposed to land?
>> Perhaps we can try to delete and recreate the POC job I created at that
>> link to see if we can get it working?
>>
>>
> I see another email thread on the list saying that we are part of said
> "related projects". We are expected to move to
> http://ci-hadoop.apache.org/ within 4 weeks. Seems nodes are already
> being removed/migrated from the "H#" pool.
>
> Also this:
>
> There are over 400 plugins on the current builds.apache.org - most of which
> we don't need any more, or are replaced with different plugins on the new
> system. I expect there may be some plugins we still need to install to get
> you going again, which is why it is vitally important that you start
> testing and migrating your jobs over *now*. You should all have auth.
>
> Any questions, feel free to email the hadoop-migrati...@apache.org list if
> you are one of the projects listed below. The rest of you, not listed, a
> similar email to this one will be posted for you shortly on builds@a.o.
>
>
> full details
> https://lists.apache.org/thread.html/r21c9d40cdbf5461143dd7eb4ff48a200c2fd20c50e946884f61318fd%40%3Cbuilds.apache.org%3E
>
> Patrick
>
>
>
>> Patrick
>>
>>
>>>
>>> -- Forwarded message -
>>> Da: Gavin McDonald 
>>> Date: Gio 16 Lug 2020, 18:33
>>> Subject: [IMPORTANT] - Migration to ci-builds.a.o
>>> To: builds 
>>>
>>>
>>> Hi All,
>>>
>>> This NOTICE is for everyone on builds.apache.org. We are migrating to a
>>> new
>>> Cloudbees based Client Master called https://ci-builds.apache.org. The
>>> migrations of all jobs needs to be done before the switch off date of
>>> 15th
>>> August 2020, so you have a maximum of 4 weeks.
>>>
>>> There is no tool or automated way of migrating your jobs, the
>>> differences in the platforms, the plugins and the setup makes it
>>> impossible
>>> to do in a safe way. So, you all need to start creating new jobs on
>>> ci-infra.a.o and then , when you are happy, turn off your old builds on
>>> builds.a.o.
>>>
>>> There are currently 4 agents over there ready to take jobs, plus a
>>> floating
>>> agent which is shared amongst many masters (more to come). I will migrate
>>> away 2 more agents from builds.a.o to ci-builds.a.o every few days, and
>>> will keep an eye of load across both and adjust accordingly.
>>>
>>> If needed, create a ticket on INFRA jira for any issues that crop up, or
>>> email here on builds@a.o. there may be one or two plugins we need to
>>> install/tweak etc.
>>>
>>> We will be not using 'Views' at the top level, but rather we will take
>>> advantage of 'Folders Plus' - each project will get its own Folder and
>>> have
>>> authorisation access to create/edit jobs etc within that folder. I will
>>> create these folders as you ask for them to start with. This setup allows
>>> for credentials isolation amongst other benefits, including but not
>>> limited
>>> to exclusive agents (Controlled Agents) for your own use , should you
>>> have
>>> any project targeted donations of agents.
>>>
>>> As with other aspects of

Re: [IMPORTANT] - Migration to ci-builds.a.o

[Patrick Hunt]

On Thu, Jul 16, 2020 at 3:22 PM Patrick Hunt  wrote:

>
>
> On Thu, Jul 16, 2020 at 12:56 PM Enrico Olivelli 
> wrote:
>
>> FYI
>>
>
> Fun. I do notice it says "Hadoop and related projects have their own
> migration path to follow" - any insight on that? We are or are not lumped
> in? I would assume we are?
>
> This (eventual migration) came up a while back on the Hadoop PMC and I
> volunteered to try for us (ZK). I was never able to get it to work, I
> provided feedback to infra  but they never got back, as such we have a
> project here that's not working with some basic dependencies missing:
> https://ci-hadoop.apache.org/job/zookeeper-master-maven/
>
> That said, we can try again. Can we verify where ZK is supposed to land?
> Perhaps we can try to delete and recreate the POC job I created at that
> link to see if we can get it working?
>
>
I see another email thread on the list saying that we are part of said
"related projects". We are expected to move to http://ci-hadoop.apache.org/
within 4 weeks. Seems nodes are already being removed/migrated from the
"H#" pool.

Also this:

There are over 400 plugins on the current builds.apache.org - most of which
we don't need any more, or are replaced with different plugins on the new
system. I expect there may be some plugins we still need to install to get
you going again, which is why it is vitally important that you start
testing and migrating your jobs over *now*. You should all have auth.

Any questions, feel free to email the hadoop-migrati...@apache.org list if
you are one of the projects listed below. The rest of you, not listed, a
similar email to this one will be posted for you shortly on builds@a.o.


full details
https://lists.apache.org/thread.html/r21c9d40cdbf5461143dd7eb4ff48a200c2fd20c50e946884f61318fd%40%3Cbuilds.apache.org%3E

Patrick



> Patrick
>
>
>>
>> -- Forwarded message -
>> Da: Gavin McDonald 
>> Date: Gio 16 Lug 2020, 18:33
>> Subject: [IMPORTANT] - Migration to ci-builds.a.o
>> To: builds 
>>
>>
>> Hi All,
>>
>> This NOTICE is for everyone on builds.apache.org. We are migrating to a
>> new
>> Cloudbees based Client Master called https://ci-builds.apache.org. The
>> migrations of all jobs needs to be done before the switch off date of 15th
>> August 2020, so you have a maximum of 4 weeks.
>>
>> There is no tool or automated way of migrating your jobs, the
>> differences in the platforms, the plugins and the setup makes it
>> impossible
>> to do in a safe way. So, you all need to start creating new jobs on
>> ci-infra.a.o and then , when you are happy, turn off your old builds on
>> builds.a.o.
>>
>> There are currently 4 agents over there ready to take jobs, plus a
>> floating
>> agent which is shared amongst many masters (more to come). I will migrate
>> away 2 more agents from builds.a.o to ci-builds.a.o every few days, and
>> will keep an eye of load across both and adjust accordingly.
>>
>> If needed, create a ticket on INFRA jira for any issues that crop up, or
>> email here on builds@a.o. there may be one or two plugins we need to
>> install/tweak etc.
>>
>> We will be not using 'Views' at the top level, but rather we will take
>> advantage of 'Folders Plus' - each project will get its own Folder and
>> have
>> authorisation access to create/edit jobs etc within that folder. I will
>> create these folders as you ask for them to start with. This setup allows
>> for credentials isolation amongst other benefits, including but not
>> limited
>> to exclusive agents (Controlled Agents) for your own use , should you have
>> any project targeted donations of agents.
>>
>> As with other aspects of the ASF, projects can choose to just enable all
>> committers access to their folder, just ask.
>>
>> We will re-use builds.apache.org as a CNAME to ci-builds.a.o but will not
>> be setting up any forwarding rules or anything like that.
>>
>> So, please, get started *now *on this so you can be sure we are all
>> completed before the final cutoff date of 15th August 2020.
>>
>> Any questions - I expect a few (dozen :) ) - ask away and/or file INFRA
>> tickets.
>>
>> Hadoop and related projects have their own migration path to follow, same
>> cut off date, Cassandra, Beam, CouchDB have already migrated and are doing
>> very well in their new homes.
>>
>> Lets get going ...
>>
>> --
>>
>> *Gavin McDonald*
>> Systems Administrator
>> ASF Infrastructure Team
>>
>

Re: [IMPORTANT] - Migration to ci-builds.a.o

[Patrick Hunt]

On Thu, Jul 16, 2020 at 12:56 PM Enrico Olivelli 
wrote:

> FYI
>

Fun. I do notice it says "Hadoop and related projects have their own
migration path to follow" - any insight on that? We are or are not lumped
in? I would assume we are?

This (eventual migration) came up a while back on the Hadoop PMC and I
volunteered to try for us (ZK). I was never able to get it to work, I
provided feedback to infra  but they never got back, as such we have a
project here that's not working with some basic dependencies missing:
https://ci-hadoop.apache.org/job/zookeeper-master-maven/

That said, we can try again. Can we verify where ZK is supposed to land?
Perhaps we can try to delete and recreate the POC job I created at that
link to see if we can get it working?

Patrick


>
> -- Forwarded message -
> Da: Gavin McDonald 
> Date: Gio 16 Lug 2020, 18:33
> Subject: [IMPORTANT] - Migration to ci-builds.a.o
> To: builds 
>
>
> Hi All,
>
> This NOTICE is for everyone on builds.apache.org. We are migrating to a
> new
> Cloudbees based Client Master called https://ci-builds.apache.org. The
> migrations of all jobs needs to be done before the switch off date of 15th
> August 2020, so you have a maximum of 4 weeks.
>
> There is no tool or automated way of migrating your jobs, the
> differences in the platforms, the plugins and the setup makes it impossible
> to do in a safe way. So, you all need to start creating new jobs on
> ci-infra.a.o and then , when you are happy, turn off your old builds on
> builds.a.o.
>
> There are currently 4 agents over there ready to take jobs, plus a floating
> agent which is shared amongst many masters (more to come). I will migrate
> away 2 more agents from builds.a.o to ci-builds.a.o every few days, and
> will keep an eye of load across both and adjust accordingly.
>
> If needed, create a ticket on INFRA jira for any issues that crop up, or
> email here on builds@a.o. there may be one or two plugins we need to
> install/tweak etc.
>
> We will be not using 'Views' at the top level, but rather we will take
> advantage of 'Folders Plus' - each project will get its own Folder and have
> authorisation access to create/edit jobs etc within that folder. I will
> create these folders as you ask for them to start with. This setup allows
> for credentials isolation amongst other benefits, including but not limited
> to exclusive agents (Controlled Agents) for your own use , should you have
> any project targeted donations of agents.
>
> As with other aspects of the ASF, projects can choose to just enable all
> committers access to their folder, just ask.
>
> We will re-use builds.apache.org as a CNAME to ci-builds.a.o but will not
> be setting up any forwarding rules or anything like that.
>
> So, please, get started *now *on this so you can be sure we are all
> completed before the final cutoff date of 15th August 2020.
>
> Any questions - I expect a few (dozen :) ) - ask away and/or file INFRA
> tickets.
>
> Hadoop and related projects have their own migration path to follow, same
> cut off date, Cassandra, Beam, CouchDB have already migrated and are doing
> very well in their new homes.
>
> Lets get going ...
>
> --
>
> *Gavin McDonald*
> Systems Administrator
> ASF Infrastructure Team
>

Re: An official API for starting ZooKeeper from a Java program

[Patrick Hunt]

On Thu, Jun 25, 2020 at 1:45 PM Enrico Olivelli  wrote:

> Il Gio 25 Giu 2020, 22:13 Patrick Hunt  ha scritto:
>
> > On Thu, Jun 25, 2020 at 3:20 AM Enrico Olivelli 
> > wrote:
> >
> > > Hi,
> > > we recently got into ZOOKEEPER-3803
> FileTxnSnapLog.fastForwardFromEdits()
> > > throws NPE if TestingServer is started from another thread (see [1])
> > > and I have similar cases in other non OS products that run ZooKeeper
> from
> > > Java.
> > >
> > > The case of ZOOKEEPER-3803 is for Curator TestingServer, and here we
> are
> > > talking about running a ZK server for testing purposes.
> > > But I have other usecases in which the ZK server must be launched, for
> > > production usage, from a Java based bootstrap launcher.
> > >
> > > We are now officially supporting our binary package distribution that
> > runs
> > > ZooKeeper from a bash script and the bash script is coupled with
> > > ZooKeeperMain and QuorumPeerMain.
> > >
> > > In my opinion we should provide a well known and supported API, better
> > than
> > > using directly those two classes, to run ZooKeeper safely in
> production,
> > > but launched from Java.
> > >
> > > I am not here supporting or suggesting the idea of running ZooKeeper
> > inside
> > > the same process of a client application,
> > > but only to provide a clear and stable API to start/stop and do minimal
> > > health checks to a ZooKeeper peer.
> > >
> > > I will be happy to work on it
> > >
> > > Thoughts ?
> > >
> >
> > Sounds reasonable to me. That said I'm not sure I follow you entirely.
> > Isn't that the goal of the two Main classes? Is it that they are
> deficient
> > (and can therefore be fixed to address) or they are serving a different
> > role entirely from what you intend to provide?
> >
>
> Those classes do not have a clear interface.
>
> We need at least
> - init(configuration)
> - start()
> - stop()
> - boolean isAlive()
>
>
Makes sense to me. Can we refactor the Main classes to include/use that and
also doc/pub it as an public/enduser interface? Possible user/consumer
visible regressions may make that a bad idea? Or do you want to have just
one interface that supports any cluster type, distributed or non. I could
see both approaches working.

Patrick


> Optionally we can provide some utility to get the endpoint address.
>
> Very similar to Curator TestingServer but:
> - for production
> - maintained by Zookeeper project
>
>
> Enrico
>
>
>
> > Patrick
> >
> >
> > >
> > > Enrico
> > >
> > >
> > > [1] https://issues.apache.org/jira/browse/ZOOKEEPER-3803
> > >
> >
>

Re: An official API for starting ZooKeeper from a Java program

[Patrick Hunt]

On Thu, Jun 25, 2020 at 3:20 AM Enrico Olivelli  wrote:

> Hi,
> we recently got into ZOOKEEPER-3803 FileTxnSnapLog.fastForwardFromEdits()
> throws NPE if TestingServer is started from another thread (see [1])
> and I have similar cases in other non OS products that run ZooKeeper from
> Java.
>
> The case of ZOOKEEPER-3803 is for Curator TestingServer, and here we are
> talking about running a ZK server for testing purposes.
> But I have other usecases in which the ZK server must be launched, for
> production usage, from a Java based bootstrap launcher.
>
> We are now officially supporting our binary package distribution that runs
> ZooKeeper from a bash script and the bash script is coupled with
> ZooKeeperMain and QuorumPeerMain.
>
> In my opinion we should provide a well known and supported API, better than
> using directly those two classes, to run ZooKeeper safely in production,
> but launched from Java.
>
> I am not here supporting or suggesting the idea of running ZooKeeper inside
> the same process of a client application,
> but only to provide a clear and stable API to start/stop and do minimal
> health checks to a ZooKeeper peer.
>
> I will be happy to work on it
>
> Thoughts ?
>

Sounds reasonable to me. That said I'm not sure I follow you entirely.
Isn't that the goal of the two Main classes? Is it that they are deficient
(and can therefore be fixed to address) or they are serving a different
role entirely from what you intend to provide?

Patrick


>
> Enrico
>
>
> [1] https://issues.apache.org/jira/browse/ZOOKEEPER-3803
>

Re: [VOTE] Apache ZooKeeper release 3.5.8 candidate 0

[Patrick Hunt]

+1. xsum/sig verified. rat ran clean. Compiled and ran various manual tests
successfully.

Patrick

On Wed, May 6, 2020 at 6:03 AM Andor Molnar  wrote:

> +1 (binding)
>
> - release notes looks good,
> - documentation looks good,
> - licence files look good,
> - run java unit tests on Java 8 & 11,
> - run C unit tests on Ubuntu 19.10
> - run rat, spotbugs, checkstyle checks
> - verified 5-node cluster with zk-latencies.py, zk-smoketest.py,
> - verified TTL nodes feature
>
> Nice rc0, thanks Mate!
>
> Andor
>
>
>
> > On 2020. May 5., at 13:33, Norbert Kalmar 
> wrote:
> >
> > Great, thanks Máté!
> >
> > +1 (non-binding)
> > Did my usual build and testing, verified signature (new public key in
> > KEYS), compared src release with git repository, checked license files -
> > all looks good to me.
> > I'm rooting for an RC0 release! :)
> >
> > Regards,
> > Norbert
> >
> > On Mon, May 4, 2020 at 6:22 PM Szalay-Bekő Máté <
> szalay.beko.m...@gmail.com>
> > wrote:
> >
> >> This is a release candidate for 3.5.8, a bugfix release
> >> introducing bugfixes and improvements including:
> >> - compatibility with applications built against earlier 3.5 client
> >> libraries (restored a few non public APIs)
> >> - CVE fixes (update Netty to 4.1.48.Final and Jackson-databind to
> 2.10.3)
> >> - Fix several ZooKeeper leader-election bugs
> >> - Make sources buildable with JDK14
> >>
> >> The full release notes is available at:
> >>
> >>
> >>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310801=12346950
> >>
> >> *** Please download, test and vote by May 10th 2020, 23:59 UTC+0. ***
> >>
> >> Source files:
> >> https://people.apache.org/~symat/zookeeper-3.5.8-rc0/
> >>
> >> Maven staging repo:
> >>
> https://repository.apache.org/content/repositories/orgapachezookeeper-1059/
> >>
> >> The release candidate tag in git to be voted upon: release-3.5.8-rc0
> >> https://github.com/apache/zookeeper/tree/release-3.5.8-rc0
> >>
> >> ZooKeeper's KEYS file containing PGP keys we use to sign the release:
> >> https://www.apache.org/dist/zookeeper/KEYS
> >>
> >> The staging version of the website is:
> >> https://people.apache.org/~symat/zookeeper-3.5.8-rc0/webpage/
> >>
> >> Should we release this candidate?
> >>
> >> Mate Szalay-Beko
> >>
>
>

Re: [VOTE] Apache ZooKeeper release 3.6.1 candidate 1

[Patrick Hunt]

On Thu, Apr 23, 2020 at 2:20 AM Enrico Olivelli  wrote:

> Il giorno mer 22 apr 2020 alle ore 16:14 Norbert Kalmar
>  ha scritto:
>
> > Only thing I found is that the bin has netty-codec-4.1.49 license file
> > while the jar included is 4.1.48. I think the license version has a typo
> in
> > the bugfix version. Not sure if it's a showstopper.
> >
>
> I don't consider it a showstopper.
>
> Do you have time to send a fix please ?
> This way if we have to roll out a new RC we can pick it up.
>

Sorry - my bad on that one.

I submitted a simple PR to fix it if you want to pull into the other
branches or have it ready if a respin is necessary:
https://github.com/apache/zookeeper/pull/1333

Patrick


>
> We could anyhow update to 4.1.49.Final
> https://netty.io/news/2020/04/22/4-1-49-Final.html
>
> Enrico
>
>
> >
> > Otherwise LGTM:
> > - Signatures OK
> > - Compared to git and 3.6.0
> > - Compiled both on Mac (without C client) and Linux (with C client)
> > - Run tests (from src) and server (from src and bin tarball), connect
> with
> > client and run simple commands
> > - Spotbugs and checkstyle passed
> >
> > Regards,
> > Norbert
> >
> > On Wed, Apr 22, 2020 at 3:50 PM Szalay-Bekő Máté <
> > szalay.beko.m...@gmail.com>
> > wrote:
> >
> > > +1 (non-binding)
> > >
> > > - I built the source code (-Pfull-build) on Ubuntu 18.04.3 using
> OpenJDK
> > > 8u242 and maven 3.6.0.
> > > - all the unit tests passed (both Java and C-client).
> > > - I also built and executed unit tests for zkpython
> > > - checkstyle and spotbugs passed
> > > - apache-rat passed
> > > - fatjar built
> > > - I executed a quick rolling-upgrade test from 3.5.7 to 3.6.1. (using
> > > https://github.com/symat/zk-rolling-upgrade-test)
> > >
> > > On Tue, Apr 21, 2020 at 5:20 PM Enrico Olivelli 
> > > wrote:
> > >
> > > > This is a release candidate for 3.6.1.
> > > >
> > > > It is a bugfix release and it introduces a few bugfixes and new
> > features
> > > in
> > > > these areas:
> > > > - compatibility with applications built against 3.5 client libraries
> > > > (restored a few non public APIs)
> > > > - update Netty to 4.1.48.Final
> > > > - ability to pass configuration as file in zkCli for TLS config
> > > > - Add setKeepAlive support for NIOServerCnxn
> > > > - Fix server side request throttling
> > > >
> > > > The full release notes is available at:
> > > >
> > > >
> > > >
> > >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310801=12346764
> > > >
> > > > *** Please download, test and vote by April 14th 2020, 23:59 UTC+0.
> ***
> > > >
> > > > Source files:
> > > > https://people.apache.org/~eolivelli/zookeeper-3.6.1-candidate-1/
> > > >
> > > > Maven staging repo:
> > > >
> > >
> >
> https://repository.apache.org/content/repositories/orgapachezookeeper-1058/
> > > >
> > > > The release candidate tag in git to be voted upon: release-3.6.1-1
> > > > https://github.com/apache/zookeeper/tree/release-3.6.1-1
> > > >
> > > > ZooKeeper's KEYS file containing PGP keys we use to sign the release:
> > > > https://www.apache.org/dist/zookeeper/KEYS
> > > >
> > > > The staging version of the website is:
> > > >
> > >
> >
> https://people.apache.org/~eolivelli/zookeeper-3.6.1-candidate-1/website/
> > > >
> > > > Should we release this candidate?
> > > >
> > > > Enrico Olivelli
> > > >
> > >
> >
>

Re: [VOTE] Apache ZooKeeper release 3.6.1 candidate 1

[Patrick Hunt]

+1. xsum/sig verified. compiled fine and I was able to run some manual test
successfully. lgtm

Patrick

On Thu, Apr 23, 2020 at 2:16 PM Christopher  wrote:

> +1 (non-binding); overall, looks great!
>
> Good:
> * Source tarball matches tag (git sha1 at
> 104dcb3e3fb464b30c5186d229e00af9f332524b)
> * Release tag includes all commits from branch-3.6 (at
> e64a74fabafeb3b20109014149beb3ebd6a48be7)
> * SHA512 checksums match tarballs:
>
> 1c5cb4d9886fae41bf244a446dd874b73c0fff7a5fc2dda4305041964420cde21e59b388dfd2551464a46bb6918d9d3c3c01ebe68fdbe782074ee360aa830c7d
>  apache-zookeeper-3.6.1-bin.tar.gz
>
> 0c6740a14bcc6fac56ffa1d4d18dc5397d454d46ffb42a3f6a784a9d8bf5083b460d6f8a5f65718e83973f65683a420a4614de11710e21cdf288d586d3c5203d
>  apache-zookeeper-3.6.1.tar.gz
> * GPG signatures match (signed using key
> BBE7232D7991050B54C8EA0ADC08637CA615D22C, 2048/rsa, with recommended
> SHA512 digest algo) and key is present in KEYS
> * Was able to reproduce creation of the binary tarball (comparison of
> file listing only) using OpenJDK14 (only diffs were expected javadoc
> differences) using `mvn clean package -Pfull-build`
> * I tested the convenience binary with Apache Accumulo 2.0.0 and basic
> functionality is all there
>
> Of minor concern:
> * Seeing lots of warnings in the ZK logs about bad reads from the
> client connection when there hasn't been any other indication of a
> failure anywhere. Possibly a mishandled connection in client code, but
> not sure (certainly not serious enough to block a release, since
> everything seems to be functioning fine otherwise):
> 2020-04-23 17:01:48,414 [myid:] - WARN
> [NIOWorkerThread-3:NIOServerCnxn@364] - Unexpected exception
> EndOfStreamException: Unable to read additional data from client, it
> probably closed the socket: address = /127.0.0.1:35702, session =
> 0x100028c09f1000e
>   at
> org.apache.zookeeper.server.NIOServerCnxn.handleFailedRead(NIOServerCnxn.java:163)
>   at org.apache.zookeeper.server.NIOServerCnxn.doIO(NIOServerCnxn.java:326)
>   at
> org.apache.zookeeper.server.NIOServerCnxnFactory$IOWorkRequest.doWork(NIOServerCnxnFactory.java:522)
>   at
> org.apache.zookeeper.server.WorkerService$ScheduledWorkRequest.run(WorkerService.java:154)
>   at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
>   at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
>   at java.base/java.lang.Thread.run(Thread.java:832)
>
> On Thu, Apr 23, 2020 at 6:00 AM Norbert Kalmar
>  wrote:
> >
> > Sure, I'll do the update today.
> > +1 (non-binding) from me (see my testing in my previous mail)
> >
> > Thanks Enrico!
> >
> > On Thu, Apr 23, 2020 at 11:20 AM Enrico Olivelli 
> > wrote:
> >
> > > Il giorno mer 22 apr 2020 alle ore 16:14 Norbert Kalmar
> > >  ha scritto:
> > >
> > > > Only thing I found is that the bin has netty-codec-4.1.49 license
> file
> > > > while the jar included is 4.1.48. I think the license version has a
> typo
> > > in
> > > > the bugfix version. Not sure if it's a showstopper.
> > > >
> > >
> > > I don't consider it a showstopper.
> > >
> > > Do you have time to send a fix please ?
> > > This way if we have to roll out a new RC we can pick it up.
> > >
> > > We could anyhow update to 4.1.49.Final
> > > https://netty.io/news/2020/04/22/4-1-49-Final.html
> > >
> > > Enrico
> > >
> > >
> > > >
> > > > Otherwise LGTM:
> > > > - Signatures OK
> > > > - Compared to git and 3.6.0
> > > > - Compiled both on Mac (without C client) and Linux (with C client)
> > > > - Run tests (from src) and server (from src and bin tarball), connect
> > > with
> > > > client and run simple commands
> > > > - Spotbugs and checkstyle passed
> > > >
> > > > Regards,
> > > > Norbert
> > > >
> > > > On Wed, Apr 22, 2020 at 3:50 PM Szalay-Bekő Máté <
> > > > szalay.beko.m...@gmail.com>
> > > > wrote:
> > > >
> > > > > +1 (non-binding)
> > > > >
> > > > > - I built the source code (-Pfull-build) on Ubuntu 18.04.3 using
> > > OpenJDK
> > > > > 8u242 and maven 3.6.0.
> > > > > - all the unit tests passed (both Java and C-client).
> > > > > - I also built and executed unit tests for zkpython
> > > > > - checkstyle and spotbugs passed
> > > > > - apache-rat passed
> > > > > - fatjar built
> > > > > - I executed a quick rolling-upgrade test from 3.5.7 to 3.6.1.
> (using
> > > > > https://github.com/symat/zk-rolling-upgrade-test)
> > > > >
> > > > > On Tue, Apr 21, 2020 at 5:20 PM Enrico Olivelli <
> eolive...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > This is a release candidate for 3.6.1.
> > > > > >
> > > > > > It is a bugfix release and it introduces a few bugfixes and new
> > > > features
> > > > > in
> > > > > > these areas:
> > > > > > - compatibility with applications built against 3.5 client
> libraries
> > > > > > (restored a few non public APIs)
> > > > > > - update Netty to 4.1.48.Final
> > > > > > - ability to pass configuration as file in zkCli for TLS config
> > > > > > - Add setKeepAlive 

Re: Branch-36 is broken - fatjar - WAS Re: [VOTE] Apache ZooKeeper release 3.6.1 candidate 0

[Patrick Hunt]

sg. Merged onto both. Thanks all!

Patrick

On Sat, Apr 18, 2020 at 10:08 AM Enrico Olivelli 
wrote:

> Patrick,
> Yes only to be merged to branch3.6 and release-3.6.1
>
> Thanks
> Enrico
>
> Il Sab 18 Apr 2020, 18:25 Christopher  ha scritto:
>
> > 3.6.1 and the 3.6 branch. PR #1314 has been updated to address the same
> > issues and more for master/3.7
> >
> > On Sat, Apr 18, 2020, 11:47 Patrick Hunt  wrote:
> >
> > > I can take a look. Does this need to go into just 3.6.1 or other
> branches
> > > as well? The JIRA says just 3.6.1,is that right?
> > >
> > > Patrick
> > >
> > > On Sat, Apr 18, 2020 at 6:02 AM Enrico Olivelli 
> > > wrote:
> > >
> > > > PR is finally ready
> > > > https://github.com/apache/zookeeper/pull/1323
> > > >
> > > > Looking for some committer to help me merge that patch
> > > >
> > > > Enrico
> > > >
> > > > Il giorno sab 18 apr 2020 alle ore 12:42 Enrico Olivelli <
> > > > eolive...@gmail.com> ha scritto:
> > > >
> > > > > Thank you Christopher
> > > > >
> > > > > We are iterating over #1323.
> > > > > I think we can finish the work today
> > > > >
> > > > > Enrico
> > > > >
> > > > > Il giorno sab 18 apr 2020 alle ore 09:39 Christopher <
> > > > ctubb...@apache.org>
> > > > > ha scritto:
> > > > >
> > > > >> +1 to that approach. I reviewed and made a suggestion on the PR at
> > > > >> https://github.com/apache/zookeeper/pull/1323
> > > > >>
> > > > >> On Sat, Apr 18, 2020 at 3:16 AM Enrico Olivelli <
> > eolive...@gmail.com>
> > > > >> wrote:
> > > > >> >
> > > > >> > This is my patch.
> > > > >> > Basically it adds back the fatjar module to the full-build
> profile
> > > > >> > this way we have only one profile that actually does the "full
> > > build"
> > > > =
> > > > >> all
> > > > >> > maven modules
> > > > >> >
> > > > >> > I feel this is a very clear way for users,
> > > > >> > mvn clean package -Pfull-build
> > > > >> > this builds the whole repository
> > > > >> >
> > > > >> > Enrico
> > > > >> >
> > > > >> > Il giorno sab 18 apr 2020 alle ore 08:28 Enrico Olivelli <
> > > > >> > eolive...@gmail.com> ha scritto:
> > > > >> >
> > > > >> > > Hi,
> > > > >> > > Branch-3.6 is broken due to the fatjat stuff
> > > > >> > >
> > > > >> > > [eolivelli@localhost zookeeper]$ mvn clean
> -Pfull-build,fatjar
> > > > >> > > [INFO] Scanning for projects...
> > > > >> > > [ERROR] [ERROR] Project
> > > > >> > > 'org.apache.zookeeper:zookeeper-contrib-fatjar:3.6.1-SNAPSHOT'
> > is
> > > > >> > > duplicated in the reactor @
> > > > >> > > [ERROR] Project
> > > > >> > > 'org.apache.zookeeper:zookeeper-contrib-fatjar:3.6.1-SNAPSHOT'
> > is
> > > > >> > > duplicated in the reactor -> [Help 1]
> > > > >> > > [ERROR]
> > > > >> > >
> > > > >> > >
> > > > >> > > I am preparing a fix
> > > > >> > >
> > > > >> > > Enrico
> > > > >> > >
> > > > >> > > Il giorno sab 18 apr 2020 alle ore 07:08 Enrico Olivelli <
> > > > >> > > eolive...@gmail.com> ha scritto:
> > > > >> > >
> > > > >> > >>
> > > > >> > >>
> > > > >> > >> Il Ven 17 Apr 2020, 08:50 Enrico Olivelli <
> eolive...@gmail.com
> > >
> > > ha
> > > > >> > >> scritto:
> > > > >> > >>
> > > > >> > >>> Thank you Christopher !
> > > > >> > >>>
> > > > >> > >>> I have manually fixed the pom.xml files in branch-3.6 and
> > > > >> release-3.6.1
> > > > >> > >>

Re: Branch-36 is broken - fatjar - WAS Re: [VOTE] Apache ZooKeeper release 3.6.1 candidate 0

[Patrick Hunt]

em in isolation. It
> >> might
> >> > >>>> just be because surefire forkCount is 8, and my laptop is slow.
> Not
> >> > >>>> sure. Would need further investigation. I'm not worried about
> this,
> >> > >>>> though, and wouldn't consider it a blocker... but I might open
> up a
> >> > >>>> JIRA if I see it again and can capture a stack trace or logs.
> >> > >>>>
> >> > >>>> >
> >> > >>>> >
> >> > >>>> > > * release did not appear to be prepared using the
> >> > >>>> maven-release-plugin
> >> > >>>> > > from the branch-3.6, but from a different (local?) branch;
> this
> >> > >>>> > > resulted in a few minor issues
> >> > >>>> > >
> >> > >>>> >
> >> > >>>> > yes, the tradition here is to create a work branch
> release-3.6.1
> >> and
> >> > >>>> then
> >> > >>>> > it up to the Release Manager to handle the status of that
> branch
> >> > >>>> > it is not strictly the Maven way, but we discussed that
> approach
> >> while
> >> > >>>> > releasing 3.6.0, that was the first release with the
> >> > >>>> maven-release-plugin
> >> > >>>> >
> >> > >>>> > this is our guide
> >> > >>>> >
> >> > >>>>
> >>
> https://cwiki.apache.org/confluence/display/ZOOKEEPER/HowToRelease+using+maven+release+plugin
> >> > >>>> >
> >> > >>>>
> >> > >>>> I recommend using the false and
> >> > >>>> true in maven-release-plugin (for
> >> > >>>> release:prepare and release:perform) and using '3.6.1' instead as
> >> the
> >> > >>>> release version. Improving the build and release process is
> >> something
> >> > >>>> I have a lot of experience with, so I may look into this more
> >> later.
> >> > >>>> Much of the details on this page can be replaced with an
> >> interactive
> >> > >>>> helper script, as I've done for both Accumulo and Fluo already.
> >> > >>>>
> >> > >>>> >
> >> > >>>> >
> >> > >>>> > >   ** git commit hashes don't match up with the branch
> (commits
> >> > >>>> appear
> >> > >>>> > > cherry-picked and exclude ZOOKEEPER-3726, mentioned above)
> >> > >>>> > >
> >> > >>>> > This is not a big deal, it is important that we have the good
> tag
> >> > >>>> > (release-3.6.1-0)
> >> > >>>>
> >> > >>>> Agreed. This is minor. It was just confusing. Missing commits in
> >> the
> >> > >>>> release can be included in future releases. A bigger problem
> would
> >> be
> >> > >>>> if the commits only existed in the tag and not in the maintenance
> >> > >>>> branch, because that might mean a regression in the next release.
> >> The
> >> > >>>> main concern I had here was that the JIRA issue was marked as
> fixed
> >> > >>>> for this release, but it wasn't included.
> >> > >>>>
> >> > >>>> >
> >> > >>>> >   ** the content of the pom.xml's   includes `-0`,
> >> which
> >> > >>>> > > will not be the final tag name if the artifacts are approved
> >> for
> >> > >>>> > > release (actual tag should be "release-3.6.1")
> >> > >>>> > >
> >> > >>>> >
> >> > >>>> > I agree, this is not nice. We can improve it.
> >> > >>>> > Not a blocker for this release
> >> > >>>> >
> >> > >>>> >
> >> > >>>> > > * fatjar profile is broken because fatjar module and
> >> zookeeper-it
> >> > >>>> > > module specify wrong parent pom version (bad cherry-pick from
> >> > >>>> > > master/3.7.0-SNAPSHOT?)
> >

Re: [VOTE] Apache ZooKeeper release 3.6.1 candidate 0

[Patrick Hunt]

+1 - xsum/sig validated, rat ran clean, I was able to compile and ran some
manual tests on varying cluster sizes.

Patrick

On Wed, Apr 15, 2020 at 11:44 AM Enrico Olivelli 
wrote:

> This is a release candidate for 3.6.1.
>
> It is a bugfix release and it introduces a few bugfixes and new features in
> these areas:
> - compatibility with applications built against 3.5 client libraries
> (restored a few non public APIs)
> - update Netty to 4.1.48.Final
> - ability to pass configuration as file in zkCli for TLS config
> - Add setKeepAlive support for NIOServerCnxn
> - Fix server side request throttling
>
> The full release notes is available at:
>
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310801=12346764
>
> *** Please download, test and vote by April 19th 2020, 23:59 UTC+0. ***
>
> Source files:
> https://people.apache.org/~eolivelli/zookeeper-3.6.1-candidate-0/
>
> Maven staging repo:
> https://repository.apache.org/content/repositories/orgapachezookeeper-1056
>
> The release candidate tag in git to be voted upon: release-3.6.1-0
> https://github.com/apache/zookeeper/tree/release-3.6.0-1
>
> ZooKeeper's KEYS file containing PGP keys we use to sign the release:
> https://www.apache.org/dist/zookeeper/KEYS
>
> The staging version of the website is:
> https://people.apache.org/~eolivelli/zookeeper-3.6.1-candidate-0/website/
>
> Should we release this candidate?
>
> Enrico Olivelli
>

Re: No tag for 3.6.0?

[Patrick Hunt]

No worries at all. That does seem odd, perhaps it's related to having
multiple remotes?

Regards,

Patrick

On Tue, Apr 14, 2020 at 7:38 PM Christopher  wrote:

> This was a weird client-side error with git... not sure why it wasn't
> working, but `git remote update` wasn't fetching tags for some reason.
> I did `git fetch --tags`, then `git tag --delete $(git tag)`, then
> `git remote update` and it worked.
> So weird. Sorry for the noise.
>
> On Tue, Apr 14, 2020 at 9:44 PM Patrick Hunt  wrote:
> >
> > Christopher - I believe it's release-3.6.0 - I have it from either gh or
> > apache gitbox, eg:
> > https://github.com/apache/zookeeper/tree/release-3.6.0
> >
> > Patrick
> >
> > On Tue, Apr 14, 2020 at 6:26 PM Christopher  wrote:
> >
> > > Hi ZK Devs,
> > >
> > > I don't see a tag for 3.6.0 in git. Is there one available that hasn't
> > > been pushed?
> > >
> > > Thanks,
> > > Christopher
> > >
>

Re: No tag for 3.6.0?

[Patrick Hunt]

Christopher - I believe it's release-3.6.0 - I have it from either gh or
apache gitbox, eg:
https://github.com/apache/zookeeper/tree/release-3.6.0

Patrick

On Tue, Apr 14, 2020 at 6:26 PM Christopher  wrote:

> Hi ZK Devs,
>
> I don't see a tag for 3.6.0 in git. Is there one available that hasn't
> been pushed?
>
> Thanks,
> Christopher
>

Re: Cutting 3.6.1 HEADS UP !

[Patrick Hunt]

I notice that the owasp check is failing due to netty:
https://issues.apache.org/jira/browse/ZOOKEEPER-3794
doesn't seem super critical but might be worth knocking off if we're still
not ready to create an RC:

[ERROR] Failed to execute goal
org.owasp:dependency-check-maven:5.3.0:check (default-cli) on project
zookeeper:[ERROR] [ERROR] One or more dependencies were identified
with vulnerabilities that have a CVSS score greater than or equal to
'0.0':[ERROR] [ERROR] netty-handler-4.1.45.Final.jar:
CVE-2020-11612[ERROR] netty-common-4.1.45.Final.jar:
CVE-2020-11612[ERROR] netty-buffer-4.1.45.Final.jar:
CVE-2020-11612[ERROR] netty-transport-4.1.45.Final.jar:
CVE-2020-11612[ERROR] netty-resolver-4.1.45.Final.jar:
CVE-2020-11612[ERROR] netty-codec-4.1.45.Final.jar:
CVE-2020-11612[ERROR] netty-transport-native-epoll-4.1.45.Final.jar:
CVE-2020-11612[ERROR]
netty-transport-native-unix-common-4.1.45.Final.jar: CVE-2020-11612

Patrick


On Sun, Apr 12, 2020 at 9:39 AM Enrico Olivelli  wrote:

> Christopher
> Maybe with your commit a93ff0fe631d1c96ee056a79e3c16535ab33c794 we have
> broken the source release tarball.
>
> It looks like we are not passing the git sha to VerGen or something like
> that
>
> Just download the source tarball from my staging area and try.
>
> Do you have time to help fixing this issue?
> Otherwise I can try to fix it or simply git revert that commit as it is not
> a blocker issue for the release
>
> Cheers
> Enrico
>
> Il giorno dom 12 apr 2020 alle ore 14:58 Enrico Olivelli <
> eolive...@gmail.com> ha scritto:
>
> > Christopher
> > This is my staging area
> > https://people.apache.org/~eolivelli/zookeeper-3.6.1-candidate-0/
> >
> > this is not the VOTE thread, I will send the official VOTE email once I
> > feel the staging area is valid
> > this is the Maven Repository
> >
> https://repository.apache.org/content/repositories/orgapachezookeeper-1054
> >
> > I will hopefully send the VOTE email tomorrow
> >
> > Please send me comments directly and not to the ML, in order not to
> create
> > confusion
> >
> > Thank in advance
> > Enrico
> >
> > Il giorno ven 10 apr 2020 alle ore 04:35 Christopher <
> ctubb...@apache.org>
> > ha scritto:
> >
> >> I don't anticipate any issues, but I can test Accumulo with the
> >> release candidate when it's ready.
> >> Do you already have the binary tarball built and uploaded somewhere?
> >>
> >> On Thu, Apr 9, 2020 at 2:43 PM Enrico Olivelli 
> >> wrote:
> >> >
> >> > Il Gio 9 Apr 2020, 20:33 Norbert Kalmar  >
> >> ha
> >> > scritto:
> >> >
> >> > > Hi Enrico,
> >> > >
> >> > > Thanks for driving this!
> >> > >
> >> > > I managed to build HBase with ZooKeeper 3.5.7 having cherry-picked
> the
> >> > > getRevision() patch. I know it's not 3.6.x, but I found the problem
> >> with
> >> > > this 3.5.7 and fixed it according to this on 3.6 as well. So it
> >> should be
> >> > > fine now.
> >> > >
> >> >
> >> > Thank you
> >> >
> >> > Enrico
> >> >
> >> > >
> >> > > - Norbert
> >> > >
> >> > > On Thu, Apr 9, 2020 at 11:00 AM Enrico Olivelli <
> eolive...@gmail.com>
> >> > > wrote:
> >> > >
> >> > > > Hi,
> >> > > > I am going to prepare a release candidate for ZooKeeper 3.6.1.
> >> > > >
> >> > > > There is no JIRA issue with fixVersion = 3.6.1 that is unresolved.
> >> > > >
> >> > > > I have tested a few projects that had compatibility issues and
> they
> >> are
> >> > > > resolved (like Apache BookKeeper and other non OS projects in my
> >> > > company).
> >> > > >
> >> > > > I remember that Norbert pointed a problem with HBase client, that
> >> uses
> >> > > > getRevision() method, it would be super great to have some
> feedback
> >> of
> >> > > > compatibility of HBase with 3.6.1 client.
> >> > > >
> >> > > > I have deployed the snapshots to snapshots.apache.org, this way
> >> you can
> >> > > > easily test your project in CI, even on Travis.
> >> > > >
> >> > > > I have created the work branch for release
> >> > > > https://github.com/apache/zookeeper/tree/release-3.6.1
> >> > > >
> >> > > > Please ping me if you have any questions or concerns or you need
> to
> >> add
> >> > > new
> >> > > > items.
> >> > > >
> >> > > > I will start the release procedure once I have self validated the
> >> status
> >> > > of
> >> > > > that branch
> >> > > >
> >> > > > Stay tuned
> >> > > >
> >> > > > Enrico
> >> > > >
> >> > >
> >>
> >
>

Re: Contribs as separate git repos

[Patrick Hunt]

On Thu, Apr 9, 2020 at 4:21 AM Enrico Olivelli  wrote:

> Answers inline
>
> Il Gio 9 Apr 2020, 05:28 Christopher  ha scritto:
>
> > On Wed, Apr 8, 2020 at 2:01 PM Damien Diederen  >
> > wrote:
> > >
> > >
> > > Hi Christopher,
> > >
> > > > I am just curious if anybody has thought about, or perhaps discussed,
> > > > the idea that the projects in the zookeeper-contrib folder should be
> > > > in their own separate git repos?
> > >
> > > We were discussing this a few days ago:
> > >
> > >
> https://github.com/apache/zookeeper/pull/1068#issuecomment-607160440
> > >
> > > My (only) concern was that I wouldn't want to see contribs *even more*
> > > abandoned than they are now:
> >
>
> Yep
> But I'd no one contributes to them it is better to drop them from master.
>
> >
> > That's a fair concern. It is always sad to see code get abandoned.
> > Moving them out won't solve a "lack of interest" problem. Apache is
> > composed of volunteers... and sometimes interest in a project withers.
> > But, it can help organize whatever remaining (or future) interest
> > there is by decoupling the contrib and presenting it as a smaller,
> > more focused project.
> >
> > >
> > > >> While I wouldn't be opposed to moving "unpopular" bindings to their
> > > >> own repository, it would probably only make sense to do so if merge
> > > >> rules are somewhat relaxed—as I suspect it would otherwise be even
> > > >> more difficult to meet the "two PMC approvals" threshold.
> >
>
> We need two committers +1, not strictly PMCs.
> This is setting the quality of our product,
> everything we deliver must have the same level.
>
> Personally I find good to keep the python binding, and maybe to make it a
> sibling of the C client inside the zookeeper-clients module.
> I saw recent activity on fat-jar.
>
>
Sounds right to me re python. I've seen it used and also a good way to
validate the c client.

On the flip side there is an established AL2 python zk client which is
active:
https://github.com/python-zk/kazoo

Patrick



> Other modules seem abandoned so no value for me in keeping them.
>
> Enrico
>
>
>
>
> > That already seems like a pretty high bar to me, even for the main
> > project. It's definitely more strict than the other Apache projects
> > I've contributed to. I can see how it could be a problem if there is
> > diminished interest in these contribs. The PMC would have to decide
> > how they want to approach that.
> >
> > >
> > > But whatever the outcome is:
> > >
> > > >> In any case: I am willing to be automatically marked as a reviewer
> > > >> for (at least) the zkperl and zkpython "contribs." Do we have such a
> > > >> mechanism? I see that GitHub implements some such mechanisms (1, 2),
> > > >> but I'm not sure how applicable they are to our case. Never hesitate
> > > >> to ping me manually!
> > >
> > > > I'm asking because I've been looking a lot at the build, trying to
> > > > find ways to improve it, and I think this might be a nice improvement
> > > > to streamline the core ZooKeeper build. This can help side-projects
> > > > succeed or fail on their own merits, rather than be bound to the core
> > > > project so tightly, and it could make it easier for contributors to
> > > > know where to contribute, by making each independent component
> smaller
> > > > and easier to navigate through the code.
> > >
> > > Mostly agree—except that I would subsitute "popularity" for "merits."
> > > (Which may or may not change the conclusion.)
> >
> > Yes, popularity. :)
> >
> > >
> > > Cheers, -D
> >
>

Re: [DISCUSS] Sending 3.4 release line to End-Of-Life status

[Patrick Hunt]

On Fri, Apr 3, 2020 at 10:59 PM Christopher  wrote:

> On Fri, Apr 3, 2020 at 12:57 PM Patrick Hunt  wrote:
> >
> > On Thu, Apr 2, 2020 at 1:14 PM Christopher  wrote:
> >
> > > On Thu, Apr 2, 2020 at 12:20 PM Patrick Hunt  wrote:
> > > >
> > > > On Thu, Apr 2, 2020 at 8:15 AM Andor Molnar 
> wrote:
> > > >
> > > > > Alright. Not sure how to coordinate this properly, let’s try to
> discuss
> > > > > these 3 points individually.
> > > > >
> > > > > 1) EOL is 1st of June, 2020 which means from this day forward 3.4
> is
> > > ...
> > > > >- not supported by the community dev team,
> > > > >- not accepting patches, no future releases, no security fixes,
> > > > >- latest version is still accessible at download page for 1(?)
> year
> > > > >
> > > > >
> > > > Apache archival process is documented on this page:
> > > > https://www.apache.org/legal/release-policy.html#when-to-archive
> > > > we do get nudged on it every so often:  e.g.
> > > > https://issues.apache.org/jira/browse/ZOOKEEPER-1752
> > >
> > > The archival process is regarding removal of old versions from the
> > > mirroring system. It does not apply to "current" releases ("current"
> > > being defined as still linked from the project's download page).
> > >
> > >
> > The text is pretty unequivocal and not what you are saying.
> >
> > "downloads.apache.org should contain *the latest release in each branch
> > that is currently under development*. When development ceases on a
> version
> > branch, releases of that branch should be removed from the project's
> > download directory."
> >
> > Meaning it should go to archive only once the branch is no longer under
> > active development, not that it would be "removed". The semantics btw
> > archive and remove are different. I don't think we should ever truly
> > "remove" anything once we've officially released it. eg. you can still
> find
> > 3.3 on the archive site if you want it.
>
> The portion you are quoting is from an FAQ, below the release policy,
> not the release policy itself. The actual policy doesn't address the
> archival *process*, only the requirement that releases be archived.
> The release policy is set by VP Legal, whereas the release and
> archival *processes* are managed by VP Infra. The FAQs have their
> shortcomings and could be improved (this isn't the first time these
> FAQs have caused confusion by seemingly conflicting with how INFRA
> operates the distribution channels).
>
> In order to be consistent with best practices for how the mirror
> system is intended to be used for release artifact distribution, I
> interpret "When development ceases" to refer to the entire development
> lifecycle, including release promotion via announcements and
> availability on the downloads page. Otherwise, you'd have to archive
> any "final release" of a branch immediately, and if you wanted to
> widely distribute the release by promoting it on the downloads page,
> you would have to link to the archives which is *BAD*. Projects
> should distribute releases via the mirroring system, not via the
> archives. Once they stop promoting the artifacts on their downloads
> page, the artifacts should be removed (archived) from
> SVN/dist.apache.org as the same time.
>
> If you're uncomfortable with interpreting "development" to include the
> release promotion period where they are linked on the downloads page,
> you could instead just choose to not "cease" development until you are
> ready to remove it from the downloads page. You could slow development
> down to the point where maybe you might still release critical
> security fixes, for example, but really nothing else. Development is
> still "active" and hasn't "ceased". But, what you should not do, is
> continue promoting the artifact on the downloads page with a link to
> the archives.
>
> If somebody from INFRA wants to contradict me on this... I'm happy to
> be corrected with more accurate information... but I'm 99% confident
> they don't want releases being promoted that cause users to pull more
> heavily on the archives servers, as that would be a costly drain on
> Foundation resources.
>
> All that said, the last 3.4 release has been promoted on the downloads
> page for over a year now, which is probably long enough for a final
> release, so it's probably easiest to just go ahead and remove it from
> your downloads page (and from the mirrors, of course) sooner, rather
> than wait until later.
>

For 3.4 example specifically I don't see how it could be considered "in
development" if we state that it's EOL as detailed by Andor above. That
seems to meet the criteria as I understand it. I agree that removing it
from the downloads page would be reasonable and consistent with that intent.

Patrick

Re: ZooKeeper snapCount Tuning

[Patrick Hunt]

On Fri, Apr 3, 2020 at 6:19 AM David Mollitor  wrote:

> Hello Community,
>
> The configuration zookeeper.snapCount defaults to a value of 100,000 and
> has been at this default for 11 years now.
>
>
> https://github.com/apache/zookeeper/blob/e87bad6774e7269ef21a156aff9dad089ef54794/zookeeper-server/src/main/java/org/apache/zookeeper/server/ZooKeeperServer.java#L1149
>
> Based on the last ZK meetup, I know there has been some recent attempts to
> re-run the baseline performance benchmarks.
>
> The current value may be a "safe" value.  However, I think we can all agree
> that hardware has improved quite a bit in the past 11 years.  Does anyone
> have any experience tweaking and testing this number on a production
> system?  Are there any recommendations out there for how to set this value?
>
>
Makes sense. For eg. SSD characteristics are vastly diff from spinning
media. I suspect it would be worth looking into this in even more depth -
we pre-allocate certain files, perhaps that's no longer necessary, etc...
Makes sense. If we do something it would be great to have a set of tests
that could be used/reused to explore the various types even beyond SSD
itself.

Regards,

Patrick


> My hypothesis is: with a larger snapCount value, ZK can have higher
> throughput because it is spending less time creating snapshots.
>
> Thanks!
>

Re: [DISCUSS] Sending 3.4 release line to End-Of-Life status

[Patrick Hunt]

On Thu, Apr 2, 2020 at 1:14 PM Christopher  wrote:

> On Thu, Apr 2, 2020 at 12:20 PM Patrick Hunt  wrote:
> >
> > On Thu, Apr 2, 2020 at 8:15 AM Andor Molnar  wrote:
> >
> > > Alright. Not sure how to coordinate this properly, let’s try to discuss
> > > these 3 points individually.
> > >
> > > 1) EOL is 1st of June, 2020 which means from this day forward 3.4 is
> ...
> > >- not supported by the community dev team,
> > >- not accepting patches, no future releases, no security fixes,
> > >- latest version is still accessible at download page for 1(?) year
> > >
> > >
> > Apache archival process is documented on this page:
> > https://www.apache.org/legal/release-policy.html#when-to-archive
> > we do get nudged on it every so often:  e.g.
> > https://issues.apache.org/jira/browse/ZOOKEEPER-1752
>
> The archival process is regarding removal of old versions from the
> mirroring system. It does not apply to "current" releases ("current"
> being defined as still linked from the project's download page).
>
>
The text is pretty unequivocal and not what you are saying.

"downloads.apache.org should contain *the latest release in each branch
that is currently under development*. When development ceases on a version
branch, releases of that branch should be removed from the project's
download directory."

Meaning it should go to archive only once the branch is no longer under
active development, not that it would be "removed". The semantics btw
archive and remove are different. I don't think we should ever truly
"remove" anything once we've officially released it. eg. you can still find
3.3 on the archive site if you want it.

Patrick


> The question here is regarding the timing for removal from the
> project's download page. I suggest event-based, rather than
> time-based. Since ZK seems to be maintaining 3 release lines
> concurrently, you could remove 3.4 when 3.7 is released, unless
> there's a good reason to drop it sooner (to reduce the number of
> concurrent releases supported to 2, for example).
>
> >
> >
> > > 2) Supported upgrade path is: latest 3.4 -> latest 3.5 -> latest 3.6
> > >
> > > 3) Interoperability guarantees:
> > >- Previous version of ZooKeeper client is able to connect to server
> as
> > > long as there’s no new feature enforced on server side,
> > >- Previous version of ZooKeeper server is able to accept connections
> > > from clients as long as they don’t want to use new features.
> > >
> > >
> > I believe 2/3 are consistent with "Backward Compatibility" here?
> > https://cwiki.apache.org/confluence/display/ZOOKEEPER/ReleaseManagement
> >
> > Patrick
> >
> >
> > > Thoughts?
> > >
> > > Andor
> > >
> > >
> > >
> > >
> > > > On 2020. Apr 2., at 6:30, Michael Han  wrote:
> > > >
> > > > +1.
> > > >
> > > > For EOL policy statement, just to throw something out here that i can
> > > think
> > > > of:
> > > >
> > > > * Define what EOL means (such as: not supported by community dev team
> > > > anymore, no future 3.4 releases .. still accessible at download page
> for
> > > X
> > > > years..) and a date of EOL.
> > > >
> > > > * Provide guidelines for upgrading paths to 3.5 / 3.6.
> > > >
> > > > * State interoperability guarantees another post pointed out
> previously ^
> > > >
> > > > On Wed, Apr 1, 2020 at 2:04 AM Andor Molnar 
> wrote:
> > > >
> > > >> Hi folks,
> > > >>
> > > >> Based on Enrico’s latest post about a 3.4 client problem I’d like to
> > > push
> > > >> this initiative.
> > > >> Asking more senior members of the community what communicated
> policy is
> > > >> needed exactly to say 3.4 is EoL?
> > > >>
> > > >> In terms of timing I’d like Patrick’s suggestion about 1st of June,
> > > 2020.
> > > >>
> > > >> Any objections?
> > > >>
> > > >> Andor
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>> On 2020. Mar 4., at 18:45, Michael K. Edwards <
> m.k.edwa...@gmail.com>
> > > >> wrote:
> > > >>>
> > > >>> I think it would be useful for an EOL statement about 3.4.x to
> include
&

Re: [ANNOUNCE] New ZooKeeper committer: Mate Szalay-Beko

[Patrick Hunt]

Kudos Mate!

Patrick

On Fri, Apr 3, 2020 at 3:07 AM tison  wrote:

> Kudos Mate!
>
> Best,
> tison.
>
>
> Tamas Penzes  于2020年4月3日周五 下午5:53写道：
>
> > Congrats Mate!
> >
> > On Fri, Apr 3, 2020, 10:42 Andor Molnar  wrote:
> >
> > > The Apache ZooKeeper PMC recently extended committer karma to Mate and
> he
> > > has accepted.
> > > Mate has made some great contributions (including C client!) and we are
> > > looking forward to even more. :)
> > >
> > > Congratulations and welcome aboard, Mate!
> > >
> > >
> > >
> >
>

Re: [DISCUSS] Sending 3.4 release line to End-Of-Life status

[Patrick Hunt]

On Thu, Apr 2, 2020 at 8:15 AM Andor Molnar  wrote:

> Alright. Not sure how to coordinate this properly, let’s try to discuss
> these 3 points individually.
>
> 1) EOL is 1st of June, 2020 which means from this day forward 3.4 is ...
>- not supported by the community dev team,
>- not accepting patches, no future releases, no security fixes,
>- latest version is still accessible at download page for 1(?) year
>
>
Apache archival process is documented on this page:
https://www.apache.org/legal/release-policy.html#when-to-archive
we do get nudged on it every so often:  e.g.
https://issues.apache.org/jira/browse/ZOOKEEPER-1752


> 2) Supported upgrade path is: latest 3.4 -> latest 3.5 -> latest 3.6
>
> 3) Interoperability guarantees:
>- Previous version of ZooKeeper client is able to connect to server as
> long as there’s no new feature enforced on server side,
>- Previous version of ZooKeeper server is able to accept connections
> from clients as long as they don’t want to use new features.
>
>
I believe 2/3 are consistent with "Backward Compatibility" here?
https://cwiki.apache.org/confluence/display/ZOOKEEPER/ReleaseManagement

Patrick


> Thoughts?
>
> Andor
>
>
>
>
> > On 2020. Apr 2., at 6:30, Michael Han  wrote:
> >
> > +1.
> >
> > For EOL policy statement, just to throw something out here that i can
> think
> > of:
> >
> > * Define what EOL means (such as: not supported by community dev team
> > anymore, no future 3.4 releases .. still accessible at download page for
> X
> > years..) and a date of EOL.
> >
> > * Provide guidelines for upgrading paths to 3.5 / 3.6.
> >
> > * State interoperability guarantees another post pointed out previously ^
> >
> > On Wed, Apr 1, 2020 at 2:04 AM Andor Molnar  wrote:
> >
> >> Hi folks,
> >>
> >> Based on Enrico’s latest post about a 3.4 client problem I’d like to
> push
> >> this initiative.
> >> Asking more senior members of the community what communicated policy is
> >> needed exactly to say 3.4 is EoL?
> >>
> >> In terms of timing I’d like Patrick’s suggestion about 1st of June,
> 2020.
> >>
> >> Any objections?
> >>
> >> Andor
> >>
> >>
> >>
> >>
> >>> On 2020. Mar 4., at 18:45, Michael K. Edwards 
> >> wrote:
> >>>
> >>> I think it would be useful for an EOL statement about 3.4.x to include
> a
> >>> policy on interoperability of newer ZooKeeper servers with 3.4.x client
> >>> code.  Stacks that build on top of Kafka and Hadoop (I'm looking at
> you,
> >>> Spark) often wind up having an indirect dependency on a comically stale
> >>> ZooKeeper library.  Even if this library isn't really exercised by the
> >>> client side of the stack, it's there in the mountain of jars; and when
> >>> application code also wants to use ZooKeeper more directly, using a
> newer
> >>> client library can get kind of messy.  The approach I've taken has been
> >> to
> >>> rebuild large swathes of the stack around a consistent, recent
> ZooKeeper
> >>> build; but I think it would be relevant to a lot of people to know
> >> whether,
> >>> say, a 3.4.14 client will work reliably with a 3.6.x quorum.
> >>>
> >>> On Wed, Mar 4, 2020 at 9:28 AM Enrico Olivelli 
> >> wrote:
> >>>
> >>>> Il giorno mer 4 mar 2020 alle ore 17:23 Patrick Hunt
> >>>>  ha scritto:
> >>>>>
> >>>>> It seems like we should have a stated/communicated policy around
> >> release
> >>>>> lifecycles before sending an EOL message. That way folks have some
> >> runway
> >>>>> to plan for the event, both near term (3.4) as well as long term.
> >>>>
> >>>> Shall we set a deadline ?
> >>>> Something like "3.4 will be EOL by the end of 2020" ?
> >>>> At this point we are only "discussing" about sending 3.4 to EOL, no
> >>>> decision has been made yet
> >>>>
> >>>>
> >>>> Enrico
> >>>>
> >>>>
> >>>>>
> >>>>> Patrick
> >>>>>
> >>>>> On Wed, Mar 4, 2020 at 5:16 AM Szalay-Bekő Máté <
> >>>> szalay.beko.m...@gmail.com>
> >>>>> wrote:
> >>>>>
> >>>>>> Also a minor thing to consider: we wanted to ask t