openstack/ironic-specs
Code Issues Proposed changes

add codespell to run via pre-commit

Browse Source 
Added running codespell via pre-commit. Corrected all the spelling
mistakes as well. It seemed better to correct them than to leave them
incorrect in past specs and priorities since it looks more professional.

Change-Id: If96abb56726a4d8164ebdd5de4dc5ba09bc734a5
Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
This commit is contained in:
Doug Goldstein 2024-11-09 12:42:58 -05:00
parent 3592d4c370
commit a92f7f9c2f
No known key found for this signature in database
61 changed files with 150 additions and 142 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
.pre-commit-config.yaml
View File

@ -23,6 +23,11 @@ repos:
hooks:
- id: remove-tabs
exclude: '.*\.(svg)$'
- repo: https://github.com/codespell-project/codespell
rev: v2.2.6
hooks:
- id: codespell
args: [--write-changes]
- repo: https://github.com/sphinx-contrib/sphinx-lint
rev: v1.0.0
hooks:

2
doc/source/index.rst
View File

@ -431,7 +431,7 @@ Retired
These specifications are ideas and features which are no longer applicable.
They were either not implemented, no longer exist, and have generally been
superceeded either through the evolution of the project's capabilities or
superseded either through the evolution of the project's capabilities or
the state in the marketplace. Each document listed below has been updated
to indicate the context as to why it was moved to this list.

8
priorities/2023-1-workitems.rst
View File

@ -42,7 +42,7 @@ Each item in the table includes:
- Category
- Champions
* - `SQLAlchemy 2.0 Compatability`_
* - `SQLAlchemy 2.0 Compatibility`_
- Maintenance
- TheJulia
@ -73,7 +73,7 @@ Each item in the table includes:
Goals Details
=============
SQLAlchemy 2.0 Compatability
SQLAlchemy 2.0 Compatibility
----------------------------
Our DB layer is currently using SQLAlchemy 1.4 or older, and relies heavily on
autocommit behaviors. Additionally as part of the migration to 2.0, SQLAlchemy
@ -113,7 +113,7 @@ Remove default use of MD5
The MD5 hashing algorithm is still supported in Ironic for image hashing.
This is not ideal as MD5 is broken. This work will be a breaking change;
forbidding use of MD5 hashes by default. Operators who wish to
continue using MD5 for API compatability reasons will be able to re-enable
continue using MD5 for API compatibility reasons will be able to re-enable
it via config.
Merging Inspector into Ironic
@ -126,7 +126,7 @@ well, as Ironic Inspector also needs to be updated to work with SQLAlchemy 2.0.
Active Steps
------------
Ironic uses steps to perform actions on a node during deployment or cleaning.
We'd like to extend this concept of steps to allow for maintainence on actively
We'd like to extend this concept of steps to allow for maintenance on actively
deployed nodes. This new Active Steps feature will allow operators to perform a
firmware update -- or any other automated action on a provisioned, ACTIVE node.

4
priorities/2023-2-workitems.rst
View File

@ -105,7 +105,7 @@ Remove default use of MD5
The MD5 hashing algorithm is still supported in Ironic for image hashing.
This is not ideal as MD5 is broken. This work will be a breaking change;
forbidding use of MD5 hashes by default. Operators who wish to
continue using MD5 for API compatability reasons will be able to re-enable
continue using MD5 for API compatibility reasons will be able to re-enable
it via config.
Merging Inspector into Ironic
@ -145,7 +145,7 @@ non-disruptive conductor shutdowns and restarts.
FIPS Compatibility jobs in CI
-----------------------------
FIPS compatability is a `cross-project goal <https://governance.openstack.org/tc/goals/selected/fips.html>`_
FIPS compatibility is a `cross-project goal <https://governance.openstack.org/tc/goals/selected/fips.html>`_
in OpenStack. We hope to have CI jobs added to identify areas in Ironic that
are not FIPS compatible. No major incompatibilities are anticipated, but we may
need to update some hashlib.md5() calls and other minor changes.

2
priorities/stein-priorities.rst
View File

@ -146,7 +146,7 @@ While the community is interested in supporting HTTPClient based booting,
we currently have a few steps to surpass first. Namely the iPXE/PXE interface
split and improved UEFI testing.
The nature of this work is to enable an explict HTTP booting scenario where
The nature of this work is to enable an explicit HTTP booting scenario where
the booting node does not leverage PXE.
The story can be found at `story 2003934 <https://storyboard.openstack.org/#!/story/2003934>`_.

8
priorities/train-priorities.rst
View File

@ -72,7 +72,7 @@ Deploy Steps
As a general theme of work for the Train Cycle, the Ironic project community
wishes to break the monolithic deployment step into multiple deployment steps
which will further enable operators to easily create more complex
declaritive deployments. This work also includes the the ability to trigger
declarative deployments. This work also includes the the ability to trigger
steps through the agent, something that is not presently possible today.
Faster Deployments
@ -112,7 +112,7 @@ Redfish Virtual Media
One of the most powerful features we can offer to operators with distributed
and edge ironic nodes is to offer booting the ramdisk via a generic
Redfish Virtual Media boot interface. This will enable greater comptability
Redfish Virtual Media boot interface. This will enable greater compatibility
and once completed in-gate testing of virtual media relate scenarios in CI.
More information can be found in
@ -152,13 +152,13 @@ node power state. At larger scales, this is inefficient and results
in the power state nova having on record from being out of state
from ironic as the source of truth.
Conversely, nova presently assumes that it is always authorative
Conversely, nova presently assumes that it is always authoritative
in regards to power states. This work will allow ironic to inform
nova of the new power state such that nova does not attempt to
reset the power state.
While this is largely an effort in the nova project, we need to be
aware and attempt to support this work to move foward.
aware and attempt to support this work to move forward.
The nova-spec document can be found in review as
`change 636132 <https://review.opendev.org/#/c/636132/>`_.

4
priorities/ussuri-priorities.rst
View File

@ -90,7 +90,7 @@ visibility and awareness to this topic as well as ensuring we set
expectations and communicate ideal architectures.
* Implement some lightweight stress and performance testing
* Documentation oriented to scaleing
* Documentation oriented to scaling
It will be important to work with the `Bare Metal SIG`_ on this topic.
@ -133,7 +133,7 @@ topic has arisen from the Telecom world seeking to represent the state of the
node more accurately with-in ironic as to represent if a machine is in a fault
state or questionable state under-going investigation.
With that being said, we did not make progess on this issue in the past cycle
With that being said, we did not make progress on this issue in the past cycle
due to a fundamental disagreements in perception. The Project Teams Gathering
in Shanghai provided a forum for discussion where we realized that these are
actually similar but separate issues. One is for a separate logic path in what

4
priorities/victoria-priorities.rst
View File

@ -119,7 +119,7 @@ rely upon stable APIs and interfaces, at least in most cases.
While we would all love to see all of the features, we should be delivering
in a model which conforms to `Sem-Ver <http://semver.org>`_ and not force
artificial major version changes to match a cycle boundry and to create a
artificial major version changes to match a cycle boundary and to create a
branch point.
Having said this, it is time for us to move to an
@ -236,7 +236,7 @@ For standalone use cases to flourish, we must support another authentication
mechanism. The simplest, is rather simple. Just HTTP Basic Authentication.
Maybe we won't just stop there, but "noauth" is simply not acceptable with
edge infrastucture management.
edge infrastructure management.
DHCP-less Deployments
---------------------

2
priorities/wallaby-priorities.rst
View File

@ -247,7 +247,7 @@ appropriate management of a baremetal node.
The Redfish Forum has an `interop validator utility <https://github.com/DMTF/Redfish-Interop-Validator>`_
mechanism to allow BMC vendors to validate their implementation of the
Redfish API against the profile that represents compatability with Ironic.
Redfish API against the profile that represents compatibility with Ironic.
This work will also enable consumers of hardware to leverage the profile
to make sure the hardware they intend to buy works with Ironic or even

8
priorities/xena-themes.rst
View File

@ -225,7 +225,7 @@ herd situation. In essence, the database could not keep up. We need to try
and be smart to prevent some of these situations from happening, or at least
minimize the impact as many operators now also launch services using
Kubernetes, which can result in all services coming online at the same
moment, an aspect which aggrevates a thundering herd.
moment, an aspect which aggravates a thundering herd.
It should be noted, not all of this is intended to be feature work, as some
of the work product will end up being backported to the Wallaby release which
@ -256,7 +256,7 @@ in a human parsable way has long been under discussion and been a desired
feature. It is time we make it happen.
This work was started during the Wallaby development cycle but we did not have
the capcity to move it forward last cycle. This cycle we ought to finish it.
the capacity to move it forward last cycle. This cycle we ought to finish it.
Finishing anaconda deployment
-----------------------------
@ -315,7 +315,7 @@ may choose to deploy.
Ultimately having support for integration helps ensure a greater level
of operational security by helping operators identify and isolate
machines which have had malicious actions taken on them and also
potentialy help increase the level of security of the deployment
potentially help increase the level of security of the deployment
process by helping identify if a malicious actor has attempted to
modify a running ramdisk's contents.
@ -394,7 +394,7 @@ the "just want to be able to reuse my machine safely" group of operators.
This may result in some changes to how Secure Erase/Format operations are
handled, as well as additional portions of data to be removed from disks to
aid in re-use. Specifically for operators with Ceph.
aid in reuse. Specifically for operators with Ceph.
iSCSI deployment removal
------------------------

2
priorities/yoga-themes.rst
View File

@ -120,7 +120,7 @@ Start Merging Ironic Inspector in Ironic
Based on the PTG discussions, we will provide a new home for introspection
rules using a `new format
<https://owlet.today/posts/miniscript-and-future-of-introspection-rules/>`_
(still need to be discused with the community), we also want to add the
(still need to be discussed with the community), we also want to add the
`ability to generate ironic-inspector iPXE scripts
<https://storyboard.openstack.org/#!/story/2009294>`_.

3
setup.cfg
View File

@ -15,3 +15,6 @@ classifier =
packages =
specs
priorities
[codespell]
ignore-words-list = ninjs

4
specs/approved/active-node-creation.rst
View File

@ -110,7 +110,7 @@ REST API impact
Addition of a new state verb of ``adopt`` that triggers a transition to
``ADOPTING`` state. This verb will be unavailable for clients invoking
an insufficent API version.
an insufficient API version.
The API micro-version will need to be incremented as a result of this change.
@ -182,7 +182,7 @@ Allows for an easier adoption by managers of pre-existing hardware fleets.
There is the potential that a operator could define a hardware fleet with
bare minimal configuration to initially add the node to ironic. The result
of which means that an operator could conceivably and inadvertently act upon
a node when insufficent information is defined. This risk will be documented
a node when insufficient information is defined. This risk will be documented
as part of the resulting documentation in order to help highlight the risk
and help provide guidance on preventing such a possibility should a user
be attempting to adopt an inventory that is already "cloudy".

2
specs/approved/agent-api.rst
View File

@ -186,7 +186,7 @@ A new method is added to the deploy driver interface:
:param callback_url: a URL to use to call to the ramdisk
:return: None
"""
LOG.warning('Got hearbeat message from node %(node)s, but the driver '
LOG.warning('Got heartbeat message from node %(node)s, but the driver '
'%(driver)s does not support heartbeating',
{'node': task.node.uuid, 'driver': task.node.driver})

2
specs/approved/agent-http-provisioning.rst
View File

@ -284,7 +284,7 @@ Work Items
* Promote instance cache to be a global cache, usable for other interfaces.
* Implement the proposed work for ``direct`` deploy interface, includes image
caching, checksum recalculating, symlink mangement, etc.
caching, checksum recalculating, symlink management, etc.
* Update documents.
Dependencies

2
specs/approved/allocation-api.rst
View File

@ -106,7 +106,7 @@ database is used as backend (the only option in this spec):
Deallocation: database backend
------------------------------
The deallocation process will in one transation:
The deallocation process will in one transaction:
* unset node's ``instance_uuid``,
* unset node's ``allocation_id``,

2
specs/approved/anaconda-deploy-interface.rst
View File

@ -456,7 +456,7 @@ Security impact
The ``heartbeat`` method implemented by the driver has to be
unauthenticated so that anaconda can POST to the status API without a token.
An attacker could potentially cause targetted denial of service attack by
An attacker could potentially cause targeted denial of service attack by
sending invalid/incorrect status to Ironic nodes since the API is
unauthenticated. This issue is mitigated by mandatory agent token verification.

2
specs/approved/ansible-deploy-driver.rst
View File

@ -111,7 +111,7 @@ Control of cleaning steps is through Ansible tags
and auxiliary clean steps file.
The playbooks for actions can be set per-node, as is cleaning steps file.
The dreploy interface tries to re-use as much code from ironic as possible,
The dreploy interface tries to reuse as much code from ironic as possible,
and interface-wise is quite similar to the ``direct`` deploy interface.
Currently this interface supports two modes for continuing deployment

2
specs/approved/attestation-interface.rst
View File

@ -335,7 +335,7 @@ these variables as ``driver_info\keylime_agent_uuid``,
receive these credentials cleaning will fail.
The allowlist and excludelist will be sent to the verifier by calling the
keylime_tenant cli programatically. Once the verifier has received the
keylime_tenant cli programmatically. Once the verifier has received the
allowlist and excludelist, attestation will begin. The verifier will
periodically poll the Keylime agent for IMA measurements and compare them
with the allowlist and excludelist to determine if the node has been tampered

2
specs/approved/deployment-steps-framework.rst
View File

@ -209,7 +209,7 @@ described above.
"openstack baremetal" CLI
~~~~~~~~~~~~~~~~~~~~~~~~~
Responses will inclde the change described above.
Responses will include the change described above.
RPC API impact
--------------

4
specs/approved/enhance-power-interface-for-soft-reboot-and-nmi.rst
View File

@ -326,7 +326,7 @@ PowerInterface base and ManagementInterface base are enhanced by
adding a new method respectively as described in the section "Proposed
change".
And these enhancements keep API backward compatible.
Therefor it doesn't have any risk to break out of tree drivers.
Therefore it doesn't have any risk to break out of tree drivers.
Nova driver impact
@ -338,7 +338,7 @@ And "nova reboot" command has a option '--hard' to indicate hard reboot.
However the default behavior of "nova reboot" to an Ironic instance
is hard reboot, and --hard option is meaningless to the Ironic instance.
Therefor Ironic Nova driver needs to be update to unify the behavior
Therefore Ironic Nova driver needs to be update to unify the behavior
between virtual machine instance and bare-metal instance.
This problem is reported as a bug [6]. How to fix this problem is

2
specs/approved/expose-supported-power-states.rst
View File

@ -112,7 +112,7 @@ A new feature is no longer added to the "ironic" CLI.
"openstack baremetal" CLI
~~~~~~~~~~~~~~~~~~~~~~~~~
A new subcommnad will be added::
A new subcommand will be added::
openstack baremetal node power show [--supported] <node>

2
specs/approved/firmware-interface.rst
View File

@ -64,7 +64,7 @@ Proposed change
.. note:: This spec describes the out of band interface. An in-band
interface is planned to be implemented later, it can be called
`AgentFirmware`, changes on IPA-level APIs will have to be defined.
Other implementations can support going trough this interface to
Other implementations can support going through this interface to
execute the necessary in-band steps.

10
specs/approved/httpboot.rst
View File

@ -30,17 +30,17 @@ is no longer a constraint of late 2023.
Implementing both would be relatively easy and very beneficial for the
operator ecosystem, while also allowing for the navigation of the security
and NAT incompatability issues which exist with TFTP.
and NAT incompatibility issues which exist with TFTP.
Problem description
===================
Infrastructure operators need reliable, and realtively secure means of
Infrastructure operators need reliable, and relatively secure means of
conveying bootloaders and initial artifacts to remote machines.
Ironic's historical answer has been to utilize virtual media.
But not all hardware supports virutal media, and emulating a block device
But not all hardware supports virtual media, and emulating a block device
is not exactly the simplest thing once you boot an operating system. A helpful
aspect with UEFI and the evolution of systems is now we have facilities in
Baseboard management controllers and even UEFI base firmware support
@ -59,7 +59,7 @@ BMC Path
--------
* Update sushy-tools to support mapping cals to utilize a HTTP next boot
URL to the virutal media driver code. Functionally this is similar, as
URL to the virtual media driver code. Functionally this is similar, as
there appears to be no means to inject the hint to boot from the URL
into libvirt.
* Update sushy to support requesting to boot a node from a HTTP URL.
@ -212,7 +212,7 @@ Work Items
* Add support to pxe_utils logic to generate a URL boot response
payload, and set that based upon a driver feature/capability flag.
* Compose lots of documentation.
* Create tempest suite to execise both modes of boot operations.
* Create tempest suite to exercise both modes of boot operations.
Dependencies
============

2
specs/approved/inband-raid-configuration.rst
View File

@ -57,7 +57,7 @@ Following are the changes required:
clean step completes, the conductor resumes the cleaning and goes on to the
next clean step if any. A new mechanism - the
``agent_base_vendor.post_clean_step_hook`` decorator, will be added. This
allows a driver implementor to specify a function to be invoked after
allows a driver implementer to specify a function to be invoked after
successful completion of an in-band clean step (and before the next clean
step is started). The decorated function would take two arguments: the task
and the command status (of the clean step) returned by the agent ramdisk.

8
specs/approved/inspection-rules.rst
View File

@ -26,7 +26,7 @@ site-specific customizations:
following a certain pattern or by fetching them from a CMDB.
* Validation logic. Some operators want to fail inspection if the nodes do not
fullfil certain criteria. In the context of auto-discovery, such a validation
fulfill certain criteria. In the context of auto-discovery, such a validation
may be used to prevent unexpected machines from getting enrolled.
These requests can be covered by inspection hooks. But, as explained in
@ -485,7 +485,7 @@ The new section ``[inspection_rules]`` will have these options:
``built_in``
An optional path to a YAML file with built-in inspection rules. Loaded on
service start and thus not modifyable via SIGHUP.
service start and thus not modifiable via SIGHUP.
``default_scope``
The default value for ``scope`` for all rules where this field is not set
@ -511,7 +511,7 @@ One option will be added to the ``[auto_discovery]`` section:
``inspection_scope``
The default value of inspection scope for nodes enrolled via auto-discovery.
Simplifies targetting such nodes with inspection rules.
Simplifies targeting such nodes with inspection rules.
Developer impact
----------------
@ -576,7 +576,7 @@ Upgrades and Backwards Compatibility
====================================
Existing rules will not be automatically migrated from Inspector to Ironic
since the convertion may not be always trivial (e.g. around variable
since the conversion may not be always trivial (e.g. around variable
interpolation or loops).
Documentation Impact

4
specs/approved/ironic-redfish-proxy.rst
View File

@ -139,7 +139,7 @@ otherwise expect to provide, which poses a potential problem.
We intend to solve this problem through the use of application credentials,
which specify the user, project, and domain they are scoped to. Since each
application credential posesses a UUID, we can use this identifier in place of
application credential possesses a UUID, we can use this identifier in place of
all the information that would otherwise be required by Keystone. [APPCREDS]_
This approach is also beneficial from a security standpoint, as it reduces the
number of times raw user credentials are handled directly.
@ -847,7 +847,7 @@ currently being implemented as a separate WSGI service, it shall require at
minimum its own port to be ran on. This can be useful if one wishes to have
the Redfish proxy service bound to a different port or a different host IP
from the Ironic API; however, it will require a new endpoint to be added via
Keystone (if using Keystone), and may potentially require extra nework
Keystone (if using Keystone), and may potentially require extra network
configuration on the part of the system administrator.
Developer impact

4
specs/approved/manual-cleaning.rst
View File

@ -66,10 +66,10 @@ The main differences will be:
specified in the manual clean request; false if it is optional.
* add clean steps to drivers that will only be used by manual cleaning. The
mechanism for doing this exists already. Driver implementors only need to
mechanism for doing this exists already. Driver implementers only need to
use the @clean_step decorator with a default cleaning priority of 0. This
will ensure the step isn't run as part of the automated cleaning. The
implementor can specify whether the step is abortable, and should also
implementer can specify whether the step is abortable, and should also
include any arguments that can be passed to the clean step.
* operators will be able to get a list of possible steps via an API. The

14
specs/approved/mercury.rst
View File

@ -36,7 +36,7 @@ The goals can be summarized as:
facilitated by a modified networking-generic-switch or similar plugin.
* Provide a mechanism to configure L2 networks to be provided to a host
from a DPU.
* Provide a mechanism to accomodate highly isolated network management
* Provide a mechanism to accommodate highly isolated network management
interfaces where operators restrict access such that *only* Ironic
is able to connect to the remote endpoint.
* Provide a tool to apply and clean-up configuration, *not* track
@ -114,7 +114,7 @@ and perform attachment of interfaces based upon the provided information.
progorative" soft of item.
MVP would likely exclude locking, but be modeled as a single worker service
or container which does not maintain state, largely simplfies the problem to
or container which does not maintain state, largely simplifies the problem to
"who is logged into what" to make concurrent changes, which has been the
historical driver for locking.
@ -263,7 +263,7 @@ The closest alternative would be a ``standalone Neutron`` coupled with some
sort of extended/proxy RPC model, which is fine, but that really does not
address the underlying challenge of the attach/detach functionality
being needed by Infrastructure Operators. It also introduces modeling which
might not be suitable for bulk infrastucture operators as they would need
might not be suitable for bulk infrastructure operators as they would need
to think and operate a cloud model, as opposed to the physical infrasructure
model. Plus operating Neutron would require a database to be managed,
increasing operational complexity, and state would also need to still
@ -295,7 +295,7 @@ REST API impact
---------------
With a MVP, we do not anticipate any REST API changes to Ironic itself
with the very minor exception of the loosing of a Regular Expression
with the very minor exception of the losing of a Regular Expression
around what Ironic accepts for VIF attachment requests. This was agreed
upon by the Ironic community quite some time ago and just never performed.
@ -398,7 +398,7 @@ Performance Impact
------------------
This proposal is intentionally designed to be limited and isolated
to minimze risk and reduce deployment complexity. It is also intentionally
to minimize risk and reduce deployment complexity. It is also intentionally
modeled as a tool to "do something", and that "something" happens to be
configuration in area where device locking is necessary. This realistically
means that the only content written to disk is going to be lock files.
@ -464,7 +464,7 @@ Past initial prototyping, the following may apply order:
can take place.
* Add support to networking-baremetal for it to proxy the request
through to this service for port binding requests in Neutron.
* Design a new model, likely superceeding VIFS, but vifs could just also be
* Design a new model, likely superseding VIFS, but vifs could just also be
an internal network ID moving forward. This would likely be required for
formal adoption of the functionality by Metal3, but standalone users could
move to leverage this immediately once implemented.
@ -496,7 +496,7 @@ Upgrades and Backwards Compatibility
This functionality is anticipated to be "net new" for Ironic and exposed
to end users through a dedicated ``network_interface`` module which could
be selected by users at a point in the future. As such no upgrade or backwards
compatability issues are anticipated.
compatibility issues are anticipated.
Documentation Impact
====================

8
specs/approved/merge-inspector.rst
View File

@ -88,7 +88,7 @@ Inspection data
Inventory
In the broad sense - synonym to inspection data. In the narrower sense -
hardward inventory_ as defined by IPA and returned by its hardware managers.
hardware inventory_ as defined by IPA and returned by its hardware managers.
Inspection collectors
IPA plugin responsible for collecting inspection data on the ramdisk side.
@ -499,7 +499,7 @@ configuration`_):
the ``valid_interfaces`` collection with a new boolean interface field
``is_added``.
The list of available optoinal hooks (adapted from existing Inspector hooks):
The list of available optional hooks (adapted from existing Inspector hooks):
``accelerators``
Sets the ``accelerators`` property based on the available accelerator devices
@ -691,7 +691,7 @@ The new ``[auto_discovery]`` section will have these options:
.. note::
Inspector has several options to tune the freshly created nodes. I believe
that this complex logic should rather be implementated with inspection
that this complex logic should rather be implemented with inspection
rules. The follow-up inspection rules spec will have some additions to make
it easier.
@ -733,7 +733,7 @@ the conductor handling inspection. The RPC call will be:
"""
No notifications will be done for JSON RPC transport. This will be documented
as a known limitation. The futher work as part of the `cross-conductor RPC
as a known limitation. The further work as part of the `cross-conductor RPC
effort <https://review.opendev.org/c/openstack/ironic-specs/+/873662>`_ may
eventually lift it.

2
specs/approved/node-history.rst
View File

@ -85,7 +85,7 @@ be truncated to 1000 characters.
``conductor`` is the hostname of the conductor who recorded the entry.
``user`` is the requestor for the operation from the context, for the Identify
``user`` is the requester for the operation from the context, for the Identify
service it's a string with fixed length.

2
specs/approved/node-retirement.rst
View File

@ -80,7 +80,7 @@ where a retired node would receive another instance. Otherwise, 'retired' set
to True shall not interfere with cleaning or rebuilding.
Nodes with 'retired' set to True cannot move from manageable to available
(to prevent accidental re-use): the "provide" verb is blocked. In order to
(to prevent accidental reuse): the "provide" verb is blocked. In order to
move these nodes to available, the 'retired' field needs to be set to False
first.

2
specs/approved/partition-image-support-for-agent-driver.rst
View File

@ -39,7 +39,7 @@ Proposed change
* Post deploy, agent driver prepares the config for subsequent boot, either
using pxe or vmedia as defined by the driver. Both agent_ipmitool and
agent_ilo driver should support deploy with parition images.
agent_ilo driver should support deploy with partition images.
* Factor out the partitioning code from ironic into a different library
and use it in both IPA and ironic code base.

2
specs/approved/power-fault-recovery.rst
View File

@ -12,7 +12,7 @@ https://storyboard.openstack.org/#!/story/1596107
This spec proposes adding a new node field to reflect any faults detected
by the system. For nodes put into maintenance mode due to power-sync
failures, this proposes a mechanims to try to recover the nodes from
failures, this proposes a mechanisms to try to recover the nodes from
the failure.
Problem description

6
specs/approved/predefined-system-hw-config-single-step.rst
View File

@ -321,7 +321,7 @@ The workflow of configuration import and export consists of parts:
Format of configuration data
----------------------------
The format to store the re-usable configuration is in JSON format and consists
The format to store the reusable configuration is in JSON format and consists
of 3 sections:
* ``bios`` – ``reset`` to indicate if reset is necessary before applying
@ -613,7 +613,7 @@ However, comparing deploy templates to the proposed solution currently:
* No functionality to get the configuration from already configured system,
user has to construct the initial configuration file themselves by hand or
a script. To make it easier, can use cached BIOS and RAID settings from a
node that was deployed, but this re-use is still not built in ironic.
node that was deployed, but this reuse is still not built in ironic.
* Depending on vendor's capabilities each step may require reboot to finish.
For example, iDRAC BIOS configuration apply needs reboot to take effect and
deem the step to be finished. For now ironic cannot line up several steps
@ -700,7 +700,7 @@ Other end user impact
The configuration items can accumulate in the storage as there is no default
timeout or logic that deletes them after a while because these configuration
items should be available after node's cleaning or deployment. If user do not
need the re-usable configuration items anymore, then user should delete those
need the reusable configuration items anymore, then user should delete those
themselves from the storage.
This adds new configuration section ``[molds]`` to control storage location.

6
specs/approved/ramdisk_deploy_virtual_media_boot_iso.rst
View File

@ -11,7 +11,7 @@ Allow a ramdisk deploy user to specify their boot ISO
https://storyboard.openstack.org/#!/story/2007633
With support for virtual media, there are cases where an operator may
wish to boot a machine with a specific virutal media image to facilitate
wish to boot a machine with a specific virtual media image to facilitate
the deployment of a machine or even just the completion of an action like
firmware upgrades.
@ -116,7 +116,7 @@ None
Scalability impact
------------------
The distinct possibiliy exists, if a user requests multiple concurrent
The distinct possibility exists, if a user requests multiple concurrent
deployments, that configuration injection could consume a large amount
of disk space.
@ -174,7 +174,7 @@ Dependencies
Testing
=======
Unit tests should be sufficent for ensuring this functionality is not broken.
Unit tests should be sufficient for ensuring this functionality is not broken.
A tempest test may also be viable, but we may wish to partner with the Metal3
community on integration testing, as ultimately this is essentially just an

22
specs/approved/secure-rbac.rst
View File

@ -50,7 +50,7 @@ Role definitions:
scope. These are accounts which Create/Delete $things,
and in keystone default configuration, this role implies
the ``member`` role. In an Ironic context, we can think of this user
as the infrastucture administrator who is adding their baremetal
as the infrastructure administrator who is adding their baremetal
machines into Ironic.
* member - This is a user which can act upon things. They may be able to read
and write with-in objects, but cannot create/delete new objects
@ -132,7 +132,7 @@ appropriately navigated.
In summary, the purpose of this specification is to make changes in
*ironic* and *ironic-inspector* to be consistent and future compatible
with the rest of the OpenStack community. This will further enable
infrastucture operators where they can leverage the prior community
infrastructure operators where they can leverage the prior community
policy work in the OpenStack community to override the policy defaults
the community reaches.
@ -156,7 +156,7 @@ We will do this by:
removed at a later point in time.
3) Implementing explicit testing to ensure scopes are handled as we expect.
4) Creating an integration test job leveraging the ``oslo.policy`` setting
to enforce scope restriction to help ensure cross-service compatability
to enforce scope restriction to help ensure cross-service compatibility
and potentially having to alter some cross-service interactions to ensure
requests are appropriately modeled. It should be expected that this may
make visible any number of possible issues which will need to be addressed.
@ -194,7 +194,7 @@ enforcement.
.. note::
Adjacent/integrated projects/services, for example is the interaction
between Nova, Neutron, Cinder, Glance, Swift, and Ironic. Services do
convey context on behalf of the original requestor for a period of time,
convey context on behalf of the original requester for a period of time,
and can make access control decisions based up on this. Ironic has
previously had to address these sorts of issues in the Neutron
and Cinder integrations.
@ -358,7 +358,7 @@ or lessee are populated.
.. TODO:: Follow-up with Nova regarding rights passed through on context.
.. NOTE::
The primary focus of this specification is targetted at the Wallaby
The primary focus of this specification is targeted at the Wallaby
development cycle where the System scope is most beneficial to
support. Given time constraints and cross-project mechanics
we will likely see additional work to refine scope interactions
@ -477,7 +477,7 @@ apply. See `Node object field restrictions`_ for details with a Node object.
+------------------------------------+----------------------------------------+
| /v1/deploy_templates | No, `system` scope only at this time. |
| | as the table/data structure is not |
| | modeled for compatability. |
| | modeled for compatibility. |
+------------------------------------+----------------------------------------+
| /v1/chassis | No, `system` scope only. |
+------------------------------------+----------------------------------------+
@ -493,7 +493,7 @@ apply. See `Node object field restrictions`_ for details with a Node object.
project scoped access, however one important item to stress
is that the ``owner`` may be viewed as the ultimate ``manager``
of a physical node, and the ``system``, or ``ironic`` itself
just provides the management infrastucture. This is a valid case
just provides the management infrastructure. This is a valid case
and thus it may be reasonable that we settle on permitting owner
far more access rights than node lesses in a project scope.
@ -569,8 +569,8 @@ Node object field restrictions
from changing the field value.
* description - Read-Write
* conductor - Returns None as it provides insight into the running
infrastucture configuration and state, i.e. System visible is the
onlly appropriate state.
infrastructure configuration and state, i.e. System visible is the
only appropriate state.
* allocation_uuid - Read Only
Special areas:
@ -678,7 +678,7 @@ to logic in the API services.
Other deployer impact
---------------------
Cloud infrastucture operators are anticipated to possibly need to adjust
Cloud infrastructure operators are anticipated to possibly need to adjust
``oslo_policy`` settings to enable or disable these new policies. This may
include cloud operators continuing to use older or other more restrictive
policies to improve operational security.
@ -729,7 +729,7 @@ Phases
The initial phase for deployment is scoped for the eqiuvalent of the existing
project admin scoped authentication for system scoped use.
The next phase, persumably spanning a major release would then cover the
The next phase, presumably spanning a major release would then cover the
project scoped access rights and changes.
Dependencies

16
specs/approved/service-steps.rst
View File

@ -70,7 +70,7 @@ in the same line of ``clean steps``, then the node state will return to the
**servicing** state, heartbeat, and upon all steps completed, the node will
automatically return to the **active** state.
To achive this, we will also need to:
To achieve this, we will also need to:
* Add an additional ``service_step`` field to the Node object. Similar to clean
steps, a ``service_steps`` entry would also be utilized in the node
@ -104,7 +104,7 @@ explicit steps into the step process.
set of steps have been received.
* ``pause`` - This step would pause the step execution for a user defined
period of time. Think of this as "sleep". In all liklihood, this step is
period of time. Think of this as "sleep". In all likelihood, this step is
likely to be constrained with a maximum sleep period of the heartbeat
window.
@ -128,7 +128,7 @@ step name in progress, allowing the next step to proceed upon next heartbeat.
.. NOTE:: Ironic *might* need a step which enables the agent token to be
removed to allow the agent to be restarted or rebooted. This is not
anticipated to be a feature, but shouldn't be controversal if deemed
anticipated to be a feature, but shouldn't be controversial if deemed
needed soon afterwards.
Alternatives
@ -168,7 +168,7 @@ New states will be added to the state machine:
| State | Description |
+---------------------+-------------------------------------------------------+
| states.SERVICING | Modifying "unstable" state indicating a lock is held |
| | and action is occuring. |
| | and action is occurring. |
+---------------------+-------------------------------------------------------+
| states.SERVICEWAIT | An intermediate unstable state where Ironic is |
| | waiting for an action such as a `heartbeat` |
@ -291,7 +291,7 @@ The act of removing a node from the service state is anticipated to use the
``do_provision_action`` RPC method, but the API may need to validate the
running RPC version before making the call.
Because of this addition, both sevices will need to be upgraded before this
Because of this addition, both services will need to be upgraded before this
feature can be utilized.
Driver API impact
@ -300,7 +300,7 @@ Driver API impact
Decorators will need to be added/modified to enable the steps to be
appropriately validated and invoked when the feature is needed. No other
driver API changes are anticipated. It should be noted this is not a breaking
change, we only note it because it will need to be performed on relevent
change, we only note it because it will need to be performed on relevant
actions/steps.
Nova driver impact
@ -323,7 +323,7 @@ Ramdisk impact
A ``get_service_steps`` and ``execute_service_step`` methods are anticipated
as being needed to support this functionality in the agent. A lack of these
agent side comands are not to be considered faults.
agent side commands are not to be considered faults.
It is expected that we would likely want the agent to just to continue to
heartbeat while waiting for work to do, which is not breaking for older
@ -426,7 +426,7 @@ scenario will exercuse one of the ``pause``, ``wait``, or ``hold`` steps.
Upgrades and Backwards Compatibility
====================================
No additional upgrade or compatability issues are anticipated aside from
No additional upgrade or compatibility issues are anticipated aside from
what has already been noted and explored in this document.
Documentation Impact

18
specs/approved/shard-key.rst
View File

@ -88,13 +88,13 @@ unless ``nova-compute`` or some other API consumer were to request the
``shard`` to be updated on a node.
.. NOTE::
The overall process consumers use today is to retreive everything and
The overall process consumers use today is to retrieve everything and
then limit the scope of work based upon contents of the result set.
This results in a large overhead of work and increased looping latency
which also can encourage race conditions. Both ``nova-compute``
and the ``networking-baremetal`` ML2 plugin operate in this way with
different patterns of use. The advantage of the the proposed solution
is to enabel the scope limiting/grouping into managable chunks.
is to enable the scope limiting/grouping into manageable chunks.
In terms of access controls, we would also add a new RBAC policy to
restrict changes such that the system itself or a appropriately scoped
@ -137,7 +137,7 @@ specific project ID value fields.
Why not Conductor Group?
~~~~~~~~~~~~~~~~~~~~~~~~
It is important to stress similiarity wise, this *is* similar to conductor
It is important to stress similarity wise, this *is* similar to conductor
groups, however conductor groups were primarily purposed to model the physical
constraints and structure of the baremetal infrastructure.
@ -355,7 +355,7 @@ model.
supplied ``shard`` value to match.
Example: nova-manage ironic-reassign <shard-key> <compute-hostname>
Programattically, this would retrieve a list of nodes matching the key from
Programmatically, this would retrieve a list of nodes matching the key from
Ironic, and then change the associated ComputeNode and Instance tables host
fields to be the supplied compute hostname, to match an existing nova
compute service.
@ -382,13 +382,13 @@ model.
responsible for, and would eventually match the shard key.
This would facilitate an ability to perform a rolling, yet isolated outage
impact as the new nova-compute configuraiton is coming online, and also allows
impact as the new nova-compute configuration is coming online, and also allows
for a flow which should be able to be automated for larger operators.
The manageability, say if one needs to change a ``shard`` or rebalance
shards, is not yet clear. The current discussion in the Nova project is that
rebalance/reassociation will only be permitted *IF* the compute service
has been "forced down" which is an irreversable action
has been "forced down" which is an irreversible action
Ramdisk impact
--------------
@ -428,7 +428,7 @@ Other deployer impact
---------------------
It *is* recognized that operators *may* wish to auto-assign or auto-shard
the node set programatically. The agreed upon limitation amongst Ironic
the node set programmatically. The agreed upon limitation amongst Ironic
contributors is that we (Ironic) would not automatically create *new*
shards in the future. Creation of new shards would be driven by the operator
by setting a new shard key on any given node.
@ -487,7 +487,7 @@ Testing
=======
Unit testing is expected for all the basic components and operations
added ot Ironic to support this funcitonality.
added to Ironic to support this functionality.
We may be able to add some tempest testing for the API field and access
interactions.
@ -496,7 +496,7 @@ Upgrades and Backwards Compatibility
====================================
To be determined. We anticipate that the standard upgrade process would apply
and that there would not realistically be an explicit downgrade compatability
and that there would not realistically be an explicit downgrade compatibility
process, but this capability and functionality is largely for external
consumption, and details there are yet to be determined.

28
specs/approved/smartnics-to-dpus.rst
View File

@ -49,7 +49,7 @@ These are best viewed as a "first generation" of DPU cards where an offload
workload is able to be executed on a card, such as a Neutron agent connected
to the message bus in order to bind ports to the physical machine.
Some initial community and vendor discussions also centered around futher
Some initial community and vendor discussions also centered around further
potential use cases of providing storage attachments through, similar to the
behavior of a Fibre Channel HBA.
@ -65,7 +65,7 @@ virtualize the hardware interaction/modeling like we have with Virtual
Machines.
Aside from some limited hardware offerings from specific vendors, Composible
Hardware largely hasn't been realized as initally pitched by the hardware
Hardware largely hasn't been realized as initially pitched by the hardware
manufacters.
DPUs
@ -167,7 +167,7 @@ evolve.
of scope for their project. Such is sensible to stand-up a general purpose
workload, but operating lifecycle and on-going management is an aspect
where Ironic can help both operators who run a variety of workloads and
configurations, or need to perform more specific lifecyle operations.
configurations, or need to perform more specific lifecycle operations.
Proposed change
===============
@ -189,11 +189,11 @@ child devices.
* Introduction of a new step field value, ``execute_on_child_nodes`` which
can be submitted. The default value is False. Steps which return CLEANWAIT,
i.e. steps which expect asynchronous return will not be permitted under
normal conditions, however this will be avaiable via a configuration option.
normal conditions, however this will be available via a configuration option.
* Introduction of a new step field value, ``limit_child_node_execution``,
which accepts a list of node UUIDs to allow filtering and constraint
of steps on some nodes. Sepcifically, this is largely separate from the
of steps on some nodes. Specifically, this is largely separate from the
``execute_on_child_nodes`` field due to JSON Schema restrictions.
* Introduction of the ability to call a vendor passthrough interface
@ -281,14 +281,14 @@ supporting xPU's in servers with external power supplies in the past, and have
largely been unable to navigate a workable model, in large part because this
model would generally require a single task.node to be able to execute with
levels of interfaces with specific parameters. For example, to the system BMC
for base line power management, and then to a SNMP PDU for the auxillary power.
This model also doesn't necessarilly work because then we would inherently
for base line power management, and then to a SNMP PDU for the auxiliary power.
This model also doesn't necessarily work because then we would inherently
have blocked ourselves from more general managmeent capabilities and access
to on DPU card features such as "serial consoles" through it's own embedded
BMC without substantial refactoring and re-doing the data model.
There is also the possibility that nesting access controls/modeling may not
be appropriate. You don't necessarilly want to offer an baremetal tenant in a
be appropriate. You don't necessarily want to offer an baremetal tenant in a
BMaaS who has lessee access to Ironic, the ability to get to a serial console
which kind of points us to the proposed solution in order to provide
capabilities to handle the inherently complex nature of modeling which can
@ -303,7 +303,7 @@ Chasssis and a Node.
Chassis was originally intended to allow the articulation of entire Racks
or Blade Chassis in Ironic's data model, in part to allow relationship and
resoruce tracking more in lines with a Configuration Management Data Base
resource tracking more in lines with a Configuration Management Data Base
(CMDB) or Asset Inventory. However, Chassis never gained much traction because
those systems are often required and decoupled in enterprise environments.
@ -316,7 +316,7 @@ chassis replaced but the DPU is just moved to the new chassis.
But the inherent one to many modeling which can exist with DPUs ultimately
means that the modeling is in reverse from what is implemented for usage.
Nodes would need to be Chassises, but then how do users schedule/deploy
"instances", much less perform targetted lifecycle operations against part
"instances", much less perform targeted lifecycle operations against part
of the machine which is independent, and can be moved to another chassis.
Overall, this could result in an area where we may make less progress
@ -372,7 +372,7 @@ a big picture view of all things Ironic is responsible for.
GET /v1/nodes/
The view will by default return only nodes where the ``parent_node`` field
is null. Older API clients will still recieve this default behavior change.
is null. Older API clients will still receive this default behavior change.
GET /v1/nodes/<node_ident>/children
@ -406,7 +406,7 @@ Client (CLI) impact
"openstack baremetal" CLI
~~~~~~~~~~~~~~~~~~~~~~~~~
The ``baremetal`` command line interface will need to recieve parameters
The ``baremetal`` command line interface will need to receive parameters
to query child nodes, and query the child nodes of a specific node.
"openstacksdk"
@ -462,7 +462,7 @@ Scalability impact
This change does propose an overall relationship and ability which may result
far more nodes to be managed in ironic's database. It may also be that for
child devices, a power synchronization loop may *not* be needed, or can be
far less frequent. These are ultimately items we need to discuss furhter,
far less frequent. These are ultimately items we need to discuss further,
and consider some additional controls if we determine the need so operators
may not feel any need nor impact to their deployments due to the increase in
rows int the "nodes" table.
@ -477,7 +477,7 @@ Performance Impact
------------------
No direct negative impact is anticipated. The most direct impact will be the
database and some periodics which we have already covered in the preceeding
database and some periodics which we have already covered in the preceding
section. Some overall performance may be avoided by also updating some of
the periodics to not possibly match any child node, the logical case is
going to be things like RAID periodics, which would just never apply and

2
specs/approved/software-raid.rst
View File

@ -227,7 +227,7 @@ None.
Implementation
==============
An inital proof-of-concept is available from [2][3][4].
An initial proof-of-concept is available from [2][3][4].
Assignee(s)
-----------

6
specs/approved/synchronize-events-with-neutron.rst
View File

@ -131,7 +131,7 @@ done. All callbacks will be stored in a simple dictionary keyed by node UUID.
strings, each of which is going to be the corresponding driver interface and
event handler's method name, so that we know which method of the event handler
of a specific driver interface to trigger when an action is asynchronous and
we receieve the event. If an unexpected event is received, we'll be ignoring
we receive the event. If an unexpected event is received, we'll be ignoring
it (and logging that an unexpected event appeared in the API).
Third-party driver interface methods can be also adding things they want to
@ -166,7 +166,7 @@ the port's ``internal_info['network_status']``, and then
``process_event`` is triggered. On the conductor side,
``process_event`` will be doing the event name to event handler method
translation via ``NETWORK_HANDLER_TO_EVENT_MAP``, and calling the event
handler. Conductor will also be dealing with state machine transistions.
handler. Conductor will also be dealing with state machine transitions.
The event handler will be looking at the status of the ironic resources, for
example, in case of network events, we want to save the neutron port status in
@ -313,7 +313,7 @@ Other end user impact
---------------------
The neutron notifier needs to be configured. It needs the keystone admin
credentials and (optionally, if not procided will be discovered from keystone
credentials and (optionally, if not provided will be discovered from keystone
endpoint catalog) the ironic API address to send events to.
Scalability impact

2
specs/approved/virtual-bare-metal-cluster-manager.rst
View File

@ -151,7 +151,7 @@ Multi-Stage Process
* Open vSwitch (containerised?)
* Virtualisation tookit (e.g. Libvirt/QEMU/KVM)
* Virtualisation toolkit (e.g. Libvirt/QEMU/KVM)
* Virtual platform management toolkit: Virtual BMC for IPMI at the
moment. Scope for extension to include other tools in future (e.g.

4
specs/approved/vnc-console.rst
View File

@ -27,7 +27,7 @@ experience as compared to serial console.
Horizon's VNC console is not supported for the ironic
nodes provisioned by Nova. This spec intents to extend that to
grapical console via the novnc proxy.
graphical console via the novnc proxy.
The end user will be able to get workable vnc console url from baremetal
server:
@ -57,7 +57,7 @@ Alternatives
* We can configure kvm access including access to the bios via the
serial proxy and shell in a box for nova provisioned ironic baremetal
intances. This would require exposing credentials.
instances. This would require exposing credentials.
* Use out-of-band KVM access provided by administrator without Ironic support.

2
specs/approved/xclarity-driver.rst
View File

@ -126,7 +126,7 @@ Performance Impact
Lenovo XClarity Administrator supports the management of up to 20 chassis with
compute nodes and a similar number of rack servers. An operator with a large
number of systems being managed by XClarity should expect reduced system
performance. Performace considerations have been provided in references at the
performance. Performance considerations have been provided in references at the
end of this specification.
Ramdisk impact

6
specs/backlog/event-subscription.rst
View File

@ -141,7 +141,7 @@ event subscriptions.
* ``GET /v1/nodes/<node_ident>/management/subscriptions/subscription_bmc_id``
Retrieves a sbuscription. Returns a JSON object representing the choosen
Retrieves a sbuscription. Returns a JSON object representing the chosen
subscription (``subscription_bmc_id``).
Error codes:
@ -272,7 +272,7 @@ None.
Security impact
---------------
It is recomended to use https.
It is recommended to use https.
Other end user impact
---------------------
@ -319,7 +319,7 @@ Redfish Implementation Details
The actual support for EventDestination in sushy is based on schema [2]_,
since HW vendors are still working on adding support for newer versions where
the propertie ``EventTypes`` is deprecated. Based on this the Ironic API
the property ``EventTypes`` is deprecated. Based on this the Ironic API
will only accept the following redfish properties to create a subscription:
* Destination - Required

2
specs/backlog/obtaining-steps.rst
View File

@ -80,7 +80,7 @@ Addition of a ``hold`` provision state verb and ``holding`` state.
.. Note::
During a specific planning and discussion meeting to determine the path
for a feature such as this, the ironic community reached a consensus on
the call that a holding state would be useful, and could likey be
the call that a holding state would be useful, and could likely be
implemented aside from the API functionality proposed in this backlog
specification.

4
specs/backlog/support-per-driver-sensor-meters.rst
View File

@ -146,8 +146,8 @@ for sensors in Juno.
The proposal is to drop the ipmi component string from the meter name so that
meter names become provider indepenent. Transforming the above to the proposed
meter naming would result in the following meter names in Ceilometer.
meter names become provider independent. Transforming the above to the
proposed meter naming would result in the following meter names in Ceilometer.
::

2
specs/juno-implemented/add-nodelocked-retry.rst
View File

@ -112,7 +112,7 @@ Scalability impact
This does have the possibility to negatively impact scalability. A spawned
worker thread within the conductor could potentially take longer to
process the work if a NodeLocked expection is thrown. This impact can be
process the work if a NodeLocked exception is thrown. This impact can be
mitigated by increasing the number of workers in the pool (the
workers_pool_size option).

2
specs/juno-implemented/ironic-ilo-virtualmedia-driver.rst
View File

@ -297,7 +297,7 @@ specified as a glance meta-property ``boot_iso`` for the image to be deployed.
Utilities will be provided in diskimage-builder for creating the deploy ISO.
This method of deploy doesn't require an extra service (like tftp service
incase of pxe driver) to be running on the conductor node.
in case of pxe driver) to be running on the conductor node.
Developer impact
----------------

2
specs/juno-implemented/send-data-to-ceilometer.rst
View File

@ -241,7 +241,7 @@ References
==========
* `Ceilometer spec`_
* `Review in progress`_ for sending notifcation from Ironic.
* `Review in progress`_ for sending notification from Ironic.
* `Sample data`_
.. _Ceilometer spec: https://blueprints.launchpad.net/ironic/+spec/send-data-to-ceilometer

2
specs/juno-implemented/support-external-dhcp.rst
View File

@ -40,7 +40,7 @@ configuration options.
The two initial provider implementations will be "neutron" and "none".
Neutron functioality that does not relate to DHCP (ie. updating a port's MAC
Neutron functionality that does not relate to DHCP (ie. updating a port's MAC
address) will not be moved.
Alternatives

2
specs/kilo-implemented/driver-periodic-tasks.rst
View File

@ -73,7 +73,7 @@ Alternatives
* Each time modify conductor when we need a periodic task. That requires a
consensus on how to make it in a generic way.
* Just use ``LoopingCall``. I believe that this approach is less controlable
* Just use ``LoopingCall``. I believe that this approach is less controllable
(in terms of how many threads we run, how many requests we make to e.g. DRAC
BMC etc) and leads to code duplication.

2
specs/kilo-implemented/expose-configdrive.rst
View File

@ -53,7 +53,7 @@ Proposed change
===============
Nova's Ironic virt driver will generate a config drive image, gzip
and base64 enconde it and pass to the Ironic service as part of the
and base64 encode it and pass to the Ironic service as part of the
setting provision state call. This is discussed in more detail in this
nova spec.[0]

2
specs/kilo-implemented/new-ironic-state-machine.rst
View File

@ -98,7 +98,7 @@ New state machine::
^ +
| |R:active
+ v
[DELET*/AVAILABLE] [DEPLOY*/ACTIVE]
[DELETE*/AVAILABLE] [DEPLOY*/ACTIVE]
^ + ^
|R:delete | |R:rebuild
| v +

2
specs/kilo-implemented/root-device-hints.rst
View File

@ -139,7 +139,7 @@ Deployers will have a finer granularity in selecting the disk device
to be used for the deployment.
.. note::
When specifing device size as a hint operator needs to make sure that
When specifying device size as a hint operator needs to make sure that
the value doesn't conflict with the local_gb properties of the node.
This is going to be documented as part of this spec.

4
specs/liberty-implemented/drac-bios-mgmt.rst
View File

@ -88,7 +88,7 @@ Four new API calls:
* 200 if the set of proposed new parameters passed validation and
was accepted for further processing.
* 204 if the set of proposed new paramters passed validation, but
* 204 if the set of proposed new parameters passed validation, but
did not actually change the BIOS configuration.
* 409 if the set of proposed new parameters contains a parameter
@ -119,7 +119,7 @@ Four new API calls:
* 200 if the proposed changes were successfully dequeued.
* 204 if there were no proposed chages to dequeue
* 204 if there were no proposed changes to dequeue
* 403 if the proposed changes are already in the process of being
committed.

2
specs/liberty-implemented/new-boot-interface.rst
View File

@ -33,7 +33,7 @@ Proposed change
===============
* A new ``BootInterface`` needs to be added. The interface will recommend the
following methods for the implementor::
following methods for the implementer::
@six.add_metaclass(abc.ABCMeta)
class BootInterface(object):

6
specs/liberty-implemented/supported-boot-device-list.rst
View File

@ -35,7 +35,7 @@ list of supported boot devices to return.
This change would be backwards compatible, using inspect to determine if
a specific driver as implemented the "task" parameter or not, and showing
a deprecation warning if "task" paramater has not been implemented.
a deprecation warning if "task" parameter has not been implemented.
This deprecation of get_suported_boot_devices() without task parameter will
be done in the next release, after which get_supported_boot_devices() without
@ -138,7 +138,7 @@ None
Developer impact
----------------
All in-tree driver and unit tests will be amended to include the new "task"
parameter. Out of tree drivers will see a depracation warning until they
parameter. Out of tree drivers will see a deprecation warning until they
implement the new "task" parameter.
@ -156,7 +156,7 @@ Work Items
* Add "task" to get_supported_devices_list() in base driver
* Add new management property definition to check if
driver supports task parameter or not.
* Update all in tree drivers adding task paramater
* Update all in tree drivers adding task parameter
* Update all unit tests affected by change
Dependencies

2
specs/retired/openbmc-driver.rst
View File

@ -16,7 +16,7 @@ OpenBMC and the addition of driver to the IPA and PXE driver classes.
.. NOTE::
This specification is no longer viewed as applicable as OpenBMC has support
for the Redfish API interface, and as such this is considered a superior
standards based interface for use. When this specificaiton was proposed,
standards based interface for use. When this specification was proposed,
These the Redfish API had not yet been implemented in OpenBMC.
Problem description

2
specs/retired/snapshot-support.rst
View File

@ -100,7 +100,7 @@ guarded by microversions.
to a location where the snapshot image should be stored.
If the ``image_ref`` is an UUID, it refers to the UUID of an image in the
Image serivce, the image should be precreated before snapshot request and
Image service, the image should be precreated before snapshot request and
acts as a holder for receiving image data. When integrated with Compute
service, the ``image_id`` is an argument passed to the driver interface
``snapshot()``.