Pacemaker uses a lot of jargon, some of it
not well-poorly defined.
It would make it easier for users and developers, especially new onesMore consistent and natural language would be easier for users and developers,
if there were more consistency and natural languageespecially new ones.
## Problems
Attribute, option, parameter, property, and setting are often used interchangeably. Then we have instance attributes, meta-attributes,
utilization attributes, node attributes, and XML attributes,
which are mostly unrelated despite using the same term. All of these except XML attributes use the obscurely named `nvpair` element for individual values. We have historically used //set// to indicate a single XML element (`instance_attributes`, `meta_attributes`, which are all unrelated despite using the same term.etc.) containing a collection of `nvpair` elements (and optionally rules), but this can be confused with resource sets and //set// as a verb.
Similarly, we tend to use action, command, op, operation, request,
and task somewhat interchangeably. It would be helpful to use consistent and easily distinguished termsand task somewhat interchangeably.
Acronyms (like CIB, CRM, DC, and STONITH) tend to be confusing for beginners. It's not essential to eliminate these entirely (//hello XML//), but more natural phrasing (such as //fencing// instead of //stonith//) should be used when available.
When we come up with a good system, we can update the code and documentation, and update the schema to accept either the old or new names (
later using an XSL transform at a major or minor version bump to ensure the new names are always used). We can create subtasks for specific changes so it can be done in reasonable pieces.
## Definite changes
* Use //metadata// (no hyphen) instead of //meta-data// except when referring to the OCF-defined action name
* Use //primitive// instead of //native//
* Use //primary// instead of //lh//, and //dependent// instead of //rh//, when referring to constraints
* Use //assign// instead of //allocate// for associating resources with nodes
* Use //score// instead of //weight//
* Use //self-fencing// instead of //suicide// (T279)
* Use //bundle// instead of //container// when referring to the collective resource (use //container// only in the usual sense of an isolated environment)
## Likely changes still open to discussion
*
For Pacemaker-defined settings, use //options// instead of //meta-attributes// (and continue to use //options// for cluster options, so we have cluster optionUse //agent parameters// or //parameters// instead of //instance attributes// (so we have resource agent parameters or resource parameters,
resource optionsalert agent parameters or alert parameters,
alert options,etc.; etc.note that this is consistent with the OCF standard's usage)
*
Use //agent parameters// or //parameters// instead of //instance attributes// (so we refer to resource agent parameters or resource parameters,For Pacemaker-defined settings, use //options// instead of //meta-attributes// (and continue to use //options// for cluster options, so we have cluster options, resource options, alert options, etc.). alert agent parameters or alert parametersNote that we allow users to set custom meta-attributes (usable in rules or their own tooling),
etc.;so we would need a name for those (maybe //labels//, note that this is more consistent withor overload //tags// for the
OCF standard's terminology)se purposes).
* Use //action// instead of //task//, //operation//, or //op// to refer to a generic action name (start, stop, etc.), for consistency with the OCF standard
* Use //standard// instead of //class// for resource agents, except when referring to a literal setting name
## Other possibilities for discussion
* Replace //n
ode attributes// with something elsvpair// with something more natural (maybe //setting// or //variable//) as a generic reference for an option, agent parameter, node attribute,
so //attributes// is used only for XML attributeor utilization attribute
* Maybe replace //set// with something more distinctive (maybe //collection// or //list//) for a grouping of nvpairs
* Us* Replace //
setting// instead of //nvpair// as a generic reference for an option, agent parameterattributes// for node and utilization attributes (maybe with //settings// or //variables//),
or nodeso //attributes// is used only for XML attribute
s
* Use //operation// or maybe //task// instead of //action// or //op// to refer to a specific instance of an action
(forexecuted for a particular resource and node
)
* Use //message// or maybe //request// for IPC and CPG messages
## CIB syntax
Here is a hypothetical example of what CIB syntax changes might look like:
```
<cib ...> | <cib ...>
<configuration> | <configuration>
<crm_config> | <cluster>
<cluster_property_set> | <options>
<nvpair ... /> | <setting ... />
</cluster_property_set> | </options>
</crm_config> | </cluster>
<nodes> | <nodes>
... | ...
</nodes> | </nodes>
<resources> | <resources>
<primitive ...> | <resource ...>
<meta_attributes> | <options>
<nvpair ... /> | <setting ... />
</meta_attributes> | </options>
<instance_attributes> | <agent_parameters>
<nvpair ... /> | <setting ... />
</instance_attributes> | </agent_parameters>
</primitive> | </resource>
</resources> | </resources>
</configuration> | </configuration>
... | ...
</cib> | </cib>