Fix indentation in few of the documentation pages

Partial-Bug: #1712860
Change-Id: Id467f5a917e61643823a9d82faa94516ea250f43

doc/source/admin/api-audit-support.rst

@@ -41,7 +41,7 @@ to ``/etc/ironic/ironic.conf``.
     audit_map_file=/etc/ironic/api_audit_map.conf
 
 #. Comma separated list of Ironic REST API HTTP methods to be ignored during audit.
-   For example: GET,POST. It is used only when API audit is enabled.
+   It is used only when API audit is enabled. For example::
 
     [audit]
     ...

doc/source/admin/drivers/ilo.rst

@@ -114,7 +114,7 @@ The ``ilo`` hardware type supports following hardware interfaces:
 The following command can be used to enroll a ProLiant node with
 ``ilo`` hardware type:
 
-    .. code-block:: console
+.. code-block:: console
 
     openstack baremetal node create --os-baremetal-api-version=1.31 \
         --driver ilo \
@@ -131,7 +131,7 @@ explanation of hardware type.
 To enable the same feature set as provided by all iLO classic drivers,
 apply the following configuration:
 
-    .. code-block:: ini
+.. code-block:: ini
 
     [DEFAULT]
     enabled_hardware_types = ilo
@@ -966,21 +966,21 @@ Supported **Automated** Cleaning Operations
 
 * The automated cleaning operations supported are:
 
-  ``reset_bios_to_default``:
+  * ``reset_bios_to_default``:
     Resets system ROM settings to default. By default, enabled with priority
     10. This clean step is supported only on Gen9 and above servers.
-  ``reset_secure_boot_keys_to_default``:
+  * ``reset_secure_boot_keys_to_default``:
     Resets secure boot keys to manufacturer's defaults. This step is supported
     only on Gen9 and above servers. By default, enabled with priority 20 .
-  ``reset_ilo_credential``:
+  * ``reset_ilo_credential``:
     Resets the iLO password, if ``ilo_change_password`` is specified as part of
     node's driver_info. By default, enabled with priority 30.
-  ``clear_secure_boot_keys``:
+  * ``clear_secure_boot_keys``:
     Clears all secure boot keys. This step is supported only on Gen9 and above
     servers. By default, this step is disabled.
-  ``reset_ilo``:
+  * ``reset_ilo``:
     Resets the iLO. By default, this step is disabled.
-  ``erase_devices``:
+  * ``erase_devices``:
     An inband clean step that performs disk erase on all the disks including
     the disks visible to OS as well as the raw disks visible to Smart
     Storage Administrator (SSA). This step supports erasing of the raw disks
@@ -1632,7 +1632,7 @@ step could be::
 
 The different attributes of ``activate_license`` clean step are as follows:
 
-  .. csv-table::
+.. csv-table::
     :header: "Attribute", "Description"
     :widths: 30, 120
 
@@ -1689,7 +1689,7 @@ step could be::
 
 The different attributes of ``update_firmware`` clean step are as follows:
 
-  .. csv-table::
+.. csv-table::
     :header: "Attribute", "Description"
     :widths: 30, 120
 
@@ -1712,11 +1712,11 @@ All the fields in the firmware image block are mandatory.
 * The different types of firmware url schemes supported are:
   ``file``, ``http``, ``https`` and ``swift``.
 
-.. note::
+  .. note::
      This feature assumes that while using ``file`` url scheme the file path is
      on the conductor controlling the node.
 
-.. note::
+  .. note::
      The ``swift`` url scheme assumes the swift account of the ``service``
      project. The ``service`` project (tenant) is a special project created in
      the Keystone system designed for the use of the core OpenStack services.
@@ -1724,7 +1724,7 @@ All the fields in the firmware image block are mandatory.
      ``service`` and the container is generally ``ironic`` and ``ilo`` drivers
      use a container named ``ironic_ilo_container`` for their own purpose.
 
-.. note::
+  .. note::
      While using firmware files with a ``.rpm`` extension, make sure the commands
      ``rpm2cpio`` and ``cpio`` are present on the conductor, as they are utilized
      to extract the firmware image from the package.

doc/source/admin/security.rst

@@ -109,13 +109,14 @@ Ideally, an operator would work with their hardware vendor to ensure that
 proper firmware security measures are put in place ahead of time. This could
 include:
 
-  - installing signed firmware for BIOS and peripheral devices
+- installing signed firmware for BIOS and peripheral devices
-  - using a TPM (Trusted Platform Module) to validate signatures at boot time
+- using a TPM (Trusted Platform Module) to validate signatures at boot time
-  - booting machines in :ref:`iLO UEFI Secure Boot Support`, rather than BIOS mode, to
+- booting machines in :ref:`iLO UEFI Secure Boot Support`, rather than BIOS mode, to
   validate kernel signatures
-  - disabling local (in-band) access from the host OS to the management controller (BMC)
+- disabling local (in-band) access from the host OS to the management controller (BMC)
-  - disabling modifications to boot settings from the host OS
+- disabling modifications to boot settings from the host OS
 
 Additional references:
-  - :ref:`cleaning`
+
-  - :ref:`trusted-boot`
+- :ref:`cleaning`
+- :ref:`trusted-boot`

doc/source/contributor/architecture.rst

@@ -21,7 +21,7 @@ An Ironic deployment will be composed of the following components:
   built which contains one of these agents, eg. with `diskimage-builder`_.
   This ramdisk can be booted on-demand.
 
-    - **NOTE:** The agent is never run inside a tenant instance.
+  .. note:: The agent is never run inside a tenant instance.
 
 .. _`architecture_drivers`:
 

doc/source/contributor/code-contribution-guide.rst

@@ -142,49 +142,49 @@ not be tolerated, and will be called out in public on the mailing list.
 Live Upgrade Related Concerns
 =============================
 
-Ironic implements upgrade with the same methodology of Nova:
+Ironic implements upgrade with the `same methodology as Nova <https://docs.openstack.org/nova/latest/user/upgrade.html>`_.
-
-    https://docs.openstack.org/nova/latest/user/upgrade.html
 
 Ironic API RPC Versions
 -----------------------
 
-*  When the signature(arguments) of an RPC method is changed, the following things
+When the signature(arguments) of an RPC method is changed, the following
-   need to be considered:
+things need to be considered:
 
- - The RPC version must be incremented and be the same value for both the client
+- The RPC version must be incremented and be the same value for both the
-   (conductor/rpcapi.py, used by ironic-api) and the server (conductor/manager.py,
+  client (conductor/rpcapi.py, used by ironic-api) and the server
-   used by ironic-conductor).
+  (conductor/manager.py, used by ironic-conductor).
- - New arguments of the method can only be added as optional. Existing arguments cannot be
+- New arguments of the method can only be added as optional. Existing
-   removed or changed in incompatible ways (with the method in older RPC versions).
+  arguments cannot be removed or changed in incompatible ways (with the
- - Client-side can pin a version cap by passing ``version_cap`` to the constructor
+  method in older RPC versions).
-   of oslo_messaging.RPCClient. Methods which change arguments should run
+- Client-side can pin a version cap by passing ``version_cap`` to the
-   client.can_send_version() to see if the version of the request is compatible with the
+  constructor of oslo_messaging.RPCClient. Methods which change arguments
-   version cap of RPC Client, otherwise the request needs to be created to work with a
+  should run client.can_send_version() to see if the version of the request
-   previous version that is supported.
+  is compatible with the version cap of RPC Client, otherwise the request
- - Server-side should tolerate the older version of requests in order to keep
+  needs to be created to work with a previous version that is supported.
-   working during the progress of live upgrade. The behavior of server-side should
+- Server-side should tolerate the older version of requests in order to keep
-   depend on the input parameters passed from the client-side.
+  working during the progress of live upgrade. The behavior of server-side
+  should depend on the input parameters passed from the client-side.
 
 Object Versions
 ---------------
-* When Object classes (subclasses of ironic.objects.base.IronicObject) are modified, the
+When Object classes (subclasses of ironic.objects.base.IronicObject) are
-  following things need to be considered:
+modified, the following things need to be considered:
 
- - The change of fields and the signature of remotable method needs a bump of object
+- The change of fields and the signature of remotable method needs a bump of
-   version.
+  object version.
- - The arguments of methods can only be added as optional, they cannot be
+- The arguments of methods can only be added as optional, they cannot be
   removed or changed in an incompatible way.
- - Fields types cannot be changed. If it is a must, create a new field and
+- Fields types cannot be changed. If it is a must, create a new field and
   deprecate the old one.
- - When new version objects communicate with old version objects,
+- When new version objects communicate with old version objects,
-   obj_make_compatible() will be called to convert objects to the target version during
+  obj_make_compatible() will be called to convert objects to the target
-   serialization. So objects should implement their own obj_make_compatible() to
+  version during serialization. So objects should implement their own
-   remove/alter attributes which was added/changed after the target version.
+  obj_make_compatible() to remove/alter attributes which was added/changed
- - There is a test (object/test_objects.py) to generate the hash of object fields and the
+  after the target version.
-   signatures of remotable methods, which helps developers to check if the change of
+- There is a test (object/test_objects.py) to generate the hash of object
-   objects need a version bump. The object fingerprint should only be updated with a
+  fields and the signatures of remotable methods, which helps developers to
-   version bump.
+  check if the change of objects need a version bump. The object fingerprint
+  should only be updated with a version bump.
 
 Driver Internal Info
 ====================
@@ -192,7 +192,8 @@ The ``driver_internal_info`` node field was introduced in the Kilo release. It a
 driver developers to store internal information that can not be modified by end users.
 Here is the list of existing common and agent driver attributes:
 
-Common attributes:
+* Common attributes:
+
   * ``is_whole_disk_image``: A Boolean value to indicate whether the user image contains ramdisk/kernel.
   * ``clean_steps``: An ordered list of clean steps that will be performed on the node.
   * ``instance``: A list of dictionaries containing the disk layout values.
@@ -201,12 +202,15 @@ Common attributes:
   * ``is_next_boot_persistent``: A Boolean value to indicate whether the next boot device is
     ``persistent_boot_device``.
 
-Agent driver attributes:
+* Agent driver attributes:
-  * ``agent_url``: A String value of IPA API URL so that Ironic can talk to IPA ramdisk.
+
-  * ``hardware_manager_version``: A String value of the version of the hardware manager in IPA ramdisk.
+  * ``agent_url``: A String value of IPA API URL so that Ironic can talk to IPA
-  * ``target_raid_config``: A Dictionary containing the target RAID configuration. This is a copy of
+    ramdisk.
-    the same name attribute in Node object. But this one is never actually saved into DB and is only
+  * ``hardware_manager_version``: A String value of the version of the hardware
-    read by IPA ramdisk.
+    manager in IPA ramdisk.
+  * ``target_raid_config``: A Dictionary containing the target RAID
+    configuration. This is a copy of the same name attribute in Node object.
+    But this one is never actually saved into DB and is only read by IPA ramdisk.
 
 .. note::
 
@@ -252,13 +256,15 @@ Changes to existing specs
 -------------------------
 
 For approved but not-completed specs:
- - cosmetic cleanup, fixing errors, and changing the definition of a feature
+
+- cosmetic cleanup, fixing errors, and changing the definition of a feature
   can be done to the spec.
 
 For approved and completed specs:
- - changing a previously approved and completed spec should only be done
+
+- changing a previously approved and completed spec should only be done
   for cosmetic cleanup or fixing errors.
- - changing the definition of the feature should be done in a new spec.
+- changing the definition of the feature should be done in a new spec.
 
 
 Please see the `Ironic specs process wiki page <https://wiki.openstack.org/

doc/source/contributor/osprofiler-support.rst

@@ -74,13 +74,11 @@ profiler options and restart ironic services::
 
 
 In order to trace ironic using OSProfiler, use openstackclient to run
-baremetal commands with
+baremetal commands with ``--os-profile SECRET_KEY``.
 
-    ``--os-profile SECRET_KEY``
+For example, the following will cause a <trace-id> to be printed after node list::
 
-For example, the following will cause a <trace-id> to be printed after node list:
+    $ openstack --os-profile SECRET_KEY baremetal node list
-
-    ``$ openstack --os-profile SECRET_KEY baremetal node list``
 
 Output of the above command will include the following::
 

doc/source/contributor/releasing.rst

@@ -60,40 +60,41 @@ Things to do after releasing
 
 When a release is done that results in a stable branch
 ------------------------------------------------------
+
 When a release is done that results in a stable branch for the project, the
 release automation will push a number of changes that need to be approved.
 
 In the new stable branch, this will include:
 
-  * a change to point .gitreview at the branch
+* a change to point .gitreview at the branch
-  * a change to update the upper constraints file used by tox
+* a change to update the upper constraints file used by tox
 
 In the master branch, this will include:
 
-  * updating the release notes RST to include the new branch
+* updating the release notes RST to include the new branch
 
 Additionally, changes need to be made to the stable branch to:
 
-  * update the ironic devstack plugin to point at the branched tarball for IPA.
+* update the ironic devstack plugin to point at the branched tarball for IPA.
   An example of this patch is
   `here <https://review.openstack.org/#/c/374863/>`_.
-  * update links in developer documentation to point to the branched version
+* update links in developer documentation to point to the branched version
   of the install guide.
-  * update links in the install guide to point to the branched version of
+* update links in the install guide to point to the branched version of
   the developer documentation.
-  * set appropriate defaults for TEMPEST_BAREMETAL_MIN_MICROVERSION and
+* set appropriate defaults for TEMPEST_BAREMETAL_MIN_MICROVERSION and
   TEMPEST_BAREMETAL_MAX_MICROVERSION in devstack/lib/ironic to make sure that
   unsupported API tempest tests are skipped on stable branches.
 
 Additionally, changes need to be made on master to:
 
-  * create an empty commit with a ``Sem-Ver`` tag to bump the generated minor
+* create an empty commit with a ``Sem-Ver`` tag to bump the generated minor
   version. See `example
   <https://git.openstack.org/cgit/openstack/ironic/commit/?id=4b28af4645c2f3b6d7864671e15904ed8f40414d>`_
   and `pbr documentation
   <https://docs.openstack.org/pbr/latest/user/features.html#version>`_ for details.
 
-  * to support rolling upgrades, since the release was a named release:
+* to support rolling upgrades, since the release was a named release:
 
   * In ironic/common/release_mappings.py, delete any entries from RELEASE_MAPPING
     associated with the oldest named release. Since we support upgrades between
@@ -110,9 +111,10 @@ Additionally, changes need to be made on master to:
 
 For all releases
 ----------------
+
 For all releases, whether or not it results in a stable branch:
 
-  * update the specs repo to mark any specs completed in the release as
+* update the specs repo to mark any specs completed in the release as
   implemented.
 
-  * remove any -2s on patches that were blocked until after the release.
+* remove any -2s on patches that were blocked until after the release.

doc/source/install/include/kernel-boot-parameters.rst

@@ -37,7 +37,7 @@ flexible and can vary per instance.
 Here is an example for grub2 with ubuntu, users can customize it
 to fit their use case:
 
-    .. code:: python
+.. code:: python
 
      #!/usr/bin/env python
      import os