From fbb12a2f22871e86567e20e9af16194c73feb6f0 Mon Sep 17 00:00:00 2001 From: Doug Goldstein Date: Fri, 24 Jan 2025 23:07:17 -0500 Subject: [PATCH] fix sphinx errors with incorrect backticks In these cases two backticks must be used instead of one. Change-Id: I85b00742a06ad1137a2d8f761432af97338995bb Signed-off-by: Doug Goldstein --- doc/source/admin/rescue.rst | 6 ++-- doc/source/admin/troubleshooting.rst | 6 ++-- doc/source/contributor/hardware_managers.rst | 34 ++++++++++---------- 3 files changed, 23 insertions(+), 23 deletions(-) diff --git a/doc/source/admin/rescue.rst b/doc/source/admin/rescue.rst index 8e8084266..70e519106 100644 --- 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 index ef7e02baa..575367d9d 100644 --- 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 index 23b650987..e1b15fabb 100644 --- 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 `. 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``.