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 discussion, but as an arbitrary starting point, here are some possibilities:
* For Pacemaker-defined settings, replace //meta-attributes// with //options// (and continue to use //options// for cluster options, so we have cluster options, resource options, alert options, etc.).
* For agent parameters, replace //instance attributes// with //parameters// (so we have resource parameters, 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 a generic reference for an option, agent parameter, or node attribute, replace //nvpair// with //setting//.
* Use //action// for action names (start, stop, etc.).
* Use //operation// (or maybe //task//) for specific instances of an action.
* 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> | <parameters>
<nvpair ... /> | <setting ... />
</instance_attributes> | </parameters>
</primitive> | </resource>
</resources> | </resources>
</configuration> | </configuration>
... | ...
</cib> | </cib>