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

From crm/cluster.h, sbd uses send_cluster_text() and crm_msg_ais but only if HAVE_DECL_PCMK_CLUSTER_CLASSIC_AIS

I suspect the use case for this feature was being able to set an explicit value in one block of meta-attributes, then have another rule-based block of attributes that resets the value to the default. Simply omitting the meta-attribute from the rule-based block wouldn't cause the explicit value to be removed.

In T817#12112, @nrwahl2 wrote:

From the GitHub discussion:

I believe it was originally for testing the code paths. Not needed anymore

Optionally, we could have a (possibly hidden) --async-call option for developer use, that starts a mainloop and runs a callback function that processes the reply.

From the GitHub discussion:

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)