diff --git a/doc/sphinx/Pacemaker_Explained/reusing-configuration.rst b/doc/sphinx/Pacemaker_Explained/reusing-configuration.rst
index 45212e8d52..892638b9ab 100644
--- a/doc/sphinx/Pacemaker_Explained/reusing-configuration.rst
+++ b/doc/sphinx/Pacemaker_Explained/reusing-configuration.rst
@@ -1,378 +1,360 @@
Reusing Parts of the Configuration
----------------------------------
-.. Convert_to_RST:
-
- Pacemaker provides multiple ways to simplify the configuration XML by reusing
- parts of it in multiple places.
-
- Besides simplifying the XML, this also allows you to manipulate multiple
- configuration elements with a single reference.
-
- == Reusing Resource Definitions ==
-
- If you want to create lots of resources with similar configurations, defining a
- 'resource template' simplifies the task. Once defined, it can be referenced in
- primitives or in certain types of constraints.
-
- === Configuring Resources with Templates ===
-
- The primitives referencing the template will inherit all meta-attributes,
- instance attributes, utilization attributes and operations defined
- in the template. And you can define specific attributes and operations for any
- of the primitives. If any of these are defined in both the template and the
- primitive, the values defined in the primitive will take precedence over the
- ones defined in the template.
-
- Hence, resource templates help to reduce the amount of configuration work.
- If any changes are needed, they can be done to the template definition and
- will take effect globally in all resource definitions referencing that
- template.
-
- Resource templates have a syntax similar to that of primitives.
-
- .Resource template for a migratable Xen virtual machine
- ====
- [source,XML]
- ----
-
-
-
-
-
-
-
-
-
-
-
-
- ----
- ====
-
- Once you define a resource template, you can use it in primitives by specifying the
- +template+ property.
-
- .Xen primitive resource using a resource template
- ====
- [source,XML]
- ----
-
-
-
-
-
-
- ----
- ====
-
- In the example above, the new primitive +vm1+ will inherit everything from +vm-template+. For
- example, the equivalent of the above two examples would be:
-
- .Equivalent Xen primitive resource not using a resource template
- ====
- [source,XML]
- ----
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- ----
- ====
-
- If you want to overwrite some attributes or operations, add them to the
- particular primitive's definition.
-
- .Xen resource overriding template values
- ====
- [source,XML]
- ----
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- ----
- ====
-
- In the example above, the new primitive +vm2+ has special
- attribute values. Its +monitor+ operation has a longer +timeout+ and +interval+, and
- the primitive has an additional +stop+ operation.
-
- To see the resulting definition of a resource, run:
-
- ----
+Pacemaker provides multiple ways to simplify the configuration XML by reusing
+parts of it in multiple places.
+
+Besides simplifying the XML, this also allows you to manipulate multiple
+configuration elements with a single reference.
+
+Reusing Resource Definitions
+############################
+
+If you want to create lots of resources with similar configurations, defining a
+*resource template* simplifies the task. Once defined, it can be referenced in
+primitives or in certain types of constraints.
+
+Configuring Resources with Templates
+____________________________________
+
+The primitives referencing the template will inherit all meta-attributes,
+instance attributes, utilization attributes and operations defined
+in the template. And you can define specific attributes and operations for any
+of the primitives. If any of these are defined in both the template and the
+primitive, the values defined in the primitive will take precedence over the
+ones defined in the template.
+
+Hence, resource templates help to reduce the amount of configuration work.
+If any changes are needed, they can be done to the template definition and
+will take effect globally in all resource definitions referencing that
+template.
+
+Resource templates have a syntax similar to that of primitives.
+
+.. topic:: Resource template for a migratable Xen virtual machine
+
+ .. code-block:: xml
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Once you define a resource template, you can use it in primitives by specifying the
+``template`` property.
+
+.. topic:: Xen primitive resource using a resource template
+
+ .. code-block:: xml
+
+
+
+
+
+
+
+
+In the example above, the new primitive ``vm1`` will inherit everything from ``vm-template``. For
+example, the equivalent of the above two examples would be:
+
+.. topic:: Equivalent Xen primitive resource not using a resource template
+
+ .. code-block:: xml
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+If you want to overwrite some attributes or operations, add them to the
+particular primitive's definition.
+
+.. topic:: Xen resource overriding template values
+
+ .. code-block:: xml
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+In the example above, the new primitive ``vm2`` has special attribute values.
+Its ``monitor`` operation has a longer ``timeout`` and ``interval``, and
+the primitive has an additional ``stop`` operation.
+
+To see the resulting definition of a resource, run:
+
+.. code-block:: none
+
# crm_resource --query-xml --resource vm2
- ----
-
- To see the raw definition of a resource in the CIB, run:
-
- ----
+
+To see the raw definition of a resource in the CIB, run:
+
+.. code-block:: none
+
# crm_resource --query-xml-raw --resource vm2
- ----
-
- === Using Templates in Constraints ===
-
- A resource template can be referenced in the following types of constraints:
-
- - +order+ constraints (see <>)
- - +colocation+ constraints (see <>)
- - +rsc_ticket+ constraints (for multi-site clusters as described in <>)
-
- Resource templates referenced in constraints stand for all primitives which are
- derived from that template. This means, the constraint applies to all primitive
- resources referencing the resource template. Referencing resource templates in
- constraints is an alternative to resource sets and can simplify the cluster
- configuration considerably.
-
- For example, given the example templates earlier in this chapter:
-
- [source,XML]
+
+Using Templates in Constraints
+______________________________
+
+A resource template can be referenced in the following types of constraints:
+
+- ``order`` constraints (see :ref:`s-resource-ordering`)
+- ``colocation`` constraints (see :ref:`s-resource-colocation`)
+- ``rsc_ticket`` constraints (for multi-site clusters as described in :ref:`ticket-constraints`)
+
+Resource templates referenced in constraints stand for all primitives which are
+derived from that template. This means, the constraint applies to all primitive
+resources referencing the resource template. Referencing resource templates in
+constraints is an alternative to resource sets and can simplify the cluster
+configuration considerably.
+
+For example, given the example templates earlier in this chapter:
+
+.. code-block:: xml
+
-
- would colocate all VMs with +base-rsc+ and is the equivalent of the following constraint configuration:
-
- [source,XML]
- ----
+
+would colocate all VMs with ``base-rsc`` and is the equivalent of the following constraint configuration:
+
+.. code-block:: xml
+
- ----
-
- [NOTE]
- ======
+
+.. note::
+
In a colocation constraint, only one template may be referenced from either
- `rsc` or `with-rsc`; the other reference must be a regular resource.
- ======
-
- === Using Templates in Resource Sets ===
-
- Resource templates can also be referenced in resource sets.
-
- For example, given the example templates earlier in this section, then:
-
- [source,XML]
- ----
+ ``rsc`` or ``with-rsc``; the other reference must be a regular resource.
+
+Using Templates in Resource Sets
+________________________________
+
+Resource templates can also be referenced in resource sets.
+
+For example, given the example templates earlier in this section, then:
+
+.. code-block:: xml
+
- ----
-
- is the equivalent of the following constraint using a sequential resource set:
-
- [source,XML]
- ----
+
+is the equivalent of the following constraint using a sequential resource set:
+
+.. code-block:: xml
+
- ----
-
- Or, if the resources referencing the template can run in parallel, then:
-
- [source,XML]
- ----
+
+Or, if the resources referencing the template can run in parallel, then:
+
+.. code-block:: xml
+
- ----
-
- is the equivalent of the following constraint configuration:
-
- [source,XML]
- ----
+
+is the equivalent of the following constraint configuration:
+
+.. code-block:: xml
+
- ----
-
- [[s-reusing-config-elements]]
- == Reusing Rules, Options and Sets of Operations ==
-
- Sometimes a number of constraints need to use the same set of rules,
- and resources need to set the same options and parameters. To
- simplify this situation, you can refer to an existing object using an
- +id-ref+ instead of an +id+.
-
- So if for one resource you have
-
- [source,XML]
- ------
+
+.. _s-reusing-config-elements::
+
+Reusing Rules, Options and Sets of Operations
+#############################################
+
+Sometimes a number of constraints need to use the same set of rules,
+and resources need to set the same options and parameters. To
+simplify this situation, you can refer to an existing object using an
+``id-ref`` instead of an ``id``.
+
+So if for one resource you have
+
+.. code-block:: xml
+
- ------
-
- Then instead of duplicating the rule for all your other resources, you can instead specify:
-
- .Referencing rules from other constraints
- =====
- [source,XML]
- -------
+
+Then instead of duplicating the rule for all your other resources, you can instead specify:
+
+.. topic:: Referencing rules from other constraints
+
+.. code-block:: xml
+
-
+
- -------
- =====
-
- [IMPORTANT]
- ===========
- The cluster will insist that the +rule+ exists somewhere. Attempting
+
+.. important::
+
+ The cluster will insist that the ``rule`` exists somewhere. Attempting
to add a reference to a non-existing rule will cause a validation
- failure, as will attempting to remove a +rule+ that is referenced
+ failure, as will attempting to remove a ``rule`` that is referenced
elsewhere.
- ===========
-
- The same principle applies for +meta_attributes+ and
- +instance_attributes+ as illustrated in the example below:
-
- .Referencing attributes, options, and operations from other resources
- =====
- [source,XML]
- -------
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- -------
- =====
-
- +id-ref+ can similarly be used with +resource_set+ (in any constraint type),
- +nvpair+, and +operations+.
-
- == Tagging Configuration Elements ==
-
- Pacemaker allows you to 'tag' any configuration element that has an XML ID.
-
- The main purpose of tagging is to support higher-level user interface tools;
- Pacemaker itself only uses tags within constraints. Therefore, what you can
- do with tags mostly depends on the tools you use.
-
- === Configuring Tags ===
-
- A tag is simply a named list of XML IDs.
-
- .Tag referencing three resources
- ====
- [source,XML]
- ----
-
-
-
-
-
-
-
- ----
- ====
-
- What you can do with this new tag depends on what your higher-level tools
- support. For example, a tool might allow you to enable or disable all of
- the tagged resources at once, or show the status of just the tagged
- resources.
-
- A single configuration element can be listed in any number of tags.
-
- === Using Tags in Constraints and Resource Sets ===
-
- Pacemaker itself only uses tags in constraints. If you supply a tag name
- instead of a resource name in any constraint, the constraint will apply to
- all resources listed in that tag.
-
- .Constraint using a tag
- ====
- [source,XML]
- ----
-
- ----
- ====
-
- In the example above, assuming the +all-vms+ tag is defined as in the previous
- example, the constraint will behave the same as:
-
- .Equivalent constraints without tags
- ====
- [source,XML]
- ----
-
-
-
- ----
- ====
-
- A tag may be used directly in the constraint, or indirectly by being
- listed in a <> used in the constraint.
- When used in a resource set, an expanded tag will honor the set's
- +sequential+ property.
+
+The same principle applies for ``meta_attributes`` and
+``instance_attributes`` as illustrated in the example below:
+
+.. topic:: Referencing attributes, options, and operations from other resources
+
+ .. code-block:: xml
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+``id-ref`` can similarly be used with ``resource_set`` (in any constraint type),
+``nvpair``, and ``operations``.
+
+Tagging Configuration Elements
+##############################
+
+Pacemaker allows you to *tag* any configuration element that has an XML ID.
+
+The main purpose of tagging is to support higher-level user interface tools;
+Pacemaker itself only uses tags within constraints. Therefore, what you can
+do with tags mostly depends on the tools you use.
+
+Configuring Tags
+________________
+
+A tag is simply a named list of XML IDs.
+
+.. topic:: Tag referencing three resources
+
+ .. code-block:: xml
+
+
+
+
+
+
+
+
+
+What you can do with this new tag depends on what your higher-level tools
+support. For example, a tool might allow you to enable or disable all of
+the tagged resources at once, or show the status of just the tagged
+resources.
+
+A single configuration element can be listed in any number of tags.
+
+Using Tags in Constraints and Resource Sets
+___________________________________________
+
+Pacemaker itself only uses tags in constraints. If you supply a tag name
+instead of a resource name in any constraint, the constraint will apply to
+all resources listed in that tag.
+
+.. topic:: Constraint using a tag
+
+ .. code-block:: xml
+
+
+
+In the example above, assuming the ``all-vms`` tag is defined as in the previous
+example, the constraint will behave the same as:
+
+.. topic:: Equivalent constraints without tags
+
+ .. code-block:: xml
+
+
+
+
+
+A tag may be used directly in the constraint, or indirectly by being
+listed in a :ref:`resource set ` used in the constraint.
+When used in a resource set, an expanded tag will honor the set's
+``sequential`` property.