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 <[email protected]> schrieb am 11.06.2020 um 04:14 in Nachricht <19881_1591841678_5EE1938D_19881_553_1_1163034878.247559.1591841668387@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/ _______________________________________________ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
