Moving this to pacemaker since I think that is probably the best place for this uuid to live (feel free to move it back if you think it belongs somewhere else).

Ken,

I'm wondering if we can just create a cluster property (that pacemaker ignores) where we can set the UUID (maybe as part of pcs cluster create?).  (Or maybe there is something in there that gets auto-generated on cluster creation).

Thanks,
Chris

(In reply to Chris Feist from comment #1)
> Moving this to pacemaker since I think that is probably the best place for
> this uuid to live (feel free to move it back if you think it belongs
> somewhere else).
> 
> Ken,
> 
> I'm wondering if we can just create a cluster property (that pacemaker
> ignores) where we can set the UUID (maybe as part of pcs cluster create?). 
> (Or maybe there is something in there that gets auto-generated on cluster
> creation).

It occurred to me later that there's no clear point-in-time of "cluster creation" from corosync's perspective, AFAIK. I believe corosync just reads corosync.conf (or the specified config file) on daemon startup.

If we're okay with not making this a built-in part of pacemaker or corosync tied to the particular cluster, then a straightforward method would be to create a cluster property during `pcs cluster setup`. There might be some corner cases to consider, like removing node 1 from a 3-node cluster, leaving nodes 2a and 3a in the original cluster, and then adding nodes 2b and 3b to node 1's current one-node cluster, without ever doing a pcs cluster setup or destroy. If I'm thinking about this right, it might leave two clusters with the same UUID.

What about some option for pcs which would generate unique cluster name (let's say cluster_name_prefix-UUID_postfix) during cluster create? That would allow UUID functionality with no change in corosync/pcmk.

Of course even corosync could generate UUID (if no exists yet) and store it alongside with ringid and present it in some form (probably cmap). But it would be problematic for corosync to have it synchronized across the nodes. So pcmk cib (which is synchronized by default) seems to be really better choice here.

Just one more comment what can be used without any change. Corosync "ignores" unknown entries in corosync.conf and just stores them in cmap. So if someone uses this example file snip:
```
totem {
    version: 2
    transport: knet
    cluster_name: mycluster
    cluster_uuid: 6f41ea47-dba9-4860-a1fc-64484dc05d69
...
```

can then call corosync-cmapctl:
```
# corosync-cmapctl  -g totem.cluster_uuid
totem.cluster_uuid (str) = 6f41ea47-dba9-4860-a1fc-64484dc05d69
```

to get uuid back.

I would just recommend that the administrator run uuidgen to generate their cluster name. Possibly via a wrapper script that calls pcs cluster create with whatever their preferred defaults are.

I was thinking a bit more about of this and I think having "standardized" cluster_uuid stored (as shown in my previous comment) in corosync.conf makes sense. Basically only pcs would need to be changed (for now).

Reassigning to pcs for consideration

It seems reasonable for pcs to create a random UUID and store it in corosync.conf as shown in #comment 4 as a part of 'pcs cluster setup' command.

Feature merged into upstream master: https://github.com/ClusterLabs/pcs/commit/f487e6d14f1d73f7fcbf6b8e14efe81ee06de486

New clusters created with "pcs cluster setup" are going to get a UUID by default. Anyone wishing to create a cluster without UUID can use the "--no-cluster-uuid"
switch on cluster setup. This UUID is being stored in the totem section of corosync.conf under "cluster_uuid" key. The generated UUID is compliant with RFC4122 [1], UUID version 4.

Command "pcs cluster config [show]" can be used to display the UUID. For existing clusters without the UUID, one can be generated by using "pcs cluster config uuid generate". In case of an UUID collision in an external system, like a CMDB (configuration management database [2]), the UUID can be regenerated with "pcs cluster config uuid generate --force". The "--force" is needed for overwriting an existing UUID in this case.  


[1] https://datatracker.ietf.org/doc/html/rfc4122.html
[2] https://en.wikipedia.org/wiki/Configuration_management_database


ENVIRONMENT PREPARATION:
- any cluster (do not use "--no-cluster-uuid" on setup)

DEV TEST:
## Generate a UUID and verify it's there
# pcs cluster config uuid generate
# pcs cluster config
Cluster Name: c3-el8m5
Cluster UUID: d59b7ca9b3ff4b5e8c758a10a8b8d350
Transport: knet
Nodes:
  c3n1-el8.5:
    Link 0 address: c3n1-el8.5
    nodeid: 1
  c3n2-el8.5:
    Link 0 address: c3n2-el8.5
    nodeid: 2
Crypto Options:
  cipher: aes256
  hash: sha256

DevTestResults:

[root@r8-node-01 ~]# rpm -q pcs
pcs-0.10.13-1.el8.x86_64


[root@r8-node-01 ~]# pcs cluster config | grep "Cluster UUID:"
Cluster UUID: cd1a29b262f34fbc9bfd930381458ee6
[root@r8-node-01 ~]# pcs cluster config uuid generate
Error: Cluster UUID has already been set, use --force to override
Error: Errors have occurred, therefore pcs is unable to continue
[root@r8-node-01 ~]# pcs cluster config uuid generate --force
Warning: Cluster UUID has already been set
Sending updated corosync.conf to nodes...
r8-node-01: Succeeded
r8-node-03: Succeeded
r8-node-02: Succeeded
r8-node-01: Corosync configuration reloaded
[root@r8-node-01 ~]# pcs cluster config | grep "Cluster UUID:"
Cluster UUID: 48af22a01a5f46749d742c4c17ce047c

The Cluster UUID has been regenerated.

Marking as VERIFIED for pcs-0.10.13-1.el8 based on comment 21.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: pcs security, bug fix, and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2022:7447