On 07/21/2011 12:19 PM, Jed Smith wrote: > Steve, > > Thank you again for all of the information. > > I labbed an in-place upgrade and the Corosync 1.4.0 compile brought > down the 1.2.1-4ubuntu1 box. All I did was deploy from scratch, create > a cluster with 1.2.1-4ubuntu1 and Pacemaker 1.0.10-4ubuntu3, then > compiled Corosync 1.4.0 and Pacemaker 1.0.11 and introduced them to > the cluster, and Corosync disappeared with no output. > > I don't mind building a new oblivious cluster and failing my resources > over the hard way -- I did that many times, including a transition > from Heartbeat to Corosync during development -- I'm just curious if > there's something I'm doing that's preventing the 1.2.1 box from > staying up. I restarted Corosync on the 1.2.1 side, and it crashed > immediately. > > Logs: http://pastie.org/private/e9ktdolkdesf3eeq5d5gnq > > Again, I don't mind doing an oblivious cluster rebuild. It's not > ideal, but it's also not a big deal -- you just mentioned that, in > theory, 1.2.1 should talk to 1.4.0 fine. >
A correction is in order. We test rolling upgrades from 1.2.latest z to 1.3.0 and 1.3.latest z to 1.4.0. updating from 1.2.1 may not roll properly. I expect rolling upgrades of redundant ring don't work well with 1.4.0 because of protocol changes to support automatic redundant ring recovery, which hopefully nobody was using until 1.4.0 where we added it to the list of things we really want to work well :) Regards -steve _______________________________________________ Openais mailing list Openais@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/openais
