Some documentaion improvements for ironic docs
The documentation contains a significant amount of grammar mistakes. This could cause confusion in certain scenarios to correctly understanding the context. Starting to go though the documentation and pushing this commit as a start. Change-Id: If2c18909a83ba501b5ffae494934fb631b009e54
This commit is contained in:
Muhammad Ahmad
parent
3d1422fb7b
commit
c316443c94
@ -26,7 +26,7 @@ The expected workflow is as follows:
|
||||
power only requires to be able to connect to the agent.
|
||||
|
||||
#. The operator moves the node to `available`. Cleaning happens normally via
|
||||
the already running agent. If reboot is needed, it is done by telling the
|
||||
the already running agent. If a reboot is needed, it is done by telling the
|
||||
agent to reboot the node in-band.
|
||||
|
||||
#. A user deploys the node. Deployment happens normally via the already
|
||||
@ -70,7 +70,7 @@ Limitations
|
||||
|
||||
* Undeploy and rescue are not supported, you need to add BMC credentials first.
|
||||
|
||||
* If any errors happens in the process, recovery will likely require BMC
|
||||
* If any errors happen in the process, recovery will likely require BMC
|
||||
credentials.
|
||||
|
||||
* Only rebooting is possible through the API, power on/off commands will fail.
|
||||
|
||||
@ -25,26 +25,26 @@ How it works
|
||||
|
||||
These tokens are provided in one of two ways to the running agent.
|
||||
|
||||
1. A pre-generated token which is embedded into virtual media ISOs.
|
||||
2. A one-time generated token that are provided upon the first "lookup"
|
||||
1. A pre-generated token that is embedded into virtual media ISOs.
|
||||
2. A one-time generated token that is provided upon the first "lookup"
|
||||
of the node.
|
||||
|
||||
In both cases, the tokens are a randomly generated using the Python
|
||||
In both cases, the tokens are randomly generated using the Python
|
||||
``secrets`` library. As of mid-2020, the default length is 43 characters.
|
||||
|
||||
Once the token has been provided, the token cannot be retrieved or accessed.
|
||||
It remains available to the conductors, and is stored in memory of the
|
||||
It remains available to the conductors, and is stored in the memory of the
|
||||
``ironic-python-agent``.
|
||||
|
||||
.. note::
|
||||
In the case of the token being embedded with virtual media, it is read
|
||||
from a configuration file with-in the image. Ideally this should be paired
|
||||
from a configuration file within the image. Ideally, this should be paired
|
||||
with Swift temporary URLs.
|
||||
|
||||
With the token is available in memory in the agent, the token is embedded with
|
||||
``heartbeat`` operations to the ironic API endpoint. This enables the API to
|
||||
authenticate the heartbeat request, and refuse "heartbeat" requests from the
|
||||
``ironic-python-agent``. As of the Victoria release, use of Agent Token is
|
||||
``ironic-python-agent``. As of the Victoria release, the use of Agent Token is
|
||||
required for all agents and the previously available setting to force this
|
||||
functionality to be mandatory, ``[DEFAULT]require_agent_token`` has been removed
|
||||
and no longer has any effect.
|
||||
@ -73,7 +73,7 @@ With PXE/iPXE/etc.
|
||||
Agent Configuration
|
||||
===================
|
||||
|
||||
An additional setting which may be leveraged with the ``ironic-python-agent``
|
||||
An additional setting that may be leveraged with the ``ironic-python-agent``
|
||||
is a ``agent_token_required`` setting. Under normal circumstances, this
|
||||
setting can be asserted via the configuration supplied from the Bare Metal
|
||||
service deployment upon the ``lookup`` action, but can be asserted via the
|
||||
|
||||
@ -64,7 +64,7 @@ package groups that need to be in the image:
|
||||
install cloud-init
|
||||
ts run
|
||||
|
||||
An OS tarball can be created using following set of commands, along with the above
|
||||
An OS tarball can be created using the following set of commands, along with the above
|
||||
``baremetal.yum`` file:
|
||||
|
||||
.. code-block:: shell
|
||||
@ -155,12 +155,12 @@ ironic node:
|
||||
|
||||
.. warning::
|
||||
In the Ironic Project terminology, the word ``template`` often refers to
|
||||
a file which is supplied to the deployment, which Ironic supplies
|
||||
a file that is supplied to the deployment, which Ironic supplies
|
||||
parameters to render a specific output. One critical example of this in
|
||||
the Ironic workflow, specifically with this driver, is that the generated
|
||||
``agent token`` is conveyed to the booting ramdisk, facilitating it to call
|
||||
back to Ironic and indicate the state. This token is randomly generated
|
||||
for every deploy, and is required. Specifically this is leveraged in the
|
||||
for every deploy, and is required. Specifically, this is leveraged in the
|
||||
template's ``pre``, ``onerror``, and ``post`` steps.
|
||||
For more information on Agent Token, please see :doc:`/admin/agent-token`.
|
||||
|
||||
@ -168,7 +168,7 @@ Standalone deployments
|
||||
----------------------
|
||||
|
||||
While this deployment interface driver was developed around the use of other
|
||||
OpenStack services, it is not explicitly required. For example HTTP(S) URLs
|
||||
OpenStack services, it is not explicitly required. For example, HTTP(S) URLs
|
||||
can be supplied by the API user to explicitly set the expected baremetal node
|
||||
``instance_info`` fields
|
||||
|
||||
@ -182,7 +182,7 @@ can be supplied by the API user to explicitly set the expected baremetal node
|
||||
|
||||
When doing so, you may wish to also utilize a customized kickstart template,
|
||||
which can also be a URL. Please reference the ironic community provided
|
||||
template *ks.cfg.template* and use it as a basis of your own kickstart
|
||||
template *ks.cfg.template* and use it as a basis for your own kickstart
|
||||
as it accounts for the particular stages and appropriate callbacks to
|
||||
Ironic.
|
||||
|
||||
@ -252,7 +252,7 @@ parameter, and the node deployed.
|
||||
Deployment Process
|
||||
------------------
|
||||
|
||||
At a high level, the mechanics of the anaconda driver works in the following
|
||||
At a high level, the mechanics of the anaconda driver work in the following
|
||||
flow, where we also note the stages and purpose of each part for informational
|
||||
purposes.
|
||||
|
||||
@ -281,16 +281,16 @@ based deployments, but the way the anaconda deployment interface works,
|
||||
you may need to make some adjustments.
|
||||
|
||||
* :oslo.config:option:`conductor.deploy_callback_timeout` likely needs to be adjusted
|
||||
for most ``anaconda`` deployment interface users. By default this
|
||||
is a timer which looks for "agents" which have not checked in with
|
||||
for most ``anaconda`` deployment interface users. By default, this
|
||||
is a timer that looks for "agents" that have not checked in with
|
||||
Ironic, or agents which may have crashed or failed after they
|
||||
started. If the value is reached, then the current operation is failed.
|
||||
This value should be set to a number of seconds which exceeds your
|
||||
average anaconda deployment time.
|
||||
* :oslo.config:option:`pxe.boot_retry_timeout` can also be triggered and result in
|
||||
an anaconda deployment in progress getting reset as it is intended
|
||||
to reboot nodes which might have failed their initial PXE operation.
|
||||
Depending on sizes of images, and the exact nature of what was deployed,
|
||||
to reboot nodes that might have failed their initial PXE operation.
|
||||
Depending on the sizes of images, and the exact nature of what was deployed,
|
||||
it may be necessary to ensure this is a much higher value.
|
||||
|
||||
Limitations
|
||||
|
||||
@ -4,8 +4,8 @@
|
||||
API Audit Logging
|
||||
=================
|
||||
|
||||
Audit middleware supports delivery of CADF audit events via Oslo messaging
|
||||
notifier capability. Based on `notification_driver` configuration, audit events
|
||||
Audit middleware supports the delivery of CADF audit events via the Oslo messaging
|
||||
notifier capability. Based on the `notification_driver` configuration, audit events
|
||||
can be routed to messaging infrastructure (notification_driver = messagingv2)
|
||||
or can be routed to a log file (`[oslo_messaging_notifications]/driver = log`).
|
||||
|
||||
@ -30,17 +30,17 @@ to ``/etc/ironic/ironic.conf``.
|
||||
enabled=true
|
||||
|
||||
#. To customize auditing API requests, the audit middleware requires the audit_map_file setting
|
||||
to be defined. Update the value of configuration setting 'audit_map_file' to set its
|
||||
to be defined. Update the value of the configuration setting 'audit_map_file' to set its
|
||||
location. Audit map file configuration options for the Bare Metal service are included
|
||||
in the etc/ironic/ironic_api_audit_map.conf.sample file. To understand CADF format
|
||||
specified in ironic_api_audit_map.conf file refer to `CADF Format.
|
||||
specified in ironic_api_audit_map.conf file, refer to `CADF Format.
|
||||
<http://www.dmtf.org/sites/default/files/standards/documents/DSP2038_1.0.0.pdf>`_::
|
||||
|
||||
[audit]
|
||||
...
|
||||
audit_map_file=/etc/ironic/api_audit_map.conf
|
||||
|
||||
#. Comma separated list of Ironic REST API HTTP methods to be ignored during audit.
|
||||
#. Comma-separated list of Ironic REST API HTTP methods to be ignored during audit.
|
||||
It is used only when API audit is enabled. For example::
|
||||
|
||||
[audit]
|
||||
@ -50,7 +50,7 @@ to ``/etc/ironic/ironic.conf``.
|
||||
Sample Audit Event
|
||||
==================
|
||||
|
||||
Following is the sample of audit event for ironic node list request.
|
||||
Following is the sample of the audit event for the ironic node list request.
|
||||
|
||||
.. code-block:: json
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user