In T788#12132, @nrwahl2 wrote:

For 3.0.0 (T793)... For pcmk_cluster_t, we can replace all deprecated struct members except destroy() and cpg with a void *private member that can be used internally for a new internal struct containing the deprecated members.

Why can't destroy and cpg become part of the void *private member at 3.0.0? It seems that's the point of creating the setter functions for those, so that external users no longer need direct access.

For 3.0.0 (T793)... For pcmk_cluster_t, we can replace all deprecated struct members except destroy() and cpg with a void *private member that can be used internally for a new internal struct containing the deprecated members.

In T788#12087, @kgaillot wrote:

Ah right, whenever we did this before, we used new value names as well. Let's define new names like pcmk_cluster_type_corosync. (Or maybe pcmk_cluster_layer/pcmk_cluster_layer_corosync.)

In T788#12086, @nrwahl2 wrote:

deprecate (via doxygen comments)

Why no compat header?

In T788#12084, @nrwahl2 wrote:

if we create new values for enum cluster_type_e and use the current names in enum pcmk_cluster_type, we get type-checker errors:

deprecate (via doxygen comments)

On that note, considering that Corosync has been the only supported cluster type for a long time now, I wonder to what extent this stuff even needs to be public. We can always add public API functions again after branching to 3.0.0. Might even make some naming issues easier in the interim, if we can work with things internally without introducing new public names yet.

enum cluster_type_e: deprecate this name and create an equivalent enum pcmk_cluster_type (the enum value names are fine and do not need to be deprecated)

One of the next things on my agenda is to do mass, quick-and-dirty deprecations -- pcmk__*() with public wrapper, no best practices or refactors otherwise, to ensure we get as much deprecated as possible in time.

In T620#11858, @kgaillot wrote:

In T620#11565, @nrwahl2 wrote:

Meta-attribute inheritance is weird. I've just started looking at groups. Very much non-exhaustive:

• is-managed: Any false wins. If is-managed=false for the group and is-managed=true for a primitive, the primitive is unmanaged.
• maintenance: Any true wins. Similar to is-managed but reversed.

These are true in general for all resource parent-child relationships

I'm thinking the simplest approach might be to consider the "inheritable" meta-attributes as separate to each layer. For example there is a group resource-stickiness meta-attribute and a different primitive resource-stickiness meta-attribute. That way each could have its own description of how it behaves. Primitive resource-stickiness keeps the current description from Pacemaker Explained, group resource-stickiness gets something like "Default value to use for members' resource-stickiness if not explicitly set for the member. The group's own stickiness is not this value, but the sum of its members' stickiness." The primitive default could even be described as "Value of resource-stickiness in group meta-attributes if set, otherwise value of resource-stickiness in clone meta-attributes if set, otherwise value of resource-stickiness in bundle meta-attributes if set, otherwise 0, plus 1 for promoted clone instances of the primitive" though that sounds horrible.

In T620#11565, @nrwahl2 wrote:

Meta-attribute inheritance is weird. I've just started looking at groups. Very much non-exhaustive:

• is-managed: Any false wins. If is-managed=false for the group and is-managed=true for a primitive, the primitive is unmanaged.
• maintenance: Any true wins. Similar to is-managed but reversed.

For this task, we only need a deprecation warning. When we get around to dropping support for master, the code won't have to worry about it at all -- an XSL transform will map master to clone before the code ever sees it.

Taking a look at crm_map_element_name...