+++ This bug was initially created as a clone of Bug #1950551 +++

Description of problem:

A customer is requesting a per-cluster UUID. Their use case is to uniquely identify each cluster within their CMDB.

The cluster name can serve as a unique identifier for the CMDB. But in an environment with a large number of clusters, an administrator may inadvertently (either manually or through an error in script logic) create two clusters with the same name.

There are certainly workarounds that make cluster name a viable solution as-is (e.g., check a new cluster's name against a database of existing names before building the new cluster). A UUID is a nice-to-have feature, acting as (nearly) a guarantee of uniqueness.

I'm not very familiar with the process of generating UUIDs and thus whether this is feasible for clusters. It looks like it might be, using something like timestamp at cluster creation and some identifier of a host (e.g., MAC address of a cluster's original node 1).
  - Universally Unique IDentifier (UUID) URN Namespace (https://tools.ietf.org/html/rfc4122)


I'm opening this against corosync as that seems like the most logical place to put this feature. CC'ing Ken for Pacemaker visibility.

--- Additional comment from Chris Feist on 2021-04-17 23:37:15 CEST ---

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

--- Additional comment from Reid Wahl on 2021-04-18 01:35:23 CEST ---

(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.

--- Additional comment from Jan Friesse on 2021-04-19 09:09:14 CEST ---

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.

--- Additional comment from Jan Friesse on 2021-04-19 09:35:46 CEST ---

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.

--- Additional comment from Ken Gaillot on 2021-04-19 15:47:34 CEST ---

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.

--- Additional comment from Jan Friesse on 2021-04-19 17:31:43 CEST ---

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).

--- Additional comment from Ken Gaillot on 2021-04-19 18:19:48 CEST ---

Reassigning to pcs for consideration

--- Additional comment from Tomas Jelinek on 2021-04-21 14:30:52 CEST ---

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.