This change adds two network boot interfaces, ``http`` and
``http-ipxe``. These interfaces are based upon the underlying PXE
boot interface code in ironic, and where this differs is it signals
to Ironic that we must do the boot loader needful in terms of telling
DHCP to send a URL instead of a filename and IP address for PXE
as a starting point.
The naming of the interfaces focuses more on the transport mechanism
and then specific style. Very similar to existing ``pxe`` and ``ipxe``
interface modeling, except in the ``ipxe`` case, it is more a specific
loader and mechanism to be utilized.
Related-Bug: #2032380
Change-Id: Ie7ace88b62b9179f640ef2a732dd228e12bd320d
No real inspection is done: it only accepts data and returns success.
Common code has been extracted from the existing inspector-based
implementation.
Change-Id: I7462bb2e0449fb1098fe59e394b5c583fea89bac
FirmwareInterface base
New Config options [default]
- enabled_firmware_interfaces
- default_firmware_interface
New FirmwareInterface base with update method
Implementations of FirmwareInterface
- FakeFirmware (fake)
- NoFirmware (no-firmware)
New entrypoint ironic.hardware.interfaces.firmware
* fake and no-firmware
Api Controllers
- Updated: driver/node/utils/versions
- Created: firmware
Unit tests
api-ref for Node Firmware
Fake and Noop implementation for FirmwareInterface
Change-Id: Ib3b9cb22099819f97d5eab1e3f1b670cb91cbb25
The iSCSI deploy was very easy to start with, but it has since become
apparently that it suffers from scalability and maintenance issues.
It was deprecated in the Victoria cycle and can now be removed.
Hide the guide to upgrade to hardware types since it's very outdated.
I had to remove the iBMC diagram since my SVG-fu is not enough to fix it.
Change-Id: I2cd6bf7b27fe0be2c08104b0cc37654b506b2e62
This change adds a new deploy-interface custom-agent that is essentially
the direct deploy without the write_image step and without bootloader
handling. It's targeted at deployments that need to write the image
differently, while keeping all other aspects the same.
The existing AgentDeploy becomes a subclass of the new CustomAgentDeploy
class, serving as a convenient base class for downstream deploy
interfaces that use IPA.
Change-Id: Ie126ce677c79f102e382305650bddb7f09834483
Story: #2008719
Task: #42059
This change adds 'anaconda' group and 'default_ks_template'
configuration option under that group to ironic configuration file.
Along with this change a new boot_option named 'kickstart' is added
to identify anaconda kickstart deploy in the boot interface.
deploy_utils.get_boot_option method is modified to check if
node.deploy_interface is set to 'anaconda' and return boot_option
'kickstart'.
This change also validates whether required parameters are set when
the boot_option on the node is set to 'kickstart'.
When boot_option is 'kickstart' we also validate if the glance image
source has 'squashfs_id' property associated with it.
Change-Id: I2ef7c33e2e63e6d08c084b4c5dbd77a44ddd2d14
Story: 2007839
Task: 41675
This change marks the iscsi deploy interface as deprecated and
stops enabling it by default.
An online data migration is provided for iscsi->direct, provided that:
1) the direct deploy is enabled,
2) image_download_source!=swift.
The CI coverage for iscsi deploy is left only on standalone jobs.
Story: #2008114
Task: #40830
Change-Id: I4a66401b24c49c705861e0745867b7fc706a7509
This change adds a new 'agent' power interface that can be used together
with fast-track to deploy nodes without knowing their power credentials.
It relies on the agent staying powered on during the whole pre-deployment
and deployment process.
Story: #2007771
Task: #39995
Change-Id: I3d7157c1c4464b650adebbd7f894ee33d0f8f25b
The current fake management interface fails when setting boot device to
disk, which makes manual-management unusable with boot_option:local.
As always with the noop management, we expect an operator to correctly
configure the boot order (e.g. to PXE with fall back to disk).
Change-Id: I551efa1a23dd3d6b33401610f298f436e8317539
A long time ago, in a galaxy not so far away,
the ironic comunity reached consensus that we
should refactor the PXE interface such that we
had separate PXE and iPXE interfaces.
In looking at what it would take for something like
a standalone deployment to have multiarchitecture
support in their environment, it seems even more
urgent and necessary that we begin to make this
delineation. This is because while some ARM iPXE
support exists, the binary is not a commonly
shipped artifiact, so operators are largely
only left with grubaa64.efi as their bootloader.
A similar issue exists with ppc64le deployments
where they must disable iPXE, as the ppc64le
hardware expects reading a syslinux compatible
file, similarlly no iPXE loader exists.
To start this effort, we need to promote iPXE
functionality to a dedicated interface,
and remove the necessity of setting the
[pxe]ipxe_enabled setting.
Next steps, beyond this patch, would be to
begin to tease out the common private method
code in the underlying PXE interface that both
the iPXE and PXE interfaces use, and appropriately
relocate and refactor that code as necesary.
During this process, we can create an [ipxe]
configuration section, and migrate settings.
Finally, once the deprecation cycle is complete,
we will be able to remove the ipxe logic with-in
the PXE interface.
Change-Id: I392616417c48986e84e50a3ddc7567344bfe3571
Story: #1628069
Task: #10516
Adds a pxe deploy driver to support the concept
of a deployment just consisting of a ramdisk.
Ideally, as long as a kernel and ramdisk are
defined, either by the operator or via a glance
image, the PXE/iPXE template should point the
booted kernel to using ramdisk as the root.
In theory, this would allow deployment via
nova, or directly using the parameters posted
to the node's instance_info.
There may be additional features realistically
needed for this to be beyond minimally useful,
but that would also depend on the contents of
the ramdisk that is deployed by an API user.
Change-Id: Id7067527cba27ed49753736f33ccb35e9b35bcba
Story: 1753842
Task: 10666
This would primarily be very useful for users of an
external SAN image based management solution[0] where
the interaction with the storage system has been
abstracted from the user but iSCSI targets are still
used.
[0]: https://massopen.cloud/blog/bare-metal-imaging/
Change-Id: I2d45b8a7023d053aac24e106bb027b9d0408cf3a
Story: #1735478
Task: #12562
this patch pulls the ansible deploy interface code
and related ansible playbooks and auxiliary files
from ironic-staging-drivers project into main ironic tree.
As discussed in the spec, the use of ramdisk callbacks
(lookup and hearbeats) is now mandatory with this deploy interface.
Playbooks and modules were updated to require Ansible>=2.4,
and custom Ansible module for executing 'parted' was replaced
with usage of built-in Ansible module.
The custom Ansible callback plugin now uses journald logger
by default to adapt to the default DevStack setup.
Documentation and devstack plugin changes enabling automated
testing of this interface will be proposed in followup patches.
Change-Id: I43f54688287953ccb1c2836437aea76236e6560b
Related-Bug: #1526308
This patch enables cinder storage interface for generic hardware. It
also adds storage_interface field to node resource and driver resource
in API and bumps API version to 1.33 so that storage interface can be
set and shown via API.
Change-Id: I2c74f386291e588a25612f73de08e8367795acff
Partial-Bug: #1559691
This adds API version 1.30, which adds dynamic driver parameters
and response fields to `GET /v1/drivers` and `GET /v1/drivers/<name>`.
Changes RAID APIs to work for dynamic drivers.
Also changes GET /v1/drivers/<name>/properties to work for dynamic
drivers. It uses the calculated default implementation for each
interface, when calculating the properties.
Last, changes node and driver vendor passthru to work correctly
for dynamic drivers. Similar to properties, driver vendor passthru
will use the calculated default vendor implementation.
Change-Id: If13e7e7fd368273e84d9a108be93b58150432fae
Partial-Bug: #1524745
This change adds ironic.drivers.generic.GenericHardware which contains
useful defaults. Other hardware types are recommended to derive from it.
Add reasonable vendor-independent defaults to enabled_{deploy,raid,boot}_interfaces
configuration options. Add an entry point for "inspector" inspect implementation.
Also adding ironic.drivers.generic.ManualManagementHardware. This hardware
type is mostly introduced to make unit testing of GenericHardware possible.
However, it also has a potential use case: hardware not covered by
an existing driver or when an existing driver misbehaves. I personally
know people using fake_pxe currently in production for such use cases.
Change-Id: I328191524eb71c2ef51fec02c9cb28087dcf663b
Partial-Bug: #1524745
Julia Kreger