fix sphinx errors with incorrect backticks

cardoe · cardoe · commit fbb12a2f2287 · 2025-01-24T23:07:51.000-05:00
In these cases two backticks must be used instead of one.

Change-Id: I85b00742a06ad1137a2d8f761432af97338995bb
Signed-off-by: Doug Goldstein &lt;cardoe@cardoe.com&gt;
diff --git a/doc/source/admin/rescue.rst b/doc/source/admin/rescue.rst
@@ -16,7 +16,7 @@ Support in ironic-python-agent images
 =====================================
 
 Rescue is initiated when ironic-conductor sends the ``finalize_rescue``
-command to ironic-python-agent. A user `rescue` is created with a password
+command to ironic-python-agent. A user ``rescue`` is created with a password
 provided as an argument to this command. DHCP is then configured to
 facilitate network connectivity, thus enabling a user to login to the machine
 in rescue mode.
@@ -34,7 +34,7 @@ DIB
 The DIB image supports rescue mode when used with DHCP tenant networks.
 
 After the ``finalize_rescue`` command completes, DHCP will be configured on all
-network interfaces, and a `rescue` user will be created with the specified
+network interfaces, and a ``rescue`` user will be created with the specified
 ``rescue_password``.
 
 TinyIPA
@@ -44,7 +44,7 @@ The TinyIPA image supports rescue mode when used with DHCP tenant networks.
 No special action is required to `build a TinyIPA image`_ with this support.
 
 After the ``finalize_rescue`` command completes, DHCP will be configured on all
-network interfaces, and a `rescue` user will be created with the specified
+network interfaces, and a ``rescue`` user will be created with the specified
 ``rescue_password``.
 
 .. _build a TinyIPA image: https://docs.openstack.org/ironic-python-agent-builder/latest/admin/tinyipa.html
diff --git a/doc/source/admin/troubleshooting.rst b/doc/source/admin/troubleshooting.rst
@@ -277,6 +277,6 @@ Edit /etc/ironic_python_agent/ironic_python_agent.conf and set the parameter
 
 References
 ==========
-.. [0] `Dynamic-login DIB element`: https://github.com/openstack/diskimage-builder/tree/master/diskimage_builder/elements/dynamic-login
-.. [1] `DevUser DIB element`: https://github.com/openstack/diskimage-builder/tree/master/diskimage_builder/elements/devuser
-.. [2] `ironic-python-agent-builder`: https://docs.openstack.org/ironic-python-agent-builder/latest/install/index.html
+.. [0] Dynamic-login DIB element: https://github.com/openstack/diskimage-builder/tree/master/diskimage_builder/elements/dynamic-login
+.. [1] DevUser DIB element: https://github.com/openstack/diskimage-builder/tree/master/diskimage_builder/elements/devuser
+.. [2] ironic-python-agent-builder: https://docs.openstack.org/ironic-python-agent-builder/latest/install/index.html
diff --git a/doc/source/contributor/hardware_managers.rst b/doc/source/contributor/hardware_managers.rst
@@ -21,11 +21,11 @@ How are methods executed on HardwareManagers?
 ---------------------------------------------
 Methods that modify hardware are dispatched to each hardware manager in
 priority order. When a method is dispatched, if a hardware manager does not
-have a method by that name or raises `IncompatibleHardwareMethodError`, IPA
+have a method by that name or raises ``IncompatibleHardwareMethodError``, IPA
 continues on to the next hardware manager. Any hardware manager that returns
 a result from the method call is considered a success and its return value
 passed on to whatever dispatched the method. If the method is unable to run
-successfully on any hardware managers, `HardwareManagerMethodNotFound` is
+successfully on any hardware managers, ``HardwareManagerMethodNotFound`` is
 raised.
 
 Why build a custom HardwareManager?
@@ -65,11 +65,11 @@ in :ironic-doc:`Ironic Cleaning </admin/cleaning.html>`. A node will perform
 a set of cleaning steps any time the node is deleted by a tenant or moved from
 ``manageable`` state to ``available`` state. Ironic will query
 IPA for a list of clean steps that should be executed on the node. IPA
-will dispatch a call to `get_clean_steps()` on all available hardware managers
-and then return the combined list to Ironic.
+will dispatch a call to ``get_clean_steps()`` on all available hardware
+managers and then return the combined list to Ironic.
 
 To expose extra clean steps, the custom hardware manager should have a function
-named `get_clean_steps()` which returns a list of dictionaries. The
+named ``get_clean_steps()`` which returns a list of dictionaries. The
 dictionaries should be in the form:
 
 .. code-block:: python
@@ -89,18 +89,18 @@ dictionaries should be in the form:
             }
         ]
 
-Then, you should create functions which match each of the `step` keys in
-the clean steps you return. The functions will take two parameters: `node`,
-a dictionary representation of the Ironic node, and `ports`, a list of
-dictionary representations of the Ironic ports attached to `node`.
+Then, you should create functions which match each of the ``step`` keys in
+the clean steps you return. The functions will take two parameters: ``node``,
+a dictionary representation of the Ironic node, and ``ports``, a list of
+dictionary representations of the Ironic ports attached to ``node``.
 
-When a clean step is executed in IPA, the `step` key will be sent to the
+When a clean step is executed in IPA, the ``step`` key will be sent to the
 hardware managers in hardware support order, using
-`hardware.dispatch_to_managers()`. For each hardware manager, if the manager
-has a function matching the `step` key, it will be executed. If the function
+``hardware.dispatch_to_managers()``. For each hardware manager, if the manager
+has a function matching the ``step`` key, it will be executed. If the function
 returns a value (including None), that value is returned to Ironic and no
 further managers are called. If the function raises
-`IncompatibleHardwareMethodError`, the next manager will be called. If the
+``IncompatibleHardwareMethodError``, the next manager will be called. If the
 function raises any other exception, the command will be considered failed,
 the command result's error message will be set to the exception's error
 message, and no further managers will be called. An example step:
@@ -159,7 +159,7 @@ function with extra parameters.
 
 .. note::
 
-    If two managers return steps with the same `step` key, the priority will
+    If two managers return steps with the same ``step`` key, the priority will
     be set to whichever manager has a higher hardware support level and then
     use the higher priority in the case of a tie.
 
@@ -319,10 +319,10 @@ Priority
 ~~~~~~~~
 A hardware manager has a single overall priority, which should be based on how
 well it supports a given piece of hardware. At load time, IPA executes
-`evaluate_hardware_support()` on each hardware manager. This method should
+``evaluate_hardware_support()`` on each hardware manager. This method should
 return an int representing hardware manager priority, based on what it detects
 about the platform it's running on. Suggested values are included in the
-`HardwareSupport` class. Returning a value of 0 aka `HardwareSupport.NONE`,
+``HardwareSupport`` class. Returning a value of 0 aka ``HardwareSupport.NONE``,
 will prevent the hardware manager from being used. IPA will never ship a
 hardware manager with a priority higher than 3, aka
-`HardwareSupport.SERVICE_PROVIDER`.
+``HardwareSupport.SERVICE_PROVIDER``.
