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 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.
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] [audit]
... ...

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

@ -114,16 +114,16 @@ The ``ilo`` hardware type supports following hardware interfaces:
The following command can be used to enroll a ProLiant node with The following command can be used to enroll a ProLiant node with
``ilo`` hardware type: ``ilo`` hardware type:
.. code-block:: console .. code-block:: console
openstack baremetal node create --os-baremetal-api-version=1.31 \ openstack baremetal node create --os-baremetal-api-version=1.31 \
--driver ilo \ --driver ilo \
--deploy-interface direct \ --deploy-interface direct \
--raid-interface agent \ --raid-interface agent \
--driver-info ilo_address=<ilo-ip-address> \ --driver-info ilo_address=<ilo-ip-address> \
--driver-info ilo_username=<ilo-username> \ --driver-info ilo_username=<ilo-username> \
--driver-info ilo_password=<ilo-password> \ --driver-info ilo_password=<ilo-password> \
--driver-info ilo_deploy_iso=<glance-uuid-of-deploy-iso> --driver-info ilo_deploy_iso=<glance-uuid-of-deploy-iso>
Please refer to :doc:`/install/enabling-drivers` for detailed Please refer to :doc:`/install/enabling-drivers` for detailed
explanation of hardware type. explanation of hardware type.
@ -131,16 +131,16 @@ explanation of hardware type.
To enable the same feature set as provided by all iLO classic drivers, To enable the same feature set as provided by all iLO classic drivers,
apply the following configuration: apply the following configuration:
.. code-block:: ini .. code-block:: ini
[DEFAULT] [DEFAULT]
enabled_hardware_types = ilo enabled_hardware_types = ilo
enabled_boot_interfaces = ilo-virtual-media,ilo-pxe enabled_boot_interfaces = ilo-virtual-media,ilo-pxe
enabled_power_interfaces = ilo enabled_power_interfaces = ilo
enabled_console_interfaces = ilo enabled_console_interfaces = ilo
enabled_raid_interfaces = agent enabled_raid_interfaces = agent
enabled_management_interfaces = ilo enabled_management_interfaces = ilo
enabled_inspect_interfaces = ilo enabled_inspect_interfaces = ilo
The following commands can be used to enroll a node with the same The following commands can be used to enroll a node with the same
feature set as one of the classic drivers, but using the ``ilo`` feature set as one of the classic drivers, but using the ``ilo``
@ -148,43 +148,43 @@ hardware type:
* ``iscsi_ilo``: * ``iscsi_ilo``:
.. code-block:: console .. code-block:: console
openstack baremetal node create --os-baremetal-api-version=1.31 \ openstack baremetal node create --os-baremetal-api-version=1.31 \
--driver ilo \ --driver ilo \
--deploy-interface iscsi \ --deploy-interface iscsi \
--boot-interface ilo-virtual-media \ --boot-interface ilo-virtual-media \
--driver-info ilo_address=<ilo-ip-address> \ --driver-info ilo_address=<ilo-ip-address> \
--driver-info ilo_username=<ilo-username> \ --driver-info ilo_username=<ilo-username> \
--driver-info ilo_password=<ilo-password> \ --driver-info ilo_password=<ilo-password> \
--driver-info ilo_deploy_iso=<glance-uuid-of-deploy-iso> --driver-info ilo_deploy_iso=<glance-uuid-of-deploy-iso>
* ``pxe_ilo``: * ``pxe_ilo``:
.. code-block:: console .. code-block:: console
openstack baremetal node create --os-baremetal-api-version=1.31 \ openstack baremetal node create --os-baremetal-api-version=1.31 \
--driver ilo \ --driver ilo \
--deploy-interface iscsi \ --deploy-interface iscsi \
--boot-interface ilo-pxe \ --boot-interface ilo-pxe \
--driver-info ilo_address=<ilo-ip-address> \ --driver-info ilo_address=<ilo-ip-address> \
--driver-info ilo_username=<ilo-username> \ --driver-info ilo_username=<ilo-username> \
--driver-info ilo_password=<ilo-password> \ --driver-info ilo_password=<ilo-password> \
--driver-info deploy_kernel=<glance-uuid-of-pxe-deploy-kernel> \ --driver-info deploy_kernel=<glance-uuid-of-pxe-deploy-kernel> \
--driver-info deploy_ramdisk=<glance-uuid-of-deploy-ramdisk> --driver-info deploy_ramdisk=<glance-uuid-of-deploy-ramdisk>
* ``agent_ilo``: * ``agent_ilo``:
.. code-block:: console .. code-block:: console
openstack baremetal node create --os-baremetal-api-version=1.31 \ openstack baremetal node create --os-baremetal-api-version=1.31 \
--driver ilo \ --driver ilo \
--deploy-interface direct \ --deploy-interface direct \
--boot-interface ilo-virtual-media \ --boot-interface ilo-virtual-media \
--driver-info ilo_address=<ilo-ip-address> \ --driver-info ilo_address=<ilo-ip-address> \
--driver-info ilo_username=<ilo-username> \ --driver-info ilo_username=<ilo-username> \
--driver-info ilo_password=<ilo-password> \ --driver-info ilo_password=<ilo-password> \
--driver-info ilo_deploy_iso=<glance-uuid-of-deploy-iso> --driver-info ilo_deploy_iso=<glance-uuid-of-deploy-iso>
Prerequisites Prerequisites
============= =============
@ -228,14 +228,14 @@ Glance Configuration
swift_account=AUTH_51ea2fb400c34c9eb005ca945c0dc9e1 swift_account=AUTH_51ea2fb400c34c9eb005ca945c0dc9e1
swift_container=glance swift_container=glance
The details can be retrieved by running the below command: The details can be retrieved by running the below command:
.. code-block:: bash .. code-block:: bash
$ swift --os-username=service:glance-swift stat -v | grep -i url $ swift --os-username=service:glance-swift stat -v | grep -i url
StorageURL: http://10.10.1.10:8080/v1/AUTH_51ea2fb400c34c9eb005ca945c0dc9e1 StorageURL: http://10.10.1.10:8080/v1/AUTH_51ea2fb400c34c9eb005ca945c0dc9e1
Meta Temp-Url-Key: mysecretkeyforglance Meta Temp-Url-Key: mysecretkeyforglance
4. Swift must be accessible with the same admin credentials configured in 4. Swift must be accessible with the same admin credentials configured in
@ -966,21 +966,21 @@ Supported **Automated** Cleaning Operations
* The automated cleaning operations supported are: * 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 Resets system ROM settings to default. By default, enabled with priority
10. This clean step is supported only on Gen9 and above servers. 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 Resets secure boot keys to manufacturer's defaults. This step is supported
only on Gen9 and above servers. By default, enabled with priority 20 . 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 Resets the iLO password, if ``ilo_change_password`` is specified as part of
node's driver_info. By default, enabled with priority 30. 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 Clears all secure boot keys. This step is supported only on Gen9 and above
servers. By default, this step is disabled. servers. By default, this step is disabled.
``reset_ilo``: * ``reset_ilo``:
Resets the iLO. By default, this step is disabled. 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 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 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 Storage Administrator (SSA). This step supports erasing of the raw disks
@ -1632,14 +1632,14 @@ step could be::
The different attributes of ``activate_license`` clean step are as follows: The different attributes of ``activate_license`` clean step are as follows:
.. csv-table:: .. csv-table::
:header: "Attribute", "Description" :header: "Attribute", "Description"
:widths: 30, 120 :widths: 30, 120
"``interface``", "Interface of clean step, here ``management``" "``interface``", "Interface of clean step, here ``management``"
"``step``", "Name of clean step, here ``activate_license``" "``step``", "Name of clean step, here ``activate_license``"
"``args``", "Keyword-argument entry (<name>: <value>) being passed to clean step" "``args``", "Keyword-argument entry (<name>: <value>) being passed to clean step"
"``args.ilo_license_key``", "iLO Advanced license key to activate enterprise features. This is mandatory." "``args.ilo_license_key``", "iLO Advanced license key to activate enterprise features. This is mandatory."
Initiating firmware update as manual clean step Initiating firmware update as manual clean step
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@ -1689,15 +1689,15 @@ step could be::
The different attributes of ``update_firmware`` clean step are as follows: The different attributes of ``update_firmware`` clean step are as follows:
.. csv-table:: .. csv-table::
:header: "Attribute", "Description" :header: "Attribute", "Description"
:widths: 30, 120 :widths: 30, 120
"``interface``", "Interface of clean step, here ``management``" "``interface``", "Interface of clean step, here ``management``"
"``step``", "Name of clean step, here ``update_firmware``" "``step``", "Name of clean step, here ``update_firmware``"
"``args``", "Keyword-argument entry (<name>: <value>) being passed to clean step" "``args``", "Keyword-argument entry (<name>: <value>) being passed to clean step"
"``args.firmware_update_mode``", "Mode (or mechanism) of out-of-band firmware update. Supported value is ``ilo``. This is mandatory." "``args.firmware_update_mode``", "Mode (or mechanism) of out-of-band firmware update. Supported value is ``ilo``. This is mandatory."
"``args.firmware_images``", "Ordered list of dictionaries of images to be flashed. This is mandatory." "``args.firmware_images``", "Ordered list of dictionaries of images to be flashed. This is mandatory."
Each firmware image block is represented by a dictionary (JSON), in the form:: Each firmware image block is represented by a dictionary (JSON), in the form::
@ -1712,22 +1712,22 @@ All the fields in the firmware image block are mandatory.
* The different types of firmware url schemes supported are: * The different types of firmware url schemes supported are:
``file``, ``http``, ``https`` and ``swift``. ``file``, ``http``, ``https`` and ``swift``.
.. note:: .. note::
This feature assumes that while using ``file`` url scheme the file path is This feature assumes that while using ``file`` url scheme the file path is
on the conductor controlling the node. on the conductor controlling the node.
.. note:: .. note::
The ``swift`` url scheme assumes the swift account of the ``service`` The ``swift`` url scheme assumes the swift account of the ``service``
project. The ``service`` project (tenant) is a special project created in project. The ``service`` project (tenant) is a special project created in
the Keystone system designed for the use of the core OpenStack services. the Keystone system designed for the use of the core OpenStack services.
When Ironic makes use of Swift for storage purpose, the account is generally When Ironic makes use of Swift for storage purpose, the account is generally
``service`` and the container is generally ``ironic`` and ``ilo`` drivers ``service`` and the container is generally ``ironic`` and ``ilo`` drivers
use a container named ``ironic_ilo_container`` for their own purpose. 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 While using firmware files with a ``.rpm`` extension, make sure the commands
``rpm2cpio`` and ``cpio`` are present on the conductor, as they are utilized ``rpm2cpio`` and ``cpio`` are present on the conductor, as they are utilized
to extract the firmware image from the package. to extract the firmware image from the package.
* The firmware components that can be updated are: * The firmware components that can be updated are:
``ilo``, ``cpld``, ``power_pic``, ``bios`` and ``chassis``. ``ilo``, ``cpld``, ``power_pic``, ``bios`` and ``chassis``.

6
doc/source/admin/drivers/pxe.rst
View File

@ -18,9 +18,9 @@ Enable persistent boot device on node
$ openstack baremetal node set --driver-info force_persistent_boot_device=True <node> $ openstack baremetal node set --driver-info force_persistent_boot_device=True <node>
.. note:: .. note::
It's recommended to check if the node's state has not changed as there It's recommended to check if the node's state has not changed as there
is no way of locking the node between these commands. is no way of locking the node between these commands.
Once the flag is present, the next cleaning and deploy steps will be done Once the flag is present, the next cleaning and deploy steps will be done
with persistent boot for that node. with persistent boot for that node.

6
doc/source/admin/drivers/snmp.rst
View File

@ -99,10 +99,10 @@ Enabling the SNMP Power Driver
to boot using ``netboot`` by setting its ``capabilities`` and updating to boot using ``netboot`` by setting its ``capabilities`` and updating
Nova flavor as described below: Nova flavor as described below:
.. code-block:: console .. code-block:: console
openstack baremetal node set --property capabilities="boot_option:netboot" <node-uuid> openstack baremetal node set --property capabilities="boot_option:netboot" <node-uuid>
openstack flavor set --property "capabilities:boot_option"="netboot" ironic-flavor openstack flavor set --property "capabilities:boot_option"="netboot" ironic-flavor
#. Restart the Ironic conductor service. #. Restart the Ironic conductor service.

12
doc/source/admin/raid.rst
View File

@ -136,12 +136,12 @@ The RAID properties can be split into 4 different types:
- ``physical_disks`` - A list of physical disks to use as read by the - ``physical_disks`` - A list of physical disks to use as read by the
driver. driver.
.. note:: .. note::
If properties from both "Backing physical disk hints" or If properties from both "Backing physical disk hints" or
"Backing physical disks" are specified, they should be consistent with "Backing physical disks" are specified, they should be consistent with
each other. If they are not consistent, then the RAID configuration each other. If they are not consistent, then the RAID configuration
will fail (because the appropriate backing physical disks could will fail (because the appropriate backing physical disks could
not be found). not be found).
Examples for ``target_raid_config`` Examples for ``target_raid_config``
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

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

@ -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 proper firmware security measures are put in place ahead of time. This could
include: 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 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: Additional references:
- :ref:`cleaning`
- :ref:`trusted-boot` - :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`_. built which contains one of these agents, eg. with `diskimage-builder`_.
This ramdisk can be booted on-demand. 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`: .. _`architecture_drivers`:

98
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 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 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 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. 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. 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 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. 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: 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. * ``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. * ``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. * ``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 * ``is_next_boot_persistent``: A Boolean value to indicate whether the next boot device is
``persistent_boot_device``. ``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:: .. note::
@ -252,13 +256,15 @@ Changes to existing specs
------------------------- -------------------------
For approved but not-completed specs: For approved but not-completed specs:
- cosmetic cleanup, fixing errors, and changing the definition of a feature
can be done to the spec. - cosmetic cleanup, fixing errors, and changing the definition of a feature
can be done to the spec.
For approved and completed specs: For approved and completed specs:
- changing a previously approved and completed spec should only be done
for cosmetic cleanup or fixing errors. - changing a previously approved and completed spec should only be done
- changing the definition of the feature should be done in a new spec. for cosmetic cleanup or fixing errors.
- 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/ Please see the `Ironic specs process wiki page <https://wiki.openstack.org/

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 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:: Output of the above command will include the following::

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

@ -60,59 +60,61 @@ 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
------------------------------------------------------ ------------------------------------------------------
When a release is done that results in a stable branch for the project, the 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. release automation will push a number of changes that need to be approved.
In the new stable branch, this will include: 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: 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: 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 An example of this patch is
`here <https://review.openstack.org/#/c/374863/>`_. `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. 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. 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 TEMPEST_BAREMETAL_MAX_MICROVERSION in devstack/lib/ironic to make sure that
unsupported API tempest tests are skipped on stable branches. unsupported API tempest tests are skipped on stable branches.
Additionally, changes need to be made on master to: 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 version. See `example
<https://git.openstack.org/cgit/openstack/ironic/commit/?id=4b28af4645c2f3b6d7864671e15904ed8f40414d>`_ <https://git.openstack.org/cgit/openstack/ironic/commit/?id=4b28af4645c2f3b6d7864671e15904ed8f40414d>`_
and `pbr documentation and `pbr documentation
<https://docs.openstack.org/pbr/latest/user/features.html#version>`_ for details. <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 * In ironic/common/release_mappings.py, delete any entries from RELEASE_MAPPING
associated with the oldest named release. Since we support upgrades between associated with the oldest named release. Since we support upgrades between
adjacent named releases, the master branch will only support upgrades from adjacent named releases, the master branch will only support upgrades from
the most recent named release to master. the most recent named release to master.
* regenerate the sample config file, so that the choices for the * regenerate the sample config file, so that the choices for the
``[DEFAULT]/pin_release_version`` configuration are accurate. ``[DEFAULT]/pin_release_version`` configuration are accurate.
* remove any DB migration scripts from ironic.cmd.dbsync.ONLINE_MIGRATIONS * remove any DB migration scripts from ironic.cmd.dbsync.ONLINE_MIGRATIONS
and remove the corresponding code from ironic. (These migration scripts and remove the corresponding code from ironic. (These migration scripts
are used to migrate from an old release to this latest release; they are used to migrate from an old release to this latest release; they
shouldn't be needed after that.) shouldn't be needed after that.)
For all releases For all releases
---------------- ----------------
For all releases, whether or not it results in a stable branch: 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. 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.

150
doc/source/install/configure-compute.rst
View File

@ -23,66 +23,66 @@ service's controller nodes and compute nodes.
#. Change these configuration options in the ``default`` section, as follows: #. Change these configuration options in the ``default`` section, as follows:
.. code-block:: ini .. code-block:: ini
[default] [default]
# Driver to use for controlling virtualization. Options # Driver to use for controlling virtualization. Options
# include: libvirt.LibvirtDriver, xenapi.XenAPIDriver, # include: libvirt.LibvirtDriver, xenapi.XenAPIDriver,
# fake.FakeDriver, baremetal.BareMetalDriver, # fake.FakeDriver, baremetal.BareMetalDriver,
# vmwareapi.VMwareESXDriver, vmwareapi.VMwareVCDriver (string # vmwareapi.VMwareESXDriver, vmwareapi.VMwareVCDriver (string
# value) # value)
#compute_driver=<None> #compute_driver=<None>
compute_driver=ironic.IronicDriver compute_driver=ironic.IronicDriver
# Firewall driver (defaults to hypervisor specific iptables # Firewall driver (defaults to hypervisor specific iptables
# driver) (string value) # driver) (string value)
#firewall_driver=<None> #firewall_driver=<None>
firewall_driver=nova.virt.firewall.NoopFirewallDriver firewall_driver=nova.virt.firewall.NoopFirewallDriver
# The scheduler host manager class to use (string value) # The scheduler host manager class to use (string value)
#scheduler_host_manager=host_manager #scheduler_host_manager=host_manager
scheduler_host_manager=ironic_host_manager scheduler_host_manager=ironic_host_manager
# Virtual ram to physical ram allocation ratio which affects # Virtual ram to physical ram allocation ratio which affects
# all ram filters. This configuration specifies a global ratio # all ram filters. This configuration specifies a global ratio
# for RamFilter. For AggregateRamFilter, it will fall back to # for RamFilter. For AggregateRamFilter, it will fall back to
# this configuration value if no per-aggregate setting found. # this configuration value if no per-aggregate setting found.
# (floating point value) # (floating point value)
#ram_allocation_ratio=1.5 #ram_allocation_ratio=1.5
ram_allocation_ratio=1.0 ram_allocation_ratio=1.0
# Amount of disk in MB to reserve for the host (integer value) # Amount of disk in MB to reserve for the host (integer value)
#reserved_host_disk_mb=0 #reserved_host_disk_mb=0
reserved_host_memory_mb=0 reserved_host_memory_mb=0
# Determines if the Scheduler tracks changes to instances to help with # Determines if the Scheduler tracks changes to instances to help with
# its filtering decisions (boolean value) # its filtering decisions (boolean value)
#scheduler_tracks_instance_changes=True #scheduler_tracks_instance_changes=True
scheduler_tracks_instance_changes=False scheduler_tracks_instance_changes=False
# New instances will be scheduled on a host chosen randomly from a subset # New instances will be scheduled on a host chosen randomly from a subset
# of the N best hosts, where N is the value set by this option. Valid # of the N best hosts, where N is the value set by this option. Valid
# values are 1 or greater. Any value less than one will be treated as 1. # values are 1 or greater. Any value less than one will be treated as 1.
# For ironic, this should be set to a number >= the number of ironic nodes # For ironic, this should be set to a number >= the number of ironic nodes
# to more evenly distribute instances across the nodes. # to more evenly distribute instances across the nodes.
#scheduler_host_subset_size=1 #scheduler_host_subset_size=1
scheduler_host_subset_size=9999999 scheduler_host_subset_size=9999999
If you have not migrated to using :ref:`scheduling-resource-classes`, then If you have not migrated to using :ref:`scheduling-resource-classes`, then
the following should be set as well: the following should be set as well:
.. code-block:: ini .. code-block:: ini
[default] [default]
# Flag to decide whether to use baremetal_scheduler_default_filters or not. # Flag to decide whether to use baremetal_scheduler_default_filters or not.
# (boolean value) # (boolean value)
#scheduler_use_baremetal_filters=False #scheduler_use_baremetal_filters=False
scheduler_use_baremetal_filters=True scheduler_use_baremetal_filters=True
This option is deprecated and has to be unset after migration This option is deprecated and has to be unset after migration
to resource classes. to resource classes.
#. Change these configuration options in the ``ironic`` section. #. Change these configuration options in the ``ironic`` section.
Replace: Replace:
@ -92,51 +92,51 @@ service's controller nodes and compute nodes.
- ``IRONIC_NODE`` with the hostname or IP address of the ironic-api node - ``IRONIC_NODE`` with the hostname or IP address of the ironic-api node
- ``IDENTITY_IP`` with the IP of the Identity server - ``IDENTITY_IP`` with the IP of the Identity server
.. code-block:: ini .. code-block:: ini
[ironic] [ironic]
# Ironic authentication type # Ironic authentication type
auth_type=password auth_type=password
# Keystone API endpoint # Keystone API endpoint
auth_url=http://IDENTITY_IP:35357/v3 auth_url=http://IDENTITY_IP:35357/v3
# Ironic keystone project name # Ironic keystone project name
project_name=service project_name=service
# Ironic keystone admin name # Ironic keystone admin name
username=ironic username=ironic
# Ironic keystone admin password # Ironic keystone admin password
password=IRONIC_PASSWORD password=IRONIC_PASSWORD
# Ironic keystone project domain # Ironic keystone project domain
# or set project_domain_id # or set project_domain_id
project_domain_name=Default project_domain_name=Default
# Ironic keystone user domain # Ironic keystone user domain
# or set user_domain_id # or set user_domain_id
user_domain_name=Default user_domain_name=Default
#. On the Compute service's controller nodes, restart the ``nova-scheduler`` #. On the Compute service's controller nodes, restart the ``nova-scheduler``
process: process:
.. code-block:: console .. code-block:: console
Fedora/RHEL7/CentOS7/SUSE: Fedora/RHEL7/CentOS7/SUSE:
sudo systemctl restart openstack-nova-scheduler sudo systemctl restart openstack-nova-scheduler
Ubuntu: Ubuntu:
sudo service nova-scheduler restart sudo service nova-scheduler restart
#. On the Compute service's compute nodes, restart the ``nova-compute`` #. On the Compute service's compute nodes, restart the ``nova-compute``
process: process:
.. code-block:: console .. code-block:: console
Fedora/RHEL7/CentOS7/SUSE: Fedora/RHEL7/CentOS7/SUSE:
sudo systemctl restart openstack-nova-compute sudo systemctl restart openstack-nova-compute
Ubuntu: Ubuntu:
sudo service nova-compute restart sudo service nova-compute restart

2
doc/source/install/include/kernel-boot-parameters.rst
View File

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