This happens because the schema defines the "id" attribute of both resources and acl_groups (but not acl_targets) as having the "ID" data type, which must be unique.

The "ID" data type also constrains what values must be used: it must start with a letter or underscore; any further characters may also be a digit, period, dash, or Unicode "combining character" or "extender" (used to make e.g. an accented character out of the base character plus an accent).

My feeling is that acl_target's id should also be restricted to the ID type, but that could invalidate existing configurations, so it might not be a good idea to change that.

One way to address the issue mentioned here would be to add a "name" attribute that defaults to the value of "id". So, id would still have to be unique, but the group name could be supplied as name. I think that implementation should be relatively simple.

This will not be addressed in the 7.4 timeframe.

Due to time constraints, this will not make 7.5

> My feeling is that acl_target's id should also be restricted to the ID
> type, but that could invalidate existing configurations, so it might
> not be a good idea to change that.

Few notes:

1. current situation seems to allow for quirks like sketched in
   https://github.com/ClusterLabs/pacemaker/pull/1563/files#r212441702

2. reasonable solution might be in duality:
   rough validation as a whole vs. detailed validation per-partes

re 2.:

In the raw files, some "locally unique" fields would be overapproximated
as NCName type from XMLSchema datatypes (mere <text/> for "acl_target"
was a pretty poor choice), and rough validation would work out of the box.

But also the "local enough" scopes (imposed requirement: with level-unique
tag to avoid any ambiguities and keep the implementation simple) would be
specially annotated, ditto particular fields that should be considered
as ID datatype for the purpose of this detailed validation.

The task would then be:
- figure out all the unique scopes that can be of interest,
  per the annotations
- for each such scope, fetch the respective sub-schema,
  perform in-memory change of the datatypes per the annotations
- for each such scope, iterate through all (disjunct) instances
  present in the document, turn each such sub-stanza into
  document on its own, and validate it with the respective
  in-memory change sub-schema, i.e., imposing strict uniqueness
  requirements

In case of "acls", the nice property is that respective sub-schema
directly matches acls-2.0.rng, hence the whole procedure would
be relatively easily scriptable also in shell if the "scope annotation"
contained XPath to match particular occurrences of the mentioned
sub-stanzas.  Such light-weight shell script (assurably detached
from any pacemaker machinery) could then be offered for consumption
by higher level tools, independently of heavy weight crm_verify
(which could implement the same in C, though, rather then calling
out to this shell).

Because this will require new configuration syntax, for technical reasons this will only be addressed in RHEL 8

Due to developer time prioritization constraints, an upstream bug has been opened for this issue, and this report is being closed. If time becomes available, we will reopen this.

It is worth noting that this will not be useful until Bug 1724310 is fixed (ACL groups are currently not functional).

The XML schema has been updated upstream as of commit 7838213fc, which will allow specifying a "name" attribute separately from "id". The name will still default to the id for backward compatibility. As mentioned in Comment 10, this is just the configuration side; the functionality will be implemented separately.

QA: To verify, configure a cluster with ACLs including a group, then use "pcs cluster edit" to edit the XML directly to add name="whatever" to the acl_group element. Before the fix, the change will be rejected; after the fix, the change will be accepted.

before fix
-----------

>   [root@virt-530 ~]# rpm -q pacemaker
>   pacemaker-2.1.0-8.el8.x86_64

Configure a cluster with ACLs including a group, create dummy resource named "test":

>   [root@virt-530 ~]# pcs resource create test ocf:pacemaker:Dummy
>   [root@virt-530 ~]# pcs status
>   Cluster name: STSRHTS25391
>   Cluster Summary:
>     * Stack: corosync
>     * Current DC: virt-543 (version 2.1.0-8.el8-7c3f660707) - partition with quorum
>     * Last updated: Wed Jan 26 15:32:18 2022
>     * Last change:  Wed Jan 26 15:32:15 2022 by root via cibadmin on virt-530
>     * 2 nodes configured
>     * 3 resource instances configured

>   Node List:
>     * Online: [ virt-530 virt-543 ]

>   Full List of Resources:
>     * fence-virt-530	(stonith:fence_xvm):	 Started virt-530
>     * fence-virt-543	(stonith:fence_xvm):	 Started virt-543
>     * test	(ocf::pacemaker:Dummy):	 Started virt-530

>   Daemon Status:
>     corosync: active/disabled
>     pacemaker: active/disabled
>     pcsd: active/enabled

>   [root@virt-530 ~]# pcs acl enable

Try to name the ACL group the same as dummy resource. It should fail.

>   [root@virt-530 ~]# pcs acl group create test
>   Error: 'test' already exists

Choose another name for ACL group:

>   [root@virt-530 ~]# pcs acl group create testgroup
>   [root@virt-530 ~]# pcs acl
>   ACLs are enabled

>   Group: testgroup
>     Roles:

Try to add name="test" to acl_group element in CIB using `pcs cluster edit`:

>   [root@virt-530 ~]# pcs cluster edit scope=acls
>   Error: unable to push cib
>   Call cib_replace failed (-203): Update does not conform to the configured schema
>   <cib crm_feature_set="3.11.0" validate-with="pacemaker-3.7" epoch="13" num_updates="0" admin_epoch="0" cib-last-written="Wed Jan 26 16:18:34 2022" update-origin="virt-530" update-client="cibadmin" update-user="root" have-quorum="1" dc-uuid="1">
>     <configuration>

>   [...]

>       <acls>
>         <acl_group id="testgroup" name="test"/>
>       </acls>
>     </configuration>

The change is rejected.


after fix
-----------

>   [root@virt-525 ~]# rpm -q pacemaker
>   pacemaker-2.1.2-2.el8.x86_64

Configure a cluster with ACLs including a group, create dummy resource named "test":

>   [root@virt-525 ~]# pcs resource create test ocf:pacemaker:Dummy
>   [root@virt-525 ~]# pcs status
>   Cluster name: STSRHTS9364
>   Cluster Summary:
>     * Stack: corosync
>     * Current DC: virt-525 (version 2.1.2-2.el8-ada5c3b36e2) - partition with quorum
>     * Last updated: Wed Jan 26 17:14:58 2022
>     * Last change:  Wed Jan 26 17:14:45 2022 by root via cibadmin on virt-525
>     * 2 nodes configured
>     * 3 resource instances configured

>   Node List:
>     * Online: [ virt-524 virt-525 ]

>   Full List of Resources:
>     * fence-virt-524	(stonith:fence_xvm):	 Started virt-524
>     * fence-virt-525	(stonith:fence_xvm):	 Started virt-525
>     * test	(ocf::pacemaker:Dummy):	 Started virt-524

>   Daemon Status:
>     corosync: active/disabled
>     pacemaker: active/disabled
>     pcsd: active/enabled

Try to name the ACL group the same as dummy resource. It should fail.

>   [root@virt-525 ~]# pcs acl group create test
>   Error: 'test' already exists

Choose another name for ACL group:

>   [root@virt-525 ~]# pcs acl group create testgroup
>   [root@virt-525 ~]# pcs acl
>   ACLs are enabled

>   Group: testgroup
>     Roles:

Try to add name="test" to acl_group element in CIB using `pcs cluster edit`:

>   [root@virt-525 ~]# pcs cluster edit scope=acls
>   CIB updated

>   [root@virt-525 ~]# cibadmin --query --scope acls
>   <acls>
>     <acl_group id="testgroup" name="test"/>
>   </acls>

The change is accepted and CIB is updated.

Marking verified in pacemaker-2.1.2-2.el8

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 (pacemaker 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/RHBA-2022:1885