Merge "doc/source/admin fixes part-2"
This commit is contained in:
Zuul
Gerrit Code Review
commit
16f0e53d61
@ -4,7 +4,7 @@ Building images for Windows
|
||||
---------------------------
|
||||
We can use ``New-WindowsOnlineImage`` in `windows-openstack-imaging-tools`_
|
||||
tool as an option to create Windows images (whole disk images) corresponding
|
||||
boot modes which will support for Windows NIC Teaming. And allow the
|
||||
boot modes which will support Windows NIC Teaming. And allow the
|
||||
utilization of link aggregation when the instance is spawned on hardware
|
||||
servers (Bare metals).
|
||||
|
||||
@ -16,26 +16,25 @@ Requirements:
|
||||
``PowerShell`` version >=4 supported,
|
||||
``Windows Assessment and Deployment Kit``,
|
||||
in short ``Windows ADK``.
|
||||
* The windows Server compatible drivers.
|
||||
* The Windows Server compatible drivers.
|
||||
* Working git environment.
|
||||
|
||||
Preparation:
|
||||
~~~~~~~~~~~~
|
||||
|
||||
* Download a Windows Server 2012R2/ 2016 installation ISO.
|
||||
* Install Windows Server 2012R2/ 2016 OS on workstation PC along with
|
||||
* Install Windows Server 2012R2/ 2016 OS on the workstation PC along with
|
||||
following feature:
|
||||
|
||||
- Enable Hyper-V virtualization.
|
||||
- Install PowerShell 4.0.
|
||||
- Install Git environment & import git proxy (if have).
|
||||
- Create new ``Path`` in Microsoft Windows Server Operating System which
|
||||
- Install Git environment & import git proxy (if you have).
|
||||
- Create a new ``Path`` in the Microsoft Windows Server Operating System which
|
||||
support for submodule update via ``git submodule update –init`` command::
|
||||
|
||||
- Variable name: Path
|
||||
- Variable value: C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files\Git\bin
|
||||
|
||||
- Rename virtual switch name in Windows Server 2012R2/ 2016 in
|
||||
- Rename the virtual switch name in Windows Server 2012R2/ 2016 in
|
||||
``Virtual Switch Manager`` into ``external``.
|
||||
|
||||
Implementation:
|
||||
@ -85,7 +84,7 @@ Implementation:
|
||||
|
||||
.. note::
|
||||
|
||||
We can change ``SizeBytes``, ``CpuCores`` and ``Memory`` depending on requirements.
|
||||
We can change ``SizeBytes``, ``CpuCores``, and ``Memory`` depending on requirements.
|
||||
|
||||
.. _`example_windows_images`: https://github.com/cloudbase/windows-openstack-imaging-tools/blob/master/Examples
|
||||
.. _`windows-openstack-imaging-tools`: https://github.com/cloudbase/windows-openstack-imaging-tools
|
||||
|
||||
@ -84,8 +84,8 @@ Clean steps specific to storage are ``erase_devices``,
|
||||
``erase_devices_metadata`` and (added in Yoga) ``erase_devices_express``.
|
||||
|
||||
``erase_devices`` aims to ensure that the data is removed in the most secure
|
||||
way available. On devices that support hardware assisted secure erasure
|
||||
(many NVMe and some ATA drives) this is the preferred option. If
|
||||
way available. On devices that support hardware-assisted secure erasure
|
||||
(many NVMe and some ATA drives), this is the preferred option. If
|
||||
hardware-assisted secure erasure is not available and if
|
||||
:oslo.config:option:`deploy.continue_if_disk_secure_erase_fails` is set to
|
||||
``True``, cleaning will fall back to using ``shred`` to overwrite the
|
||||
@ -95,24 +95,24 @@ data security.
|
||||
|
||||
.. note::
|
||||
``erase_devices`` may take a very long time (hours or even days) to
|
||||
complete, unless fast, hardware assisted data erasure is supported by
|
||||
complete, unless fast, hardware-assisted data erasure is supported by
|
||||
all the devices in a system.
|
||||
|
||||
``erase_devices_metadata`` clean step doesn't provide as strong assurance
|
||||
of irreversible destruction of data as ``erase_devices``. However, it has the
|
||||
advantage of a reasonably quick runtime (seconds to minutes). It operates by
|
||||
destroying metadata of the storage device without erasing every bit of the
|
||||
data itself. Attempts of restoring data after running
|
||||
destroying the metadata of the storage device without erasing every bit of the
|
||||
data itself. Attempts to restore data after running
|
||||
``erase_devices_metadata`` may be successful but would certainly require
|
||||
relevant expertise and specialized tools.
|
||||
|
||||
Lastly, ``erase_devices_express`` combines some of the perks of both
|
||||
``erase_devices`` and ``erase_devices_metadata``. It attempts to utilize
|
||||
hardware assisted data erasure features if available (currently only NVMe
|
||||
devices are supported). In case hardware-asssisted data erasure is not
|
||||
hardware-assisted data erasure features if available (currently only NVMe
|
||||
devices are supported). In case hardware-assisted data erasure is not
|
||||
available, it falls back to metadata erasure for the device (which is
|
||||
identical to ``erase_devices_metadata``). It can be considered a
|
||||
time optimized mode of storage cleaning, aiming to perform as thorough
|
||||
time-optimized mode of storage cleaning, aiming to perform as thorough
|
||||
data erasure as it is possible within a short period of time.
|
||||
This clean step is particularly well suited for environments with hybrid
|
||||
NVMe-HDD storage configuration as it allows fast and secure erasure of data
|
||||
@ -120,7 +120,7 @@ stored on NVMes combined with equally fast but more basic metadata-based
|
||||
erasure of data on commodity HDDs.
|
||||
|
||||
By default, Ironic will use ``erase_devices_metadata`` early in cleaning
|
||||
for reliability (ensuring a node cannot reboot into it's old workload) and
|
||||
for reliability (ensuring a node cannot reboot into its old workload) and
|
||||
``erase_devices`` later in cleaning to securely erase the drive;
|
||||
``erase_devices_express`` is disabled.
|
||||
|
||||
@ -161,7 +161,7 @@ This list may not be comprehensive. Please review ironic.conf.sample
|
||||
|
||||
.. warning::
|
||||
Ironic automated cleaning is defaulted to a secure configuration. You should
|
||||
not modify settings related to it unless you are have special hardware needs,
|
||||
not modify settings related to it unless you have special hardware needs
|
||||
or a unique use case. Misconfigurations can lead to data exposure
|
||||
vulnerabilities.
|
||||
|
||||
@ -173,7 +173,7 @@ This list may not be comprehensive. Please review ironic.conf.sample
|
||||
Manual cleaning
|
||||
===============
|
||||
|
||||
``Manual cleaning`` is typically used to handle long running, manual, or
|
||||
``Manual cleaning`` is typically used to handle long-running, manual, or
|
||||
destructive tasks that an operator wishes to perform either before the first
|
||||
workload has been assigned to a node or between workloads. When initiating a
|
||||
manual clean, the operator specifies the cleaning steps to be performed.
|
||||
@ -381,7 +381,7 @@ priority.
|
||||
|
||||
Changing the priority of an in-band (ironic-python-agent) cleaning step
|
||||
requires use of :oslo.config:option:`conductor.clean_step_priority_override`,
|
||||
a configuration option which allows specifying priority of each step using
|
||||
a configuration option that allows specifying the priority of each step using
|
||||
multiple configuration values:
|
||||
|
||||
.. code-block:: ini
|
||||
@ -421,7 +421,7 @@ Why can't I power on/off a node while it's cleaning?
|
||||
----------------------------------------------------
|
||||
During cleaning, nodes may be performing actions that shouldn't be
|
||||
interrupted, such as BIOS or Firmware updates. As a result, operators are
|
||||
forbidden from changing power state via the ironic API while a node is
|
||||
forbidden from changing the power state via the ironic API while a node is
|
||||
cleaning.
|
||||
|
||||
Advanced topics
|
||||
@ -436,7 +436,7 @@ account child nodes. Mainly, the concept of executing clean steps in relation
|
||||
to child nodes.
|
||||
|
||||
In this context, a child node is primarily intended to be an embedded device
|
||||
with it's own management controller. For example "SmartNIC's" or Data
|
||||
with its own management controller. For example "SmartNIC's" or Data
|
||||
Processing Units (DPUs) which may have their own management controller and
|
||||
power control.
|
||||
|
||||
@ -447,9 +447,9 @@ The relationship between a parent node and a child node is established on the ch
|
||||
Child Node Clean Step Execution
|
||||
-------------------------------
|
||||
|
||||
You can execute steps which perform actions on child nodes. For example,
|
||||
You can execute steps that perform actions on child nodes. For example,
|
||||
turn them on (via step ``power_on``), off (via step ``power_off``), or to
|
||||
signal a BMC controlled reboot (via step ``reboot``).
|
||||
signal a BMC-controlled reboot (via step ``reboot``).
|
||||
|
||||
For example, if you need to explicitly power off child node power, before
|
||||
performing another step, you can articulate it with a step such as::
|
||||
@ -501,8 +501,8 @@ If cleaning fails on a node, the node will be put into ``clean failed`` state.
|
||||
If the failure happens while running a clean step, the node is also placed in
|
||||
maintenance mode to prevent ironic from taking actions on the node. The
|
||||
operator should validate that no permanent damage has been done to the
|
||||
node and no processes are still running on it before removing the maintenance
|
||||
mode.
|
||||
node and that no processes are still running on it before removing the
|
||||
maintenance mode.
|
||||
|
||||
.. note:: Older versions of ironic may put the node to maintenance even when
|
||||
no clean step has been running.
|
||||
|
||||
@ -7,13 +7,13 @@ Conductor Groups
|
||||
Overview
|
||||
========
|
||||
|
||||
Large scale operators tend to have needs that involve creating
|
||||
well defined and delinated resources. In some cases, these systems
|
||||
may reside close by or in far away locations. Reasoning may be simple
|
||||
Large-scale operators tend to have needs that involve creating
|
||||
well-defined and delineated resources. In some cases, these systems
|
||||
may reside close by or in faraway locations. The reasoning may be simple
|
||||
or complex, and yet is only known to the deployer and operator of the
|
||||
infrastructure.
|
||||
|
||||
A common case is the need for delineated high availability domains
|
||||
A common case is the need for delineated high-availability domains
|
||||
where it would be much more efficient to manage a datacenter in Antarctica
|
||||
with a conductor in Antarctica, as opposed to a conductor in New York City.
|
||||
|
||||
@ -44,7 +44,7 @@ only managing nodes with a matching ``conductor_group`` string.
|
||||
How to use
|
||||
==========
|
||||
|
||||
A conductor group value may be any case insensitive string up to 255
|
||||
A conductor group value may be any case-insensitive string up to 255
|
||||
characters long which matches the ``^[a-zA-Z0-9_\-\.]*$`` regular
|
||||
expression.
|
||||
|
||||
@ -61,6 +61,6 @@ expression.
|
||||
baremetal node set \
|
||||
--conductor-group "OperatorDefinedString" <uuid>
|
||||
|
||||
#. As desired and as needed, remaining conductors can be updated with
|
||||
#. As desired and as needed, the remaining conductors can be updated with
|
||||
the first two steps. Please be mindful of the constraints covered
|
||||
earlier in the document related to ability to manage nodes.
|
||||
earlier in the document related to the ability to manage nodes.
|
||||
|
||||
@ -7,9 +7,9 @@ Configuring Web or Serial Console
|
||||
Overview
|
||||
--------
|
||||
|
||||
There are two types of console which are available in Bare Metal service,
|
||||
There are two types of consoles which are available in Bare Metal service,
|
||||
one is web console (`Node web console`_) which is available directly from web
|
||||
browser, another is serial console (`Node serial console`_).
|
||||
browser, and another is serial console (`Node serial console`_).
|
||||
|
||||
Node web console
|
||||
----------------
|
||||
@ -17,14 +17,14 @@ Node web console
|
||||
The web console can be configured in Bare Metal service in the following way:
|
||||
|
||||
* Install shellinabox in ironic conductor node. For RHEL/CentOS, shellinabox package
|
||||
is not present in base repositories, user must enable EPEL repository, you can find
|
||||
more from `FedoraProject page`_.
|
||||
is not present in base repositories, the user must enable EPEL repository, you can
|
||||
find more from `FedoraProject page`_.
|
||||
|
||||
.. note::
|
||||
|
||||
shellinabox is no longer maintained by the authorized author.
|
||||
`This <https://github.com/shellinabox/shellinabox>`_ is a fork of the
|
||||
project on GitHub that aims to continue with maintenance of the
|
||||
project on GitHub that aims to continue with the maintenance of the
|
||||
shellinabox project.
|
||||
|
||||
Installation example:
|
||||
@ -66,7 +66,7 @@ The web console can be configured in Bare Metal service in the following way:
|
||||
* Customize the console section in the Bare Metal service configuration
|
||||
file (/etc/ironic/ironic.conf), if you want to use SSL certificate in
|
||||
shellinabox, you should specify ``terminal_cert_dir``.
|
||||
for example::
|
||||
For example::
|
||||
|
||||
[console]
|
||||
|
||||
@ -147,9 +147,9 @@ The web console can be configured in Bare Metal service in the following way:
|
||||
| console_info | {u'url': u'http://<url>:<customized_port>', u'type': u'shellinabox'} |
|
||||
+-----------------+----------------------------------------------------------------------+
|
||||
|
||||
You can open web console using above ``url`` through web browser. If ``console_enabled`` is
|
||||
``false``, ``console_info`` is ``None``, web console is disabled. If you want to launch web
|
||||
console, see the ``Configure node web console`` part.
|
||||
You can open the web console using the above ``url`` through web browser. If
|
||||
``console_enabled`` is ``false``, ``console_info`` is ``None``, web console is disabled.
|
||||
If you want to launch the web console, see the ``Configure node web console`` part.
|
||||
|
||||
.. note::
|
||||
|
||||
@ -235,7 +235,7 @@ If ``console_enabled`` is ``false`` or ``console_info`` is ``None`` then
|
||||
the serial console is disabled. If you want to launch serial console, see the
|
||||
``Configure node console``.
|
||||
|
||||
Node serial console of the Bare Metal service is compatible with the
|
||||
The node serial console of the Bare Metal service is compatible with the
|
||||
serial console of the Compute service. Hence, serial consoles to
|
||||
Bare Metal nodes can be seen and interacted with via the Dashboard service.
|
||||
In order to achieve that, you need to follow the documentation for
|
||||
@ -269,7 +269,7 @@ configuration, you may consider some settings below.
|
||||
|
||||
* The Compute service's caching feature may need to be enabled in order
|
||||
to make the Bare Metal serial console work under a HA configuration.
|
||||
Here is an example of caching configuration in ``nova.conf``.
|
||||
Here is an example of a caching configuration in ``nova.conf``.
|
||||
|
||||
.. code-block:: ini
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user