Fix indentation in few of the documentation pages
Partial-Bug: #1712860 Change-Id: Id467f5a917e61643823a9d82faa94516ea250f43
This commit is contained in:
Shivanand Tendulker
parent
d6451b6dab
commit
cb793d0136
@ -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]
|
||||
...
|
||||
|
||||
@ -114,16 +114,16 @@ The ``ilo`` hardware type supports following hardware interfaces:
|
||||
The following command can be used to enroll a ProLiant node with
|
||||
``ilo`` hardware type:
|
||||
|
||||
.. code-block:: console
|
||||
.. code-block:: console
|
||||
|
||||
openstack baremetal node create --os-baremetal-api-version=1.31 \
|
||||
--driver ilo \
|
||||
--deploy-interface direct \
|
||||
--raid-interface agent \
|
||||
--driver-info ilo_address=<ilo-ip-address> \
|
||||
--driver-info ilo_username=<ilo-username> \
|
||||
--driver-info ilo_password=<ilo-password> \
|
||||
--driver-info ilo_deploy_iso=<glance-uuid-of-deploy-iso>
|
||||
openstack baremetal node create --os-baremetal-api-version=1.31 \
|
||||
--driver ilo \
|
||||
--deploy-interface direct \
|
||||
--raid-interface agent \
|
||||
--driver-info ilo_address=<ilo-ip-address> \
|
||||
--driver-info ilo_username=<ilo-username> \
|
||||
--driver-info ilo_password=<ilo-password> \
|
||||
--driver-info ilo_deploy_iso=<glance-uuid-of-deploy-iso>
|
||||
|
||||
Please refer to :doc:`/install/enabling-drivers` for detailed
|
||||
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,
|
||||
apply the following configuration:
|
||||
|
||||
.. code-block:: ini
|
||||
.. code-block:: ini
|
||||
|
||||
[DEFAULT]
|
||||
enabled_hardware_types = ilo
|
||||
enabled_boot_interfaces = ilo-virtual-media,ilo-pxe
|
||||
enabled_power_interfaces = ilo
|
||||
enabled_console_interfaces = ilo
|
||||
enabled_raid_interfaces = agent
|
||||
enabled_management_interfaces = ilo
|
||||
enabled_inspect_interfaces = ilo
|
||||
[DEFAULT]
|
||||
enabled_hardware_types = ilo
|
||||
enabled_boot_interfaces = ilo-virtual-media,ilo-pxe
|
||||
enabled_power_interfaces = ilo
|
||||
enabled_console_interfaces = ilo
|
||||
enabled_raid_interfaces = agent
|
||||
enabled_management_interfaces = ilo
|
||||
enabled_inspect_interfaces = ilo
|
||||
|
||||
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``
|
||||
@ -148,43 +148,43 @@ hardware type:
|
||||
|
||||
* ``iscsi_ilo``:
|
||||
|
||||
.. code-block:: console
|
||||
.. code-block:: console
|
||||
|
||||
openstack baremetal node create --os-baremetal-api-version=1.31 \
|
||||
--driver ilo \
|
||||
--deploy-interface iscsi \
|
||||
--boot-interface ilo-virtual-media \
|
||||
--driver-info ilo_address=<ilo-ip-address> \
|
||||
--driver-info ilo_username=<ilo-username> \
|
||||
--driver-info ilo_password=<ilo-password> \
|
||||
--driver-info ilo_deploy_iso=<glance-uuid-of-deploy-iso>
|
||||
openstack baremetal node create --os-baremetal-api-version=1.31 \
|
||||
--driver ilo \
|
||||
--deploy-interface iscsi \
|
||||
--boot-interface ilo-virtual-media \
|
||||
--driver-info ilo_address=<ilo-ip-address> \
|
||||
--driver-info ilo_username=<ilo-username> \
|
||||
--driver-info ilo_password=<ilo-password> \
|
||||
--driver-info ilo_deploy_iso=<glance-uuid-of-deploy-iso>
|
||||
|
||||
* ``pxe_ilo``:
|
||||
|
||||
.. code-block:: console
|
||||
.. code-block:: console
|
||||
|
||||
openstack baremetal node create --os-baremetal-api-version=1.31 \
|
||||
--driver ilo \
|
||||
--deploy-interface iscsi \
|
||||
--boot-interface ilo-pxe \
|
||||
--driver-info ilo_address=<ilo-ip-address> \
|
||||
--driver-info ilo_username=<ilo-username> \
|
||||
--driver-info ilo_password=<ilo-password> \
|
||||
--driver-info deploy_kernel=<glance-uuid-of-pxe-deploy-kernel> \
|
||||
--driver-info deploy_ramdisk=<glance-uuid-of-deploy-ramdisk>
|
||||
openstack baremetal node create --os-baremetal-api-version=1.31 \
|
||||
--driver ilo \
|
||||
--deploy-interface iscsi \
|
||||
--boot-interface ilo-pxe \
|
||||
--driver-info ilo_address=<ilo-ip-address> \
|
||||
--driver-info ilo_username=<ilo-username> \
|
||||
--driver-info ilo_password=<ilo-password> \
|
||||
--driver-info deploy_kernel=<glance-uuid-of-pxe-deploy-kernel> \
|
||||
--driver-info deploy_ramdisk=<glance-uuid-of-deploy-ramdisk>
|
||||
|
||||
* ``agent_ilo``:
|
||||
|
||||
.. code-block:: console
|
||||
.. code-block:: console
|
||||
|
||||
openstack baremetal node create --os-baremetal-api-version=1.31 \
|
||||
--driver ilo \
|
||||
--deploy-interface direct \
|
||||
--boot-interface ilo-virtual-media \
|
||||
--driver-info ilo_address=<ilo-ip-address> \
|
||||
--driver-info ilo_username=<ilo-username> \
|
||||
--driver-info ilo_password=<ilo-password> \
|
||||
--driver-info ilo_deploy_iso=<glance-uuid-of-deploy-iso>
|
||||
openstack baremetal node create --os-baremetal-api-version=1.31 \
|
||||
--driver ilo \
|
||||
--deploy-interface direct \
|
||||
--boot-interface ilo-virtual-media \
|
||||
--driver-info ilo_address=<ilo-ip-address> \
|
||||
--driver-info ilo_username=<ilo-username> \
|
||||
--driver-info ilo_password=<ilo-password> \
|
||||
--driver-info ilo_deploy_iso=<glance-uuid-of-deploy-iso>
|
||||
|
||||
Prerequisites
|
||||
=============
|
||||
@ -228,14 +228,14 @@ Glance Configuration
|
||||
swift_account=AUTH_51ea2fb400c34c9eb005ca945c0dc9e1
|
||||
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
|
||||
Meta Temp-Url-Key: mysecretkeyforglance
|
||||
StorageURL: http://10.10.1.10:8080/v1/AUTH_51ea2fb400c34c9eb005ca945c0dc9e1
|
||||
Meta Temp-Url-Key: mysecretkeyforglance
|
||||
|
||||
|
||||
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:
|
||||
|
||||
``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
|
||||
@ -1632,14 +1632,14 @@ step could be::
|
||||
|
||||
The different attributes of ``activate_license`` clean step are as follows:
|
||||
|
||||
.. csv-table::
|
||||
:header: "Attribute", "Description"
|
||||
:widths: 30, 120
|
||||
.. csv-table::
|
||||
:header: "Attribute", "Description"
|
||||
:widths: 30, 120
|
||||
|
||||
"``interface``", "Interface of clean step, here ``management``"
|
||||
"``step``", "Name of clean step, here ``activate_license``"
|
||||
"``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."
|
||||
"``interface``", "Interface of clean step, here ``management``"
|
||||
"``step``", "Name of clean step, here ``activate_license``"
|
||||
"``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."
|
||||
|
||||
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:
|
||||
|
||||
.. csv-table::
|
||||
:header: "Attribute", "Description"
|
||||
:widths: 30, 120
|
||||
.. csv-table::
|
||||
:header: "Attribute", "Description"
|
||||
:widths: 30, 120
|
||||
|
||||
"``interface``", "Interface of clean step, here ``management``"
|
||||
"``step``", "Name of clean step, here ``update_firmware``"
|
||||
"``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_images``", "Ordered list of dictionaries of images to be flashed. This is mandatory."
|
||||
"``interface``", "Interface of clean step, here ``management``"
|
||||
"``step``", "Name of clean step, here ``update_firmware``"
|
||||
"``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_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::
|
||||
|
||||
@ -1712,22 +1712,22 @@ All the fields in the firmware image block are mandatory.
|
||||
* The different types of firmware url schemes supported are:
|
||||
``file``, ``http``, ``https`` and ``swift``.
|
||||
|
||||
.. note::
|
||||
This feature assumes that while using ``file`` url scheme the file path is
|
||||
on the conductor controlling the node.
|
||||
.. note::
|
||||
This feature assumes that while using ``file`` url scheme the file path is
|
||||
on the conductor controlling the node.
|
||||
|
||||
.. note::
|
||||
The ``swift`` url scheme assumes the swift account of the ``service``
|
||||
project. The ``service`` project (tenant) is a special project created in
|
||||
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
|
||||
``service`` and the container is generally ``ironic`` and ``ilo`` drivers
|
||||
use a container named ``ironic_ilo_container`` for their own purpose.
|
||||
.. note::
|
||||
The ``swift`` url scheme assumes the swift account of the ``service``
|
||||
project. The ``service`` project (tenant) is a special project created in
|
||||
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
|
||||
``service`` and the container is generally ``ironic`` and ``ilo`` drivers
|
||||
use a container named ``ironic_ilo_container`` for their own purpose.
|
||||
|
||||
.. note::
|
||||
While using firmware files with a ``.rpm`` extension, make sure the commands
|
||||
``rpm2cpio`` and ``cpio`` are present on the conductor, as they are utilized
|
||||
to extract the firmware image from the package.
|
||||
.. note::
|
||||
While using firmware files with a ``.rpm`` extension, make sure the commands
|
||||
``rpm2cpio`` and ``cpio`` are present on the conductor, as they are utilized
|
||||
to extract the firmware image from the package.
|
||||
|
||||
* The firmware components that can be updated are:
|
||||
``ilo``, ``cpld``, ``power_pic``, ``bios`` and ``chassis``.
|
||||
|
||||
@ -18,9 +18,9 @@ Enable persistent boot device on node
|
||||
|
||||
$ openstack baremetal node set --driver-info force_persistent_boot_device=True <node>
|
||||
|
||||
.. note::
|
||||
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.
|
||||
.. note::
|
||||
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.
|
||||
|
||||
Once the flag is present, the next cleaning and deploy steps will be done
|
||||
with persistent boot for that node.
|
||||
|
||||
@ -99,10 +99,10 @@ Enabling the SNMP Power Driver
|
||||
to boot using ``netboot`` by setting its ``capabilities`` and updating
|
||||
Nova flavor as described below:
|
||||
|
||||
.. code-block:: console
|
||||
.. code-block:: console
|
||||
|
||||
openstack baremetal node set --property capabilities="boot_option:netboot" <node-uuid>
|
||||
openstack flavor set --property "capabilities:boot_option"="netboot" ironic-flavor
|
||||
openstack baremetal node set --property capabilities="boot_option:netboot" <node-uuid>
|
||||
openstack flavor set --property "capabilities:boot_option"="netboot" ironic-flavor
|
||||
|
||||
|
||||
#. Restart the Ironic conductor service.
|
||||
|
||||
@ -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
|
||||
driver.
|
||||
|
||||
.. note::
|
||||
If properties from both "Backing physical disk hints" or
|
||||
"Backing physical disks" are specified, they should be consistent with
|
||||
each other. If they are not consistent, then the RAID configuration
|
||||
will fail (because the appropriate backing physical disks could
|
||||
not be found).
|
||||
.. note::
|
||||
If properties from both "Backing physical disk hints" or
|
||||
"Backing physical disks" are specified, they should be consistent with
|
||||
each other. If they are not consistent, then the RAID configuration
|
||||
will fail (because the appropriate backing physical disks could
|
||||
not be found).
|
||||
|
||||
Examples for ``target_raid_config``
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
@ -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
|
||||
include:
|
||||
|
||||
- installing signed firmware for BIOS and peripheral devices
|
||||
- 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
|
||||
validate kernel signatures
|
||||
- disabling local (in-band) access from the host OS to the management controller (BMC)
|
||||
- disabling modifications to boot settings from the host OS
|
||||
- installing signed firmware for BIOS and peripheral devices
|
||||
- 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
|
||||
validate kernel signatures
|
||||
- disabling local (in-band) access from the host OS to the management controller (BMC)
|
||||
- disabling modifications to boot settings from the host OS
|
||||
|
||||
Additional references:
|
||||
- :ref:`cleaning`
|
||||
- :ref:`trusted-boot`
|
||||
|
||||
- :ref:`cleaning`
|
||||
- :ref:`trusted-boot`
|
||||
|
||||
@ -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`:
|
||||
|
||||
|
||||
@ -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.
|
||||
- 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.
|
||||
- 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.
|
||||
|
||||
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 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.
|
||||
- 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.
|
||||
|
||||
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,13 +256,15 @@ 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.
|
||||
|
||||
- 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.
|
||||
|
||||
- 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.
|
||||
|
||||
|
||||
Please see the `Ironic specs process wiki page <https://wiki.openstack.org/
|
||||
|
||||
@ -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::
|
||||
|
||||
|
||||
@ -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 for the project, the
|
||||
release automation will push a number of changes that need to be approved.
|
||||
|
||||
In the new stable branch, this will include:
|
||||
|
||||
* a change to point .gitreview at the branch
|
||||
* a change to update the upper constraints file used by tox
|
||||
* a change to point .gitreview at the branch
|
||||
* a change to update the upper constraints file used by tox
|
||||
|
||||
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:
|
||||
|
||||
* update the ironic devstack plugin to point at the branched tarball for IPA.
|
||||
An example of this patch is
|
||||
`here <https://review.openstack.org/#/c/374863/>`_.
|
||||
* update links in developer documentation to point to the branched version
|
||||
of the install guide.
|
||||
* update links in the install guide to point to the branched version of
|
||||
the developer documentation.
|
||||
* set appropriate defaults for TEMPEST_BAREMETAL_MIN_MICROVERSION and
|
||||
TEMPEST_BAREMETAL_MAX_MICROVERSION in devstack/lib/ironic to make sure that
|
||||
unsupported API tempest tests are skipped on stable branches.
|
||||
* update the ironic devstack plugin to point at the branched tarball for IPA.
|
||||
An example of this patch is
|
||||
`here <https://review.openstack.org/#/c/374863/>`_.
|
||||
* update links in developer documentation to point to the branched version
|
||||
of the install guide.
|
||||
* update links in the install guide to point to the branched version of
|
||||
the developer documentation.
|
||||
* set appropriate defaults for TEMPEST_BAREMETAL_MIN_MICROVERSION and
|
||||
TEMPEST_BAREMETAL_MAX_MICROVERSION in devstack/lib/ironic to make sure that
|
||||
unsupported API tempest tests are skipped on stable branches.
|
||||
|
||||
Additionally, changes need to be made on master to:
|
||||
|
||||
* create an empty commit with a ``Sem-Ver`` tag to bump the generated minor
|
||||
version. See `example
|
||||
<https://git.openstack.org/cgit/openstack/ironic/commit/?id=4b28af4645c2f3b6d7864671e15904ed8f40414d>`_
|
||||
and `pbr documentation
|
||||
<https://docs.openstack.org/pbr/latest/user/features.html#version>`_ for details.
|
||||
* create an empty commit with a ``Sem-Ver`` tag to bump the generated minor
|
||||
version. See `example
|
||||
<https://git.openstack.org/cgit/openstack/ironic/commit/?id=4b28af4645c2f3b6d7864671e15904ed8f40414d>`_
|
||||
and `pbr documentation
|
||||
<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
|
||||
associated with the oldest named release. Since we support upgrades between
|
||||
adjacent named releases, the master branch will only support upgrades from
|
||||
the most recent named release to master.
|
||||
* In ironic/common/release_mappings.py, delete any entries from RELEASE_MAPPING
|
||||
associated with the oldest named release. Since we support upgrades between
|
||||
adjacent named releases, the master branch will only support upgrades from
|
||||
the most recent named release to master.
|
||||
|
||||
* regenerate the sample config file, so that the choices for the
|
||||
``[DEFAULT]/pin_release_version`` configuration are accurate.
|
||||
* regenerate the sample config file, so that the choices for the
|
||||
``[DEFAULT]/pin_release_version`` configuration are accurate.
|
||||
|
||||
* remove any DB migration scripts from ironic.cmd.dbsync.ONLINE_MIGRATIONS
|
||||
and remove the corresponding code from ironic. (These migration scripts
|
||||
are used to migrate from an old release to this latest release; they
|
||||
shouldn't be needed after that.)
|
||||
* remove any DB migration scripts from ironic.cmd.dbsync.ONLINE_MIGRATIONS
|
||||
and remove the corresponding code from ironic. (These migration scripts
|
||||
are used to migrate from an old release to this latest release; they
|
||||
shouldn't be needed after that.)
|
||||
|
||||
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
|
||||
implemented.
|
||||
* update the specs repo to mark any specs completed in the release as
|
||||
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.
|
||||
|
||||
@ -23,66 +23,66 @@ service's controller nodes and compute nodes.
|
||||
|
||||
#. 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
|
||||
# include: libvirt.LibvirtDriver, xenapi.XenAPIDriver,
|
||||
# fake.FakeDriver, baremetal.BareMetalDriver,
|
||||
# vmwareapi.VMwareESXDriver, vmwareapi.VMwareVCDriver (string
|
||||
# value)
|
||||
#compute_driver=<None>
|
||||
compute_driver=ironic.IronicDriver
|
||||
# Driver to use for controlling virtualization. Options
|
||||
# include: libvirt.LibvirtDriver, xenapi.XenAPIDriver,
|
||||
# fake.FakeDriver, baremetal.BareMetalDriver,
|
||||
# vmwareapi.VMwareESXDriver, vmwareapi.VMwareVCDriver (string
|
||||
# value)
|
||||
#compute_driver=<None>
|
||||
compute_driver=ironic.IronicDriver
|
||||
|
||||
# Firewall driver (defaults to hypervisor specific iptables
|
||||
# driver) (string value)
|
||||
#firewall_driver=<None>
|
||||
firewall_driver=nova.virt.firewall.NoopFirewallDriver
|
||||
# Firewall driver (defaults to hypervisor specific iptables
|
||||
# driver) (string value)
|
||||
#firewall_driver=<None>
|
||||
firewall_driver=nova.virt.firewall.NoopFirewallDriver
|
||||
|
||||
# The scheduler host manager class to use (string value)
|
||||
#scheduler_host_manager=host_manager
|
||||
scheduler_host_manager=ironic_host_manager
|
||||
# The scheduler host manager class to use (string value)
|
||||
#scheduler_host_manager=host_manager
|
||||
scheduler_host_manager=ironic_host_manager
|
||||
|
||||
# Virtual ram to physical ram allocation ratio which affects
|
||||
# all ram filters. This configuration specifies a global ratio
|
||||
# for RamFilter. For AggregateRamFilter, it will fall back to
|
||||
# this configuration value if no per-aggregate setting found.
|
||||
# (floating point value)
|
||||
#ram_allocation_ratio=1.5
|
||||
ram_allocation_ratio=1.0
|
||||
# Virtual ram to physical ram allocation ratio which affects
|
||||
# all ram filters. This configuration specifies a global ratio
|
||||
# for RamFilter. For AggregateRamFilter, it will fall back to
|
||||
# this configuration value if no per-aggregate setting found.
|
||||
# (floating point value)
|
||||
#ram_allocation_ratio=1.5
|
||||
ram_allocation_ratio=1.0
|
||||
|
||||
# Amount of disk in MB to reserve for the host (integer value)
|
||||
#reserved_host_disk_mb=0
|
||||
reserved_host_memory_mb=0
|
||||
# Amount of disk in MB to reserve for the host (integer value)
|
||||
#reserved_host_disk_mb=0
|
||||
reserved_host_memory_mb=0
|
||||
|
||||
# Determines if the Scheduler tracks changes to instances to help with
|
||||
# its filtering decisions (boolean value)
|
||||
#scheduler_tracks_instance_changes=True
|
||||
scheduler_tracks_instance_changes=False
|
||||
# Determines if the Scheduler tracks changes to instances to help with
|
||||
# its filtering decisions (boolean value)
|
||||
#scheduler_tracks_instance_changes=True
|
||||
scheduler_tracks_instance_changes=False
|
||||
|
||||
# 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
|
||||
# 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
|
||||
# to more evenly distribute instances across the nodes.
|
||||
#scheduler_host_subset_size=1
|
||||
scheduler_host_subset_size=9999999
|
||||
# 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
|
||||
# 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
|
||||
# to more evenly distribute instances across the nodes.
|
||||
#scheduler_host_subset_size=1
|
||||
scheduler_host_subset_size=9999999
|
||||
|
||||
If you have not migrated to using :ref:`scheduling-resource-classes`, then
|
||||
the following should be set as well:
|
||||
If you have not migrated to using :ref:`scheduling-resource-classes`, then
|
||||
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.
|
||||
# (boolean value)
|
||||
#scheduler_use_baremetal_filters=False
|
||||
scheduler_use_baremetal_filters=True
|
||||
# Flag to decide whether to use baremetal_scheduler_default_filters or not.
|
||||
# (boolean value)
|
||||
#scheduler_use_baremetal_filters=False
|
||||
scheduler_use_baremetal_filters=True
|
||||
|
||||
This option is deprecated and has to be unset after migration
|
||||
to resource classes.
|
||||
This option is deprecated and has to be unset after migration
|
||||
to resource classes.
|
||||
|
||||
#. Change these configuration options in the ``ironic`` section.
|
||||
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
|
||||
- ``IDENTITY_IP`` with the IP of the Identity server
|
||||
|
||||
.. code-block:: ini
|
||||
.. code-block:: ini
|
||||
|
||||
[ironic]
|
||||
[ironic]
|
||||
|
||||
# Ironic authentication type
|
||||
auth_type=password
|
||||
# Ironic authentication type
|
||||
auth_type=password
|
||||
|
||||
# Keystone API endpoint
|
||||
auth_url=http://IDENTITY_IP:35357/v3
|
||||
# Keystone API endpoint
|
||||
auth_url=http://IDENTITY_IP:35357/v3
|
||||
|
||||
# Ironic keystone project name
|
||||
project_name=service
|
||||
# Ironic keystone project name
|
||||
project_name=service
|
||||
|
||||
# Ironic keystone admin name
|
||||
username=ironic
|
||||
# Ironic keystone admin name
|
||||
username=ironic
|
||||
|
||||
# Ironic keystone admin password
|
||||
password=IRONIC_PASSWORD
|
||||
# Ironic keystone admin password
|
||||
password=IRONIC_PASSWORD
|
||||
|
||||
# Ironic keystone project domain
|
||||
# or set project_domain_id
|
||||
project_domain_name=Default
|
||||
# Ironic keystone project domain
|
||||
# or set project_domain_id
|
||||
project_domain_name=Default
|
||||
|
||||
# Ironic keystone user domain
|
||||
# or set user_domain_id
|
||||
user_domain_name=Default
|
||||
# Ironic keystone user domain
|
||||
# or set user_domain_id
|
||||
user_domain_name=Default
|
||||
|
||||
#. On the Compute service's controller nodes, restart the ``nova-scheduler``
|
||||
process:
|
||||
|
||||
.. code-block:: console
|
||||
.. code-block:: console
|
||||
|
||||
Fedora/RHEL7/CentOS7/SUSE:
|
||||
sudo systemctl restart openstack-nova-scheduler
|
||||
Fedora/RHEL7/CentOS7/SUSE:
|
||||
sudo systemctl restart openstack-nova-scheduler
|
||||
|
||||
Ubuntu:
|
||||
sudo service nova-scheduler restart
|
||||
Ubuntu:
|
||||
sudo service nova-scheduler restart
|
||||
|
||||
#. On the Compute service's compute nodes, restart the ``nova-compute``
|
||||
process:
|
||||
|
||||
.. code-block:: console
|
||||
.. code-block:: console
|
||||
|
||||
Fedora/RHEL7/CentOS7/SUSE:
|
||||
sudo systemctl restart openstack-nova-compute
|
||||
Fedora/RHEL7/CentOS7/SUSE:
|
||||
sudo systemctl restart openstack-nova-compute
|
||||
|
||||
Ubuntu:
|
||||
sudo service nova-compute restart
|
||||
Ubuntu:
|
||||
sudo service nova-compute restart
|
||||
|
||||
@ -37,7 +37,7 @@ flexible and can vary per instance.
|
||||
Here is an example for grub2 with ubuntu, users can customize it
|
||||
to fit their use case:
|
||||
|
||||
.. code:: python
|
||||
.. code:: python
|
||||
|
||||
#!/usr/bin/env python
|
||||
import os
|
||||
|
||||
Loading…
Reference in New Issue
Block a user