Re: Rolling upgrade from 3.5 to 3.6 - expected behaviour

Good. I will cancel the vote for 3.6.0rc2. I appreciate very much If Mate and his colleagues have time to work on a fix. Otherwise I will have cycles next week I would also like to spend my time in setting up a few minimal integration tests about the upgrade story Enrico Il Mar 11 Feb 2020,

Jenkins build became unstable: zookeeper-master-maven #663

See

Re: Rolling upgrade from 3.5 to 3.6 - expected behaviour

Kudos Enrico, very thorough work as the final gate keeper of the release! Now with this, I'd like to *vote a -1* on the 3.6.0 RC2. I'd recommend we fix this issue for 3.6.0. ZooKeeper is one of the rare piece of software that put so much emphasis on compatibilities thus it just works when

Re: Rolling upgrade from 3.5 to 3.6 - expected behaviour

I suggest this plan: - release 3.6.0 now - improve the migration story, the flow outlined by Mate is interesting, but it will take time 3.6.0rc2 got enough binding votes so I am going to finalize the release this evening (within 8-10 hours) if no one comes out in the VOTE thread with a -1 Enrico

Re: Rolling upgrade from 3.5 to 3.6 - expected behaviour

On Mon, Feb 10, 2020 at 3:38 AM Andor Molnar wrote: > Hi, > > Answers inline. > > > > In my experience when you are close to a release it is better to to > > make big changes. (I am among the approvers of that patch, so I am > > responsible for this change) > > > > Although this statement is

Build failed in Jenkins: zookeeper-branch36-java11 #46

See Changes: -- [...truncated 58.29 KB...] Generating

Jenkins build is back to normal : zookeeper-master-maven-jdk12 #368

See

Re: [VOTE] Apache ZooKeeper release 3.5.7 candidate 2

+1 (binding) - release notes are OK, - documentation looks good, - verified signatures, checksum, - Java & C unit tests passed, - verified 3-node cluster with zk-latencies.py (create, get, delete, setAcl, getAcl, watchers) Andor > On 2020. Feb 10., at 12:52, Norbert Kalmar wrote: > > This

Build failed in Jenkins: zookeeper-branch36-java8 #45

See Changes: -- [...truncated 51.28 KB...] Generating

Re: [VOTE] Apache ZooKeeper release 3.5.7 candidate 2

I ran Curator tests and they pass +1 (non binding) -Jordan > On Feb 10, 2020, at 6:52 AM, Norbert Kalmar wrote: > > This is the third bugfix release candidate for 3.5.7. It fixes 25 issues, > including third party CVE fixes, potential data loss and potential split > brain if some rare

[VOTE] Apache ZooKeeper release 3.5.7 candidate 2

This is the third bugfix release candidate for 3.5.7. It fixes 25 issues, including third party CVE fixes, potential data loss and potential split brain if some rare conditions exists. There are 4 additional patches compared to rc0 and rc1: - ZOOKEEPER-3453: missing 'SET' in zkCli on windows -

Re: [VOTE] Apache ZooKeeper release 3.5.7 candidate 1

Hi Jordan, It is available again. Rc1 got downvoted, so I created rc2 which is now available in the staging repo. I'll also write the email about it but before I'll just run a few more tests. - Norbert On Sun, Feb 9, 2020 at 4:43 PM Jordan Zimmerman wrote: > 3.5.7 is not in the staging repo.

Re: Rolling upgrade from 3.5 to 3.6 - expected behaviour

Hi, Answers inline. > In my experience when you are close to a release it is better to to > make big changes. (I am among the approvers of that patch, so I am > responsible for this change) Although this statement is acceptable for me, I don’t feel this patch should not have been merged

Re: Rolling upgrade from 3.5 to 3.6 - expected behaviour

Thank you Mate for checking and explaining this story. I find it very interesting that the cause is ZOOKEEPER-3188 as: - it is the last "big patch" committed to 3.6 before starting the release process - it is the cause of the failure of the first RC In my experience when you are close to a

Re: Rolling upgrade from 3.5 to 3.6 - expected behaviour

Actually, we have an other option: we can follow the way, how the rolling restart support for the QuorumSSL was implemented. - we can make 3.6.0 to be able to read both protocol versions - we can add a parameter that tells the 3.6.0 which protocol version to use (using the old one brakes /

Re: Rolling upgrade from 3.5 to 3.6 - expected behaviour

Hi Enrico! This is caused by the different PROTOCOL_VERSION in the QuorumCnxManager. The Protocol version was changed last time in ZOOKEEPER-2186 released first in 3.4.7 and 3.5.1 to avoid some crashing / fix some bugs. Later I also changed the protocol version when the format of the initial

Rolling upgrade from 3.5 to 3.6 - expected behaviour

Hi, even if we had enough binding +1 on 3.6.0rc2 before closing the VOTE of 3.6.0 I wanted to finish my tests and I am coming to an apparent blocker. I am trying to upgrade a 3.5.6 cluster to 3.6.0, but it looks like peers are not able to talk to each other. I have a cluster of 3, server1,