[ClusterLabs] Antw: [EXT] Rolling upgrade from Corosync 2.3+ to Corosync 2.99+ or Corosync 3.0+?

Vitaly Zolotusky vitaly at unitc.com
Fri Jun 12 07:47:41 EDT 2020


Hello,
This is exactly what we do in some of our software. We have a messaging version number and we can negotiate messaging protocol between nodes. Then communication is happening on the highest common version.
Would be great to have something like that available in Corosync!
Thanks,
_Vitaly

> On June 12, 2020 3:40 AM Ulrich Windl <ulrich.windl at rz.uni-regensburg.de> wrote:
> 
>  
> Hi!
> 
> I can't help here, but in general I think corosync should support "upgrade"
> mode. Maybe like this:
> The newer version can also speak the previous protocol and the current
> protocol will be enabled only after all nodes in the cluster are upgraded.
> 
> Probably this would require a tripple version number field like (oldest
> version supported, version being requested/used, newest version supported).
> 
> For the API a questy about the latest commonly agreed version number and a
> request to use a different version number would be needed, too.
> 
> Regards,
> Ulrich
> 
> >>> Vitaly Zolotusky <vitaly at unitc.com> schrieb am 11.06.2020 um 04:14 in
> Nachricht
> <19881_1591841678_5EE1938D_19881_553_1_1163034878.247559.1591841668387 at webmail6.
> etworksolutionsemail.com>:
> > Hello everybody.
> > We are trying to do a rolling upgrade from Corosync 2.3.5‑1 to Corosync 
> > 2.99+. It looks like they are not compatible and we are getting messages 
> > like:
> > Jun 11 02:10:20 d21‑22‑left corosync[6349]:   [TOTEM ] Message received from
> 
> > 172.18.52.44 has bad magic number (probably sent by Corosync 2.3+)..
> Ignoring
> > on the upgraded node and 
> > Jun 11 01:02:37 d21‑22‑right corosync[14912]:   [TOTEM ] Invalid packet
> data
> > Jun 11 01:02:38 d21‑22‑right corosync[14912]:   [TOTEM ] Incoming packet has
> 
> > different crypto type. Rejecting
> > Jun 11 01:02:38 d21‑22‑right corosync[14912]:   [TOTEM ] Received message
> has 
> > invalid digest... ignoring.
> > on the pre‑upgrade node.
> > 
> > Is there a good way to do this upgrade? 
> > I would appreciate it very much if you could point me to any documentation 
> > or articles on this issue.
> > Thank you very much!
> > _Vitaly
> > _______________________________________________
> > Manage your subscription:
> > https://lists.clusterlabs.org/mailman/listinfo/users 
> > 
> > ClusterLabs home: https://www.clusterlabs.org/


More information about the Users mailing list