Bug 1441332

This is comparable to what pcs already does for constraints on resources that are being removed.

However, automatically deleting ACLs doesn't sound like a good idea. In this example, if someone unset stonith-disabled, then later set it again, they might not realize that they lost their ACL.

An alternative would be to give a better error, in this case something like:

Error: cannot unset stonith-disabled because it is referenced in an ACL
Please delete all references first

Besides constraints and ACLs, other references that may occur:
* <primitive> may refer to a template
* <operations>, <rule>, <nvset> and <nvpair> may refer to definition elsewhere
* <tags> refers to one or more IDs (I have no idea what these are)

Hm, another alternative then would be to turn per-reference ACL
to equivalent non-intrusive per-XPath (desugaring done internally by
pacemaker, anyway), with a downside that this will no longer be
covered by proper "referential integrity" check imposed by RelaxNG
validations.

re [comment 1]:
> However, automatically deleting ACLs doesn't sound like a good idea.
> In this example, if someone unset stonith-disabled, then later set it
> again, they might not realize that they lost their ACL.

Actually there's a strong justification behind dropping such ACL
item right away in the elaborated scenario -- nvpairs do not have
user-configurable IDs (at pcs level), hence this is not something
users have firmly under their control and the IDs generated under
the hood are not something to rely on statically.  Consider
heterogenous management tools, even pcs itself provides no explicit
guarantee of stable IDs; that they are context-dependent is rather
a convenient coincidence + see also [bug 1387358 comment 4].

In that case, it's nice that ACL item would be preserved for
now-nonexistent entity in some way (see [comment 1]), however
odds are that it's ID on recreation will be different.

So I think warning about ACL item being dropped + doing so in the
process would be the way to go in this case.

+ there is no apriori protection-per-id anyway so adding something
for the first time is really not that different as re-adding it.

What might be interesting, though, is making per-id ACL items
a standard counterpart of entity-adding commands:

  pcs property set --read observer_role --deny guest_role \
    stonith-enabled=false

Automatic "garbage collecting" would then be even more natural.

re [comment 1]:
> Besides constraints and ACLs, other references that may occur:
> * <primitive> may refer to a template
> * <operations>, <rule>, <nvset> and <nvpair> may refer to definition
>   elsewhere
> * <tags> refers to one or more IDs (I have no idea what these are)

Situation is a bit more complicated.

I tried to summarize the relationships based on "referential integrity",
together with analysis as to which IDs can actually be deliberately
selected by the user of pcs.

* * *

referencable-element
- referencing-element-1@referencing-attr-1
- referencing-element-2@referencing-attr-2

template
- primitivee@template

(primitive, group, clone, master)
- rsc_colocation@rsc
- rsc_colocation@with-rsc
- rsc_location@rsc
- rsc_order@first
- rsc_order@then
- rsc_ticket@rsc

acl_role
- role@id

// reflexive-in-class-references via @id-ref
X
- X@id-ref
for X in (cluster_property_set, instance_attributes, meta_attributes,
          nvpair [since 1.3], operations, resource_set, rule,
          utilization)

// anything referencable (see next section) can be referenced by
(ID-HAVING)
- acl_permission@reference
- obj_ref@id

* * *

Let's enumerate ID-HAVING entities (see last part of previous section),
making a distinction as to whether those ID can be actively selected
using pcs commands, or if they are not supported with pcs at all.

Entities not supported by pcs at all:
- tag
- template

Entities where IDs _cannot_ be deliberately chosen in pcs commands:
- acl_permission
- cluster_property_set (fixed ID is used, though)
- date_expression
- date_spec
- duration
- expression
- fencing-level
- instance_attributes
- meta_attributes
- nvpair
- op
- operations
- resource_set
- utilization

Entities where IDs _can_ be deliberately chosen in pcs commands:
- acl_role
- rsc_colocation
- rsc_location
- rsc_order
- rsc_ticket

(
+ coming:
- bundle
- port-mapping
- storage-mapping
)

* * *

In re <tags>: it's potentially very useful though non-interoperable way
how the management tools can group selected objects (identifiable with
with IDs) in a distributed manner under some other identifier, with
no semantic interpretation of this tag identifier other than how it's
understood by the management tool.  So, for instance, I can imagine
it could be (ab)used to list some especially important resources
prominently in the list, no matter which pcs UI daemon is accessed.

Note that respective <obj_ref> (and in turn <tags> when suddenly
made empty in due course) SHOULD be treated the very same way as
ACLs -- in ON DELETE CASCADE manner, even if tags are not supported
by pcs per se, yet.

FWIW, this is the on-merge discussion for <tags>:
https://github.com/ClusterLabs/pacemaker/pull/463

I should also mention a special category where, contrary to the bug
report, pcs is keen to enforce referential integrity where it is
conceptually desired in the final product but is not mandated (typically
cannot be as constrainted by limited RelaxNG expressivness and perhaps
suboptimal way of encoding one-or-more relationships with the dependent
entities) in the schema:

primitive (or possibly whatever makes sense to encode stonith resources)
- fencing-level/@devices (possibly carrying "id1,...,idN" array
  of pointers to respective configured instances of fence agents)

After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.