This document provides some necessary points for developers to consider when writing and reviewing Ironic code. The checklist will help developers get things right.
If you’re completely new to OpenStack and want to contribute to the ironic project, please start by familiarizing yourself with the Infra Team’s Developer Guide. This will help you get your accounts set up in Launchpad and Gerrit, familiarize you with the workflow for the OpenStack continuous integration and testing systems, and help you with your first commit.
Most of the tools used for OpenStack require a launchpad.net ID for authentication.
[ironic]
)Starting with the Mitaka development cycle, Ironic tracks new features using RFEs (Requests for Feature Enhancements) instead of blueprints. These are bugs with ‘rfe’ tag, and they should be submitted before a spec or code is proposed. When a member of ironic-drivers launchpad team decides that the proposal is worth implementing, a spec (if needed) and code should be submitted, referencing the RFE bug. Contributors are welcome to submit a spec and/or code before the RFE is approved, however those patches will not land until the RFE is approved.
When working on an RFE, please be sure to tag your commits properly: “Partial-Bug: #xxxx” or “Related-Bug: #xxxx” for intermediate commits for the feature, and “Closes-Bug: #xxxx” for the final commit. It is also helpful to set a consistent review topic, such as “bug/xxxx” for all patches related to the RFE.
If the RFE spans across several projects (e.g. ironic and python-ironicclient), but the main work is going to happen within ironic, please use the same bug for all the code you’re submitting, there is no need to create a separate RFE in every project.
Note
Currently the Ironic bug tracker is managed by the open ‘ironic-bugs’ team, not the ironic-drivers team. This means that anyone may edit bug details, and there is room to game the system here. RFEs may only be approved by members of the ironic-drivers team.
If you would like some help, or if you (or some members of your team) are unable to continue working on the feature, updating and maintaining the changes, please let the rest of the ironic community know. You could leave a comment in one or more of the changes/patches, bring it up in IRC, the weekly meeting, or on the OpenStack development email list. Communicating this will make other contributors aware of the situation and allow for others to step forward and volunteer to continue with the work.
In the event that a contributor leaves the community, do not expect the contributor’s changes to be continued unless someone volunteers to do so.
As with any large project, it does take time for features and changes to be merged in any of the project repositories. This is largely due to limited review bandwidth coupled with varying reviewer priorities and focuses.
When establishing an understanding of complexity, the following things should be kept in mind.
The driver_internal_info
node field was introduced in the Kilo release. It allows
driver developers to store internal information that can not be modified by end users.
Here is the list of existing common and agent driver attributes:
is_whole_disk_image
: A Boolean value to indicate whether the user image contains ramdisk/kernel.clean_steps
: An ordered list of clean steps that will be performed on the node.instance
: A list of dictionaries containing the disk layout values.root_uuid_or_disk_id
: A String value of the bare metal node’s root partition uuid or disk id.persistent_boot_device
: A String value of device from ironic.common.boot_devices
.is_next_boot_persistent
: A Boolean value to indicate whether the next boot device is
persistent_boot_device
.agent_url
: A String value of IPA API URL so that Ironic can talk to IPA
ramdisk.hardware_manager_version
: A String value of the version of the hardware
manager in IPA ramdisk.target_raid_config
: A Dictionary containing the target RAID
configuration. This is a copy of the same name attribute in Node object.
But this one is never actually saved into DB and is only read by IPA ramdisk.Note
These are only some fields in use. Other vendor drivers might expose more driver_internal_info
properties, please check their development documentation and/or module docstring for details.
It is important for developers to make sure these properties follow the precedent of prefixing their
variable names with a specific interface name (e.g., ilo_bar, drac_xyz), so as to minimize or avoid
any conflicts between interfaces.
Specifications must follow the template which can be found at specs/template.rst, which is quite self-documenting. Specifications are proposed by adding them to the specs/approved directory, adding a soft link to it from the specs/not-implemented directory, and posting it for review to Gerrit. For more information, please see the README.
The same Gerrit process as with source code, using the repository ironic-specs, is used to add new specifications.
All approved specifications are available at: https://specs.openstack.org/openstack/ironic-specs. If a specification has been approved but not completed within one or more releases since the approval, it may be re-reviewed to make sure it still makes sense as written.
Ironic specifications are part of the RFE (Requests for Feature Enhancements) process. You are welcome to submit patches associated with an RFE, but they will have a -2 (“do not merge”) until the specification has been approved. This is to ensure that the patches don’t get accidentally merged beforehand. You will still be able to get reviewer feedback and push new patch sets, even with a -2. The list of core reviewers for the specifications is small but mighty. (This is not necessarily the same list of core reviewers for code patches.)
For approved but not-completed specs:
For approved and completed specs:
Please see the Ironic specs process wiki page for further reference.
Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.