These are ideas for discussion. Any ready to be worked on can be separated into their own subtask. See also the existing subtasks.

The main goals would be to make the configuration more intuitive, closer to natural language, and use XML structure effectively.

Use element content instead of value attribute

Pacemaker's CIB doesn't use content with any XML elements. I'm not sure why that design was chosen, but it would be make sense to replace the value attribute in nvpair and recipient elements. For example:

<nvpair id="option1" name="stonith-enabled" value="false"/>

could become:

<nvpair id="option1" name="stonith-enabled">false</nvpair>

That would have implications for XML escaping, especially for multiline values. It would also preclude some of the enumeration-like schema we currently have for particular cluster options.

The new form could be allowed with the old form deprecated and retained for compatibility, with support eventually dropped (and an XSL transform mapping it to the new form).

Cluster options

• Options currently set as XML attributes of the cib element should be with the regular cluster options whenever practical, which would help with creating minimum-privilege ACLs. They are currently XML attributes so that the CIB manager and controller can more easily utilize them.

• Cluster options dynamically generated by Pacemaker (not intended for user modification) could move into a special section (maybe a cluster_property_set with a magic ID, or a new element in the status section). This would help discourage user modifications and make the distinction obvious.

Element for topology devices

For example:

<fencing-level id="level1" target="node1" index="1" devices="apc1,apc2"/>

could become something like:

<fencing-level id="level1" target="node1" index="1">
  <resource_ref id-ref="apc1"/>
  <resource_ref id-ref="apc2"/>
</fencing-level>

The new form would be better structured and allow IDREF type validation.

expression attributes

It would be more intuitive to replace value and value-source with a choice of reference-value (literal), reference-parameter, or reference-option.

status schema

The status section is currently free-form, which gives more freedom to change it from release to release, but in practice the format has been stable for a long time. A formal schema might be worthwhile to help detect bugs during development.

Agent metadata cache

Currently, the controller obtains agent metadata and caches it locally. We could consider saving it to the status section beneath node_state. The advantage would be eliminating some differences between simulations and actual cluster behavior, and making it easier for the scheduler to schedule meta-data actions (T359). The main disadvantage would be CIB size in memory (which would be lessened by keeping just what we need from the metadata).