2024.2 Project Work Items¶
During the latest virtual Project Team Gathering happened between April 8 and 12, the Ironic developers and operators discussed multiple topics to plan the work for the next 2024.2 (Dalmatian) release. We summarize the outcome of the discussion in this document, providing a list of the main priorities for the next development cycle. For more information please look at the link for each topic or contact the Ironic team on IRC.
Ironic contributors are busy; they work spanning multiple open source projects, and have varied downstream responsibilities. We cannot guarantee any or all planned work will be completed.
- 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.
Tracking link is a link to the bug (usually) tracking the work.
Name |
Category |
Tracking |
Champions |
|---|---|---|---|
Maintenance |
N/A |
JayF |
|
Feature |
N/A |
stephenfin |
|
Feature |
masghar |
||
Feature |
N/A |
janders, dtantsur, TheJulia |
|
Feature |
N/A |
dtantsur |
|
Maintenance |
N/A |
team effort |
|
Maintenance |
N/A |
JayF, rpittau |
|
Feature |
JayF |
||
Feature |
JayF, TheJulia |
||
Feature |
N/A |
TheJulia |
|
Feature |
N/A |
JayF, cid |
Goals Details¶
Ironic Documentation Improvements¶
We will use the expertise of a professional docs writer to review all the Ironic documentation and propose a list of actionable work that can be performed to improve it.
We went through a first draft during the PTG, but we aim to finalize it and complete the main changes during the Dalmatian cycle.
API response schema validation¶
The SDK team would like to generate OpenAPI schemas for core OpenStack services and store them in-tree to ensure things are complete and up-to-date, to avoid landing another large deliverable on the SDK team, and to allow service teams to fix their own issues.
Eventually API documentation will switch from os-api-ref to a new tool developed and owned by the SDK team, but this is a stretch goal. When this happens, only the Sphinx extension itself will live out-of-tree (like os-api-ref today).
The list of advantages includes:
Having a mechanism to avoid accidentally introducing API changes.
API documentation will be (automatically) validated.
Highlight bugs and issues with the API.
The first steps will be writing a spec and showing a framework example for one API.
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. This work has been progressing well. We will continue to work on this until it is complete.
Redfish Virtual Media Push / UpdateService¶
These are actually two separate proposals with a lot in common, the final goal being finding a way to facilitate virtual media booting and firmware updates by using a “push” model.
We’ll monitor the evolution of the Virtual Media Image Push proposal to the DMTF community, and we’ll consider the UpdateService already present in the Redfish standard as a future alternative to be evaluated possibly in the next cycle.
Virtual Media TLS Validation¶
Fujitsu has already proposed the validation of the TLS connection to the BMC from Ironic, but we need to work on the other direction to validate the virtual media TLS connection from the BMC to the Ironic services.
Slimming Down CI¶
Ironic is one of the major CI consumers in terms of resources.
During the Caracal cycle we’ve been able to reduce the number of jobs run by the Ironic project, but we’ve also added some more. We came to the conclusion that we need to take an approach where we stack more tests in fewer jobs, trying to consolidate down jobs as much as possible and minimize boot interface variation testing.
During the Dalmatian cycle we’ll work first on trying to have Redfish and ipmi in a single ironic job, and update the list of jobs to understand where we can avoid duplication.
Tinycore Alternative for IPA ramdisk¶
Tinycore has been the base for the Ironic Python Agent ramdisk (TinyIPA) used in the tests in the Ironic CI for a long time. Unfortunately it has become less and less tiny during the years, it lacks mirror https support, it uses a lightweight libc which caused issues multiple times, and we need to maintain a very specific series of scripts to be able to build it.
We’d like to explore alternatives to it, the main candidate being a gentoo based image that has also support in DiskImage-Builder.
Ironic Guest Metadata from Nova¶
We seek to unify the guest metadata sent to Ironic with that sent to libvirt.
Ironic currently only sets instance_info/instance_uuid, we want to expand this to include project_id, user_id and flavor name, such that we are more consistent with what is set in Libvirt guest metadata.
All of these fields are deleted when a node is undeployed, similar to instance_uuid today. The project_id might in the future be used to help with Ironic API RBAC.
Service Steps templates¶
We discussed this during the Caracal PTG in October, and as a result a spec was composed.
To move forward we need first to revise the spec with the latest outcome of the discussion during the most recent PTG.
Networking: Project Mercury¶
Networking represents the next step for a truly standalone Ironic, and this means finding alternatives to Openstack-integrated scenarios and therefore to Neutron.
For complete usage in an enterprise use case, Ironic needs a means of networking control, which today is manual unless in a fully integrated OpenStack context. Furthermore, the OpenStack integrated context has some known issues which makes it harder to adopt, so we plan to look for solutions to this difficult operations problem during this development cycle.
Ironic ARM CI¶
OpenStack Ironic uses extensive CI testing to validate things work.
While we support ARM, and have reports in the field of it working, we do not have any ARM representation, aside from unit tests, in our CI.
We aim to use ARM vms as we do for x86 vms and run one or more tempest scenario jobs in Ironic CI.
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/dalmatian/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.
Bugfix Release 1¶
The first bugfix release is scheduled to happen around the first week of June, 2024.
Bugfix release 2¶
The second bugfix release is scheduled to happen the first week of August, 2024.
Deadline Week¶
There are multiple deadlines/freezes the final week of:
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 2024.2 (Integrated) Release¶
The final releases for Ironic projects in 2024.2 must be cut by September 27.
