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.
## Problems
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.
## Definite changes
* Use //metadata// (no hyphen) instea
d 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)
## Possibilities for discussion
* 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.)
* Use //agent parameters// or //parameters// instead of //instance attributes// (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)
* Use //setting// instead of //nvpair// as a generic reference for an option, agent parameter, or node attribute
* 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 //task// instead of //action//, //operation//, or //op// to refer to a specific instance of an action (for a particular resource and node)
* Use
//message// or //request// for IPC and CPG messages
* Use //standard// instead of //class// for resource agents, except when referring to a literal setting name
## 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>