Merge "Add 2023.2 Workitems discussed at Ironic PTG"
This commit is contained in:
Zuul
Gerrit Code Review
commit
c6976aa2d2
|
|
@ -15,6 +15,7 @@ those discussions:
|
|||
:glob:
|
||||
:maxdepth: 1
|
||||
|
||||
priorities/2023-2-workitems
|
||||
priorities/2023-1-workitems
|
||||
priorities/zed-themes
|
||||
priorities/yoga-themes
|
||||
|
|
@ -35,7 +36,7 @@ those discussions:
|
|||
Specifications
|
||||
==============
|
||||
|
||||
Specifications for the ironic project are available here. Specifications
|
||||
Specifications for the Ironic project are available here. Specifications
|
||||
begin life in the "approved" tree. They stay there (possibly beyond the
|
||||
development cycle in which they had been approved), and once implemented,
|
||||
are moved to the "implemented" tree for that development cycle.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,245 @@
|
|||
.. _2023-2-work-items:
|
||||
|
||||
=========================
|
||||
2023.2 Project Work Items
|
||||
=========================
|
||||
|
||||
Most Ironic contributors have a large number of responsibilities, including
|
||||
but not limited to, keeping CI working across all branches and projects,
|
||||
backporting bugfixes, and any downstream job responsibilities that do not
|
||||
include Ironic contribution.
|
||||
|
||||
Because of how much this work can vary over a six month release cycle, we
|
||||
do not specify timelines for specific work items. Instead, we document planned
|
||||
items we would like to see completed, and then allow the community to pick up
|
||||
and work on them as time permits. Items are listed in no particular order.
|
||||
|
||||
This document represents our outlook for 2023.2, and will not be updated once
|
||||
published. For information or current status of items in progress, please see
|
||||
the Ironic Whiteboard at https://etherpad.openstack.org/p/IronicWhiteBoard.
|
||||
For information about items completed, please see the Ironic release notes.
|
||||
|
||||
Each item in the table includes:
|
||||
- Name of the work item, linked to the description
|
||||
- Category can be...
|
||||
- Maintenance: work that must be performed to keep Ironic working
|
||||
- Bugfix: work to enhance existing code to cover more corner cases and
|
||||
resolve bugs
|
||||
- Feature: a new Ironic feature that did not previously exist
|
||||
- Champions are the people most familiar with the technologies involved,
|
||||
and are a good resource if you'd like to implement the work item.
|
||||
|
||||
.. list-table:: 2023.2 Work Items
|
||||
:widths: 70 20 10
|
||||
:header-rows: 1
|
||||
|
||||
* - Name
|
||||
- Category
|
||||
- Champions
|
||||
|
||||
* - `Nova Ironic Driver sharding`_
|
||||
- Bugfix
|
||||
- JayF, johnthetubaguy, TheJulia
|
||||
|
||||
* - `Remove default use of MD5`_
|
||||
- Bugfix
|
||||
- TheJulia
|
||||
|
||||
* - `Merging Inspector into Ironic`_
|
||||
- Maintenance
|
||||
- dtantsur
|
||||
|
||||
* - `Service Steps`_
|
||||
- Feature
|
||||
- TheJulia
|
||||
|
||||
* - `Conductor Graceful Shutdown`_
|
||||
- Bugfix
|
||||
- stevebaker
|
||||
|
||||
* - `FIPS Compatibility jobs in CI`_
|
||||
- Feature
|
||||
- Ade Lee
|
||||
|
||||
* - `Cross-conductor communication`_
|
||||
- Feature
|
||||
- TheJulia
|
||||
|
||||
* - `Hierarchical Nodes`_
|
||||
- Feature
|
||||
- TheJulia
|
||||
|
||||
* - `Improving Deploy Kernel/Ramdisk Config`_
|
||||
- Feature
|
||||
- None
|
||||
|
||||
* - `IPA Communication`_
|
||||
- Bugfix
|
||||
- kaloyank
|
||||
|
||||
* - `Firmware Updates`_
|
||||
- Feature
|
||||
- iurygregory, dtantsur, janders
|
||||
|
||||
Goals Details
|
||||
=============
|
||||
|
||||
Nova Ironic Driver Sharding
|
||||
---------------------------
|
||||
The failure scenarios around the existing Nova Ironic driver are grim: when
|
||||
an instance is provisioned, it's permanently tied to the nova-compute that
|
||||
provisioned it and cannot be managed if that compute goes down. Additionally,
|
||||
at high scale, there are more race conditions due to the length of time it
|
||||
takes to query all Ironic nodes.
|
||||
|
||||
Last cycle we added support for Ironic, to allow assigning a shard key to
|
||||
nodes that can be used by clients, including Nova, can consume to split
|
||||
Ironic node management across a cluster of services.
|
||||
|
||||
We hope to continue progress on this goal by implementing support for sharding
|
||||
APIs in openstacksdk and python-ironicclient. Then, we will add support in the
|
||||
Nova driver and networking-baremetal for sharding queries.
|
||||
|
||||
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
|
||||
it via config.
|
||||
|
||||
Merging Inspector into Ironic
|
||||
-----------------------------
|
||||
Ironic Inspector was originally created as a service external to Ironic. Now,
|
||||
it's used by a large number of Ironic operators around the world and should
|
||||
be integrated with the primary service.
|
||||
|
||||
Last cycle, the Node Inventory API was implemented in Ironic. Next, we will
|
||||
move the rest of inspector functionality into Ironic. For more information,
|
||||
see the relevant specs:
|
||||
|
||||
`Merge Inspector into Ironic <https://review.opendev.org/c/openstack/ironic-specs/+/878001>`_
|
||||
`Migrate inspection rules from Inspector <https://review.opendev.org/c/openstack/ironic-specs/+/878230>`_
|
||||
|
||||
Service 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 maintenance on actively
|
||||
deployed nodes. This new Service Steps (formerly referred to as "Active Steps")
|
||||
feature will allow operators to perform a firmware update -- or any other
|
||||
automated action on a provisioned, ACTIVE node.
|
||||
|
||||
We will also be implementing some basic flow control steps into Ironic. These
|
||||
commands, such as 'hold' and 'pause' will enable using steps to inform Ironic
|
||||
to wait for an external API client or a configured period of time before
|
||||
continuing. Additionally, we will evaluate more hardware and API actions to
|
||||
expose as steps, such as power and BMC actions.
|
||||
|
||||
Conductor Graceful Shutdown
|
||||
---------------------------
|
||||
Initial work on gracefully shutting down by waiting for all locks to be
|
||||
released was completed early in the Bobcat cycle. Next, we will work on support
|
||||
for draining a conductor of tasks before shutting it down. The goal is to
|
||||
ensure no in-progress actions are interrupted. This will allow for truly
|
||||
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>`_
|
||||
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.
|
||||
|
||||
Cross-conductor communication
|
||||
-----------------------------
|
||||
Many conductor management actions taken on a node are written with assuming
|
||||
a single conductor will perform them. This is not great for availability or
|
||||
maintenance scenarios. We will be looking to implement some form of cross-
|
||||
conductor communication to permit conductors to hand off work when being
|
||||
shut off.
|
||||
|
||||
For more information, see
|
||||
`the cross-conductor rpc hand-off spec <https://review.opendev.org/c/openstack/ironic-specs/+/873662>`_.
|
||||
|
||||
Hierarchical Nodes
|
||||
------------------
|
||||
Many new pieces of technology, such as DPUs, are presenting more complex
|
||||
interfaces to hardware integrators. Architectures have emerged with nested
|
||||
devices, with multiple firmwares and multiple nested operating systems to
|
||||
manage. In order to support these, we are introducing parent/child relationship
|
||||
to nodes. For more information, see `the DPU management/orchestration spec <https://review.opendev.org/c/openstack/ironic-specs/+/874189>`_.
|
||||
|
||||
Improving Deploy Kernel/Ramdisk Config
|
||||
--------------------------------------
|
||||
Ironic currently offers two places to easily manage deploy kernel and ramdisk:
|
||||
configuration file, for global settings, and node metadata for per-node
|
||||
overrides. This presents a problem for operators who want to operate Ironic
|
||||
with hardware that requires different ramdisks; such as ARM and x86 -- they
|
||||
will have to make "N" API calls for "N" nodes to update their non-default arch
|
||||
ramdisks.
|
||||
|
||||
To resolve this problem, we'll be introducing config to allow setting default
|
||||
ramdisks per-architecture. This will allow operators to set a different default
|
||||
ramdisk for ARM and x86 nodes.
|
||||
|
||||
IPA Communication
|
||||
-----------------
|
||||
The current method of communication between Ironic and the Ironic Python Agent
|
||||
ramdisk, including the agent token for security, is fragile in some use cases,
|
||||
including neutron-integrated deployments with fast-track mode enabled.
|
||||
|
||||
Ironic contributors will be looking at ways to improve the communication with
|
||||
the goal in mind to improve behavior around complex scenarios like the one
|
||||
mentioned above.
|
||||
|
||||
For more information, see `the IPA communication spec <https://review.opendev.org/c/openstack/ironic-specs/+/777172>`_.
|
||||
|
||||
Firmware Updates
|
||||
----------------
|
||||
Ironic currently supports firmware updates via steps run in cleaning or
|
||||
deployment. However, this is not ideal because it requires significant operator
|
||||
understanding to perform updates.
|
||||
|
||||
Instead, as we have for BIOS and RAID, we will create a dedicated firmware
|
||||
update interface, which will give a standard way to upgrade and manage
|
||||
firmware.
|
||||
|
||||
See `the firmware update spec <https://review.opendev.org/c/openstack/ironic-specs/+/878505>`_
|
||||
for more information.
|
||||
|
||||
|
||||
Release Schedule
|
||||
================
|
||||
Contributors are reminded of our scheduled releases when they are choosing
|
||||
items to work on.
|
||||
|
||||
The dates below are a guide; please view
|
||||
https://releases.openstack.org/bobcat/schedule.html for the full schedule
|
||||
relating to the release and
|
||||
https://docs.openstack.org/ironic/latest/contributor/releasing.html for Ironic
|
||||
specific release information. Please reach out to the Ironic team if you
|
||||
would like to request a bugfix release.
|
||||
|
||||
Bugfix Release 1
|
||||
----------------
|
||||
The first bugfix release opportunity is the first week of May.
|
||||
|
||||
Bugfix release 2
|
||||
----------------
|
||||
The second bugfix release opportunity is the first week of July.
|
||||
|
||||
Deadline Week
|
||||
-------------
|
||||
There are multiple deadlines/freezes the week of August 28th:
|
||||
* Final release of client libraries must be performed
|
||||
* Requirements freeze
|
||||
* Soft string freeze - Ironic services are minimally translated; this
|
||||
generally doesn't apply to our services, such as API and Conductor, but may
|
||||
impact us via other projects which are translated.
|
||||
* Feature Freeze - Ironic does not typically have a feature freeze, but we may
|
||||
be impacted by other projects that do have a feature freeze at this date.
|
||||
|
||||
Final 2023.2 (Integrated) Release
|
||||
---------------------------------
|
||||
The final releases for Ironic projects in 2023.1 must be cut by September 29,
|
||||
2023.
|
||||
Loading…
Reference in New Issue