Pacemaker uses a lot of jargon, some of it not well-defined. It would make it easier for users and developers, especially new ones, if there were more consistency and natural language.
Attribute, option, parameter, property, and setting are often used interchangeably. Then we have instance attributes, meta-attributes, node attributes, and XML attributes, which are all unrelated despite using the same term. Similarly, we tend to use action, command, op, operation, request, and task somewhat interchangeably. It would be helpful to use consistent and easily distinguished terms.
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 (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.
All changes are open to discussionThese changes are definite:
* //metadata// has no hyphen (except when used as the OCF-specified meta-data action)
* //primitive// instead of //native//
* //primary// instead of //lh//,
but as an arbitrary starting point, here are some possibilitiesand //dependent// instead of //rh// when referring to constraints
* //assign// instead of //allocate// for associating resources with nodes
* //score// instead of //weight//
* //self-fencing// instead of //suicide// (T279)
* //bundle// instead of //container// when referring to the collective resource (use //container// only in the usual sense of an isolated environment)
The following are possibilities for discussion:
* For Pacemaker-defined settings,
replacuse //
meta-attributes// with //options//options// instead of //meta-attributes// (and continue to use //options// for cluster options, so we have cluster options, resource options, alert options, etc.)
.
* For * Use //agent parameters
, replace// or //parameters// instead of //instance attributes//
with //parameters// (so we have(so we refer to resource agent parameters or resource parameters, alert
agent parameters or alert parameters, etc.; note that this is more consistent with the OCF standard's terminology)
.
* Replace //node attributes// with something else (so //attributes// is used only for XML attributes)
.
* As* Use //setting// instead of //nvpair// as a generic reference for an option, agent parameter,
or node attribute, replace //nvpair// with //setting//.or node attribute
* Use //action//
forinstead of //task//, //operation//, or //op// to refer to a generic action name
s (start, stop, etc.)
., for consistency with the OCF standard
* Use //
operation// (or maybe //task//) for specific instances of an action.task// instead of //action//, //operation//, or //op// to refer to a specific instance of an action (for a particular resource and node)
* Use //request// for IPC and CPG messages
.
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>