Hide Forgot
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.
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