Add 2023.2 Workitems discussed at Ironic PTG

Change-Id: I65370650dc1ea50caee424d81b31100c5ac9a2b2
This commit is contained in:
Jay Faulkner 2023-04-03 13:57:54 -07:00
parent 6012895619
commit 7e6c5065d8
2 changed files with 247 additions and 1 deletions

View File

@ -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.

View File

@ -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.