openstack/ironic
Code Issues Proposed changes

Fix indentation in few of the documentation pages

Browse Source 
Partial-Bug: #1712860
Change-Id: Id467f5a917e61643823a9d82faa94516ea250f43
This commit is contained in:
Shivanand Tendulker 2017-08-25 09:22:39 -04:00
parent d6451b6dab
commit cb793d0136
12 changed files with 274 additions and 267 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
doc/source/admin/api-audit-support.rst
View File

@ -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]
...

12
doc/source/admin/drivers/ilo.rst
View File

@ -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

1
doc/source/admin/security.rst
View File

@ -117,5 +117,6 @@ include:
- disabling modifications to boot settings from the host OS
Additional references:
- :ref:`cleaning`
- :ref:`trusted-boot`

2
doc/source/contributor/architecture.rst
View File

@ -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`:

76
doc/source/contributor/code-contribution-guide.rst
View File

@ -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:
https://docs.openstack.org/nova/latest/user/upgrade.html
Ironic implements upgrade with the `same methodology as Nova <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
need to be considered:
When the signature(arguments) of an RPC method is changed, the following
things need to be considered:
- The RPC version must be incremented and be the same value for both the client
(conductor/rpcapi.py, used by ironic-api) and the server (conductor/manager.py,
used by ironic-conductor).
- New arguments of the method can only be added as optional. Existing arguments cannot be
removed or changed in incompatible ways (with the method in older RPC versions).
- Client-side can pin a version cap by passing ``version_cap`` to the constructor
of oslo_messaging.RPCClient. Methods which change arguments should run
client.can_send_version() to see if the version of the request is compatible with the
version cap of RPC Client, otherwise the request needs to be created to work with a
previous version that is supported.
- The RPC version must be incremented and be the same value for both the
client (conductor/rpcapi.py, used by ironic-api) and the server
(conductor/manager.py, used by ironic-conductor).
- New arguments of the method can only be added as optional. Existing
arguments cannot be removed or changed in incompatible ways (with the
method in older RPC versions).
- Client-side can pin a version cap by passing ``version_cap`` to the
constructor of oslo_messaging.RPCClient. Methods which change arguments
should run client.can_send_version() to see if the version of the request
is compatible with the version cap of RPC Client, otherwise the request
needs to be created to work with a previous version that is supported.
- Server-side should tolerate the older version of requests in order to keep
working during the progress of live upgrade. The behavior of server-side should
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
following things need to be considered:
When Object classes (subclasses of ironic.objects.base.IronicObject) are
modified, the following things need to be considered:
- The change of fields and the signature of remotable method needs a bump of object
version.
- The change of fields and the signature of remotable method needs a bump of
object version.
- 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
deprecate the old one.
- When new version objects communicate with old version objects,
obj_make_compatible() will be called to convert objects to the target version during
serialization. So objects should implement their own obj_make_compatible() to
remove/alter attributes which was added/changed after the target version.
- There is a test (object/test_objects.py) to generate the hash of object fields and the
signatures of remotable methods, which helps developers to check if the change of
objects need a version bump. The object fingerprint should only be updated with a
version bump.
obj_make_compatible() will be called to convert objects to the target
version during serialization. So objects should implement their own
obj_make_compatible() to remove/alter attributes which was added/changed
after the target version.
- There is a test (object/test_objects.py) to generate the hash of object
fields and the signatures of remotable methods, which helps developers to
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_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.
* ``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.
* 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.
* ``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,10 +256,12 @@ Changes to existing specs
-------------------------
For approved but not-completed specs:
- 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
for cosmetic cleanup or fixing errors.
- changing the definition of the feature should be done in a new spec.

8
doc/source/contributor/osprofiler-support.rst
View File

@ -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::

2
doc/source/contributor/releasing.rst
View File

@ -60,6 +60,7 @@ 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.
@ -110,6 +111,7 @@ 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