Re: Rolling upgrade from 3.5 to 3.6 - expected behaviour

Michael, your points are valid. I would like to see the proposal from Mate. Up to ZOOKEEPER-3188 no other patch in 3.6 (from my limited point of view) introduced changes in quorum peer protocol to make it non compatible with 3.5. Enrico Il giorno mar 11 feb 2020 alle ore 23:35 Michael K. Edwards

ZooKeeper_branch34_jdk7 - Build # 2595 - Failure

See https://builds.apache.org/job/ZooKeeper_branch34_jdk7/2595/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 47.03 KB...] [junit] Running org.apache.zookeep

Jenkins build is back to stable : zookeeper-master-maven #664

See

Re: Rolling upgrade from 3.5 to 3.6 - expected behaviour

I think it would be prudent to emphasize in the release notes that rolling upgrades (and mixed ensembles generally) are effectively untested. That this was, in practice, a non-goal of this release cycle. Because if we can get to rc2 without noticing a showstopper, clearly it's not something that

Re: Rolling upgrade from 3.5 to 3.6 - expected behaviour

Hi Andor, this is almost exactly what I proposed. More precisely: 1) First we make multi-address feature disabled by default. 2) If disabled, quorum protocol automatically uses the old protocol version which lets 3.5 and 3.6 communicate smoothly. The code in 3.6.0 will be able to understand both

Failed: ZOOKEEPER-3721 PreCommit Build #3883

Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-3721 Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/3883/ ### ## LAST 60 LINES OF THE CONSOLE ### [

[jira] [Created] (ZOOKEEPER-3721) Make the boolean configuration parameter only accept "true" or "false"

Ctest created ZOOKEEPER-3721: Summary: Make the boolean configuration parameter only accept "true" or "false" Key: ZOOKEEPER-3721 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3721 Project: ZooKeep

Re: Rolling upgrade from 3.5 to 3.6 - expected behaviour

Mate, Let me reiterate to see if I understand you correctly: 1) First we make multi-address feature disabled by default. 2) If disabled, quorum protocol automatically uses the old protocol version which lets 3.5 and 3.6 communicate smoothly. 3) Once the user finished the first rolling restart

Re: Rolling upgrade from 3.5 to 3.6 - expected behaviour

>> but it didn't solve the problem. Yes, the constraint is 3.6.0 has to default to old protocol version so the outgoing message is backward compatible. If we do this, then it's essentially the "the simplest solution" proposed. >> disable the new MultiAddress feature and stick to the old protocol

Jenkins build became unstable: zookeeper-master-maven-jdk13 #64

See

Re: Rolling upgrade from 3.5 to 3.6 - expected behaviour

I see the main problem here in the fact that we are missing proper versioning in the leader election / quorum protocols. I tried to simply implement backward compatibility in 3.6, but it didn't solve the problem. The new code understands the old protocol, but it can not decide when to use the new o

Re: Rolling upgrade from 3.5 to 3.6 - expected behaviour

I hate to say it, but I think 3.6.0 should release as is. It is impossible to *reliably* retrofit backwards compatibility / interoperability onto a release that was engineered from the beginning without that goal. Learn the lesson, set goals differently in the future. On Tue, Feb 11, 2020 at 9:4

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

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

Re: Rolling upgrade from 3.5 to 3.6 - expected behaviour

FYI: I created these scripts for my local tests: https://github.com/symat/zk-rolling-upgrade-test For the long term I would also add some script that actually monitors the state of the quorum and also runs continuous traffic, not just 1-2 smoketests after each restart. But I don't know how importa

Re: Rolling upgrade from 3.5 to 3.6 - expected behaviour

Il giorno mar 11 feb 2020 alle ore 17:17 Andor Molnar ha scritto: > > The most obvious one which crosses my mind is that I previously worked on: > > 1) run old version cluster, > 2) connect to each node and run smoke tests, > 3) restart one node with new code, > 4) goto 2) until all nodes are upgr

Re: Rolling upgrade from 3.5 to 3.6 - expected behaviour

The most obvious one which crosses my mind is that I previously worked on: 1) run old version cluster, 2) connect to each node and run smoke tests, 3) restart one node with new code, 4) goto 2) until all nodes are upgraded I think this wouldn’t work in a “unit test”, we probably need a separate

Re: Rolling upgrade from 3.5 to 3.6 - expected behaviour

Anyone have ideas how we could add testing for upgrade? Obviously something we're missing, esp given it's import. Patrick On Tue, Feb 11, 2020 at 12:40 AM Enrico Olivelli wrote: > Il giorno mar 11 feb 2020 alle ore 09:12 Szalay-Bekő Máté > ha scritto: > > > > Hi All, > > > > about the question

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

See Changes: -- [...truncated 66.81 KB...] [INFO] zookeeper-jute-3.6.0-SNAPSHOT.jar - SHA-512 : b962de7e27b2a93f40bc912a9123133676726b71b66a2c1245a2e5bc0ee613a3a1b2b88b47d55fbd05

Jenkins build became unstable: zookeeper-master-maven-jdk11 #370

See

[jira] [Created] (ZOOKEEPER-3720) Rolling upgrade failure due to invalid protocol version

Mate Szalay-Beko created ZOOKEEPER-3720: --- Summary: Rolling upgrade failure due to invalid protocol version Key: ZOOKEEPER-3720 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3720 Project: Z

Re: [CANCELLED] Re: [VOTE] Apache ZooKeeper release 3.6.0 candidate 2

Good catch, Enrico... > On 11 Feb 2020, at 09:43, Enrico Olivelli wrote: > > -1 > I saw that 3.6 servers are not able to join a 3.5 cluster, this make > it difficult or rather impossible to have a graceful rolling upgrade. > > In a separate thread on this list we discussed about this problem an

[CANCELLED] Re: [VOTE] Apache ZooKeeper release 3.6.0 candidate 2

-1 I saw that 3.6 servers are not able to join a 3.5 cluster, this make it difficult or rather impossible to have a graceful rolling upgrade. In a separate thread on this list we discussed about this problem and we decided to work on adding support for this scenario (rolling upgrade without servic

Re: Rolling upgrade from 3.5 to 3.6 - expected behaviour

Il giorno mar 11 feb 2020 alle ore 09:12 Szalay-Bekő Máté ha scritto: > > Hi All, > > about the question from Michael: > > Regarding the fix, can we just make 3.6.0 aware of the old protocol and > > speak old message format when it's talking to old server? > > In this particular case, it might be

Re: Rolling upgrade from 3.5 to 3.6 - expected behaviour

Hi All, about the question from Michael: > Regarding the fix, can we just make 3.6.0 aware of the old protocol and > speak old message format when it's talking to old server? In this particular case, it might be enough. The protocol change happened now in the 'initial message' sent by the QuorumC