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

[Ulrich Windl]

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/