Bug 1950551 - [RFE] Generate UUID for each cluster
Summary: [RFE] Generate UUID for each cluster
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: pcs
Version: 8.3
Hardware: All
OS: Linux
Target Milestone: beta
: 8.7
Assignee: Michal Pospisil
QA Contact: cluster-qe@redhat.com
Steven J. Levine
Depends On:
TreeView+ depends on / blocked
Reported: 2021-04-16 21:30 UTC by Reid Wahl
Modified: 2022-11-08 09:23 UTC (History)
13 users (show)

Fixed In Version: pcs-0.10.13-1.el8
Doc Type: Enhancement
Doc Text:
.Support for cluster UUID During cluster setup, the `pcs` command now generates a UUID for every cluster. Since a cluster name is not a unique cluster identifier, you can use the cluster UUID to identify clusters with the same name when you administer multiple clusters. You can display the current cluster UUID with the `pcs cluster config [show]` command. You can add a UUID to an existing cluster or regenerate a UUID if it already exists by using the `pcs cluster config uuid generate` command.
Clone Of:
: 2054671 2058250 (view as bug list)
Last Closed: 2022-11-08 09:12:53 UTC
Type: Feature Request
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 5973101 0 None None None 2021-04-16 22:43:46 UTC
Red Hat Product Errata RHSA-2022:7447 0 None None None 2022-11-08 09:13:11 UTC

Description Reid Wahl 2021-04-16 21:30:08 UTC
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.

Comment 1 Chris Feist 2021-04-17 21:37:15 UTC
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).


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


Comment 2 Reid Wahl 2021-04-17 23:35:23 UTC
(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.

Comment 3 Jan Friesse 2021-04-19 07:09:14 UTC
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.

Comment 4 Jan Friesse 2021-04-19 07:35:46 UTC
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.

Comment 5 Ken Gaillot 2021-04-19 13:47:34 UTC
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.

Comment 6 Jan Friesse 2021-04-19 15:31:43 UTC
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).

Comment 7 Ken Gaillot 2021-04-19 16:19:48 UTC
Reassigning to pcs for consideration

Comment 8 Tomas Jelinek 2021-04-21 12:30:52 UTC
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.

Comment 9 Michal Pospisil 2022-03-17 13:40:38 UTC
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

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

## 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
    Link 0 address: c3n1-el8.5
    nodeid: 1
    Link 0 address: c3n2-el8.5
    nodeid: 2
Crypto Options:
  cipher: aes256
  hash: sha256

Comment 11 Miroslav Lisik 2022-05-26 08:39:43 UTC

[root@r8-node-01 ~]# rpm -q pcs

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

Comment 22 svalasti 2022-06-30 10:08:53 UTC
Marking as VERIFIED for pcs-0.10.13-1.el8 based on comment 21.

Comment 26 errata-xmlrpc 2022-11-08 09:12:53 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.