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
The anaconda deploy interface was saving internal information in
the node's instance_info, in the user-facing 'stage2' and
'ks_template' fields. This broke rebuilds using a different image
with different stage2 or template specified in the image properties.
This has been fixed by saving the information in the node's
driver_internal_info instead.
Addresses comments/nits from
https://review.opendev.org/c/openstack/ironic/+/827924.
Change-Id: Id9428518d21290fb38a0f7471a2cb69a6cb3ffb2
The anaconda deploy interface has a few issues that are
addressed here:
- fixes logic in get_instance_image_info() for anaconda. If the
ironic node's instance_info doesn't have both 'stage2' and
'ks_template' specified, we weren't using any values from the
instance_info. This has been fixed to use values from
instance_info if specified. Otherwise, they are set as follows:
The 'stage2' value is taken from the image properties.
We use the value for 'ks_template' if it is specified in the
image properties. If not (since it is optional), we use the
config option's '[anaconda]default_ks_template' value.
setting.
- For anaconda's stage2 directory, we were incorrectly creating a
directory using the full path of the stage2 file. It now
correctly creates the right directory.
- The anaconda deploy interface expects the node's instance_info
to be populated with the 'image_url'; added code to do that in
PXEAnacondaDeploy's prepare() method.
- When the deploy is finished and the bm node is being rebooted,
we incorrectly set the node's provision state to 'active'
instead of doing it via the provisioning state machine mechanism.
- The code that was doing the validation of the kickstart file was
incorrect and resulted in errors; this has been addressed.
- The '%traceback' section in the packaged 'ks.cfg.template' file
is deprecated and fails validation, so it has been removed.
Change-Id: I953e948bcfa108d4c8e7b145da2f52b652e52a10
This change removes the documentation to copy master_grub_cfg.txt to
/tftpboot/grub/grub.cfg and instead writes it on conductor startup.
This grub config is a simple redirect config requested by grub network
boot. "master" has been renamed to "initial" as a more accurate label
of its function.
New configuration option [pxe]initial_grub_template allows the deployer
to specify a different initial grub template.
Change-Id: I71191dd399a6c49607f91d69b5b1673799a38624
Host preparation file writing is already done by the __init__ method
of iPXEBoot. This change moves place_loaders_for_boot calls to
iPXEBoot and PXEBoot to be consistent, and to only write the files
when that driver is enabled.
This will mean multiple writes of the same file when subclasses of
these drivers are also enabled, but this overhead will be negligible.
Change-Id: I7e17f4d1a54cd6c5d1a4bf006a0d42db8d123a46
The kickstart template expects a dictionary with 'ks_options'
as the key. Instead build_kickstart_config_options function
returns a dict with keys 'liveimg_url', 'agent_token' and
'heartbeat_url'.
This change fixes this problem by returning a dictionary of
dict with 'ks_options' as key and the dictionary with
keys 'liveimg_url', 'agent_token' and heartbeat_url' as
value.
Fix a bug where the deploy() method of anaconda deploy
interface where it did not return states.DEPLOYWAIT instead
it returned 'None' which caused the instance to go straight to
'active' instead of 'wait call-back'.
Fix issues in the default kickstart template where heartbeat was
missing 'callback_url' parameter and the HTTP method should be
'POST' not 'PUT'.
Fix issues with automated cleaning when anaconda deploy interface
is used.
Anaconda deploy interface could not deploy tarballs as
the disk image sent to the anaconda interface via liveimg --url
kickstart command does not include any file extension. When
no file extension is present the kickstart command liveimg --url
assumes the disk is a mountable partiton image. We fix this
problem by enabling the user to specify file extensions using
a glance image property named 'disk_file_extension' on the OS
image.
Co-Authored-By: Ruby Loo <opensrloo@gmail.com>
Change-Id: I556f8c9efbc5ab0941513c3ecaa2aa3ca7f346ae
The current ramdisk deploy code expects a user to set the boot_option
capability to "ramdisk". Not only is it redundant, it's also not
documented, so chances are high nobody has ever done that.
As a side effect of e6bb99cd8f boot
interfaces no longer validate kernel/ramdisk/image if boot option
is "local". Unless a user explicitly sets boot option to "ramdisk",
the validation will be skipped for the ramdisk deploy.
This patch follows the pattern of the anaconda deploy and makes
get_boot_option always return "ramdisk" for the ramdisk deploy.
In the future we need to refactor this code so that the deploy interface
provides the boot option it works with, but that is a lot of changes.
Change-Id: I25c28df048c706f0c5b013b4d252f09d5a7e57bd
agent_status is used by anaconda ramdisk to inform the
conductor about state of the deployment. Valid agent
states are 'start', 'end' and 'error'. The agent_status_message
is used to describe the why the agent_status is set to a
particular state. Use of these parameters require API
version 1.72 or greater.
When anaconda finishes deployment the agent_status is
set to 'end'. When anaconda ramdisk is unable to deploy
the OS for some reason the agent_status is set to 'error'.
PXEAnacondaDeploy is implemented to handle the 'anaconda'
deploy interface. PXEAnacondaDeploy ties to together pieces
needed to deploy a node using anaconda ramdisk.
Co-Authored-By: Jay Faulkner <jay@jvf.cc>
Change-Id: Ieb452149730510b001c4712bbb2e0f28acfc3c2e
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
1) Do not issue a warning if the boot interface supports configdrive
2) Implement missing support for Swift URLs in configdrives
Change-Id: I4b06478a14ab514d785f8e3972e5afbd79f8d3b5
Currently PXERamdiskDeploy inherits AgentDeploy, which is unnecessary
(it does not use in-band deploy steps or rely on heartbeats) and only
happens to work because AgentDeploy has only one deploy step, which
is not going to be the case soon.
This change extracts common code for tear down and cleaning from
ISCSIDeploy and AgentDeploy into the new AgentBaseMixin and makes
PXERamdiskDeploy inherit it instead.
Also removes the confusion AgentDeployMixin from iscsi_deploy.
Change-Id: Ia6c2e3d98d74fc9c64268db04bc2fb7f5a6f0c1c
Story: #2006963
Task: #40153
Remove the dynamically registered ipxe_enabled option and say goodbye.
Further extracts common bits to the PXEBaseMixin, tuning tests here and
there.
Story: 2007003
Task: 37779
Change-Id: I7c1b2a984d45bd63b4e95b62ce02960924c2ce17
This patch starts removing codes related to ipxe support from the pxe interface,
and extract common logic to the PXEBaseMixin.
Story: 2007003
Task: 37779
Change-Id: Ia621f38d9b6c4570ba6a62ddb8c72244ff3fe33b
The ipxe_enabled configuration option was deprecated for quite a while,
this patch removes it. However the code impact by simply removing the
configuration option is quite large, so the strategy here is to register
the option dynamically but sticks to False, which essentially disabled
the ipxe support in the pxe interface.
Story: 2007003
Task: 37779
Change-Id: I499e627f780b577e351fd39be5fa93a34d384e64
Do not try to configure networks when powered on, unless it's a node
with a SmartNIC, in which case do power on before configuring networks.
A new helper is created based on existing code in agent.py.
Change-Id: I3a8fab7a39b604ed17a690fa9c31b3cd1dbdc6a7
Story: #1528920
Task: #37753
This change implements in-band inspection support for PXE and iPXE
boot interfaces and all in-tree network interfaces.
Story: #1528920
Task: #23184
Change-Id: I470d55add73bae47a2755cde93d4b1e1f30e94a7
Follow-up to commit 08fe4af481 restoring
support for ipa-api-url in custom templates and adding a release note
explaining the change.
Story: #1528920
Change-Id: Ic8fc31fcde9a6f685bb1390a75a6a010c149f628
Currently only ipa-api-url is recognized there, since it's hardcoded
in the templates. Anything else is silently ignored. This patch
fixes it by wiring all provided options in pxe_append_params and
dropping the hardcoded ipa-api-url (provided by agent deploy).
Add some logging to make debugging such issues easier.
Change-Id: I573cf99d52a6965d64c2ed7a87cf901c12ea3fec
Story: #1528920
Task: #37255
PXE is inherently unreliable and sometimes times out without an
obvious reason. It happens particularly often in resource constrained
environments, such as the CI. This change allows an operator to
set a timeout, after which the boot is retried again.
The _add_node_filters call had to be refactored to avoid hitting
the complexity limit.
Change-Id: I34a11f52e8e98e5b64f2d21f7190468a9e4b030d
Story: #2005167
Task: #29901
This patch addresses some frequently failing tests with a few minor
changes related around how the exceptions are tested and how the
data is passed to the exceptions that are failing.
I've been able to duplicate the failing tests in CI while streaming
video on my desktop of all things. With these changes, I've been
unable to reproduce the failures.
This also fixes entries for DeployTemplate generation which were
noticed as well, however the failures were not observed in CI.
And a missing i18n tag was added into the pxe code, where it was
previously missing.
Change-Id: I719fa12340b51c55c0441df572ee7e3b33b1910c
The docstring contains parameter mode which is not
present. Move the param description to a comment
in code where mode is resolved.
Also fixes a typo in pxe_utils.py docstring.
Change-Id: Ic0a31612023a4985178dbb6e3078dff53f0aba0a
By default, Ironic makes persistent changes to the system boot order
at the end of an instance deployment. This may not be desired in
all cases, e.g. when DC policies require to leave the persistent
system boot order unchanged.
While keeping the persistent approach as the default, this patch
proposes to extent the existing 'force_persistent_boot_device'
field in the node's driver_info for (i)PXE in a way that allows
to have all boot device changes to be non-persistent.
Change-Id: If3a19f74fb0dfbcff2cde4cd5a8cc1edf5de3058
Story: #2004846
Task: #29058
Extend Ironic to enable use of Smart NICs to implement
generic networking services for baremetal servers.
Extending the ramdisk, direct, iscsi and ansible deployment Interfaces
to support the Smart NIC use-cases.
For Smart NIC use-case the baremetal node must be powered on and
booted into bios then wait for agent that runs on the Smart NIC to be
alive then do the network changes required.
Task: #26932
Story: #2003346
Change-Id: I00d6f13dd991074e4f45ada4d7cf4ccc0edbc7e1
After this cleanup, only one use of is_ipxe_enabled remains
which is in the storage interface. That will be removed in
a separate patchset that I have been working on.
Change-Id: I625ac56122ac4dd17d0c9e7dacc4444301a88e75
Story: 1628069
Adds logic to handle the appropriate replies for DHCPv6
responses.
The IPv6 nature was discovered while researching differences
and finding that the field ID value changes between IPv4 and
IPv6 DHCP clients, as DHCPv6 is purely booting from a URL.
Change-Id: I63572bea9bfb150aaeb4708dfa57e71adf4f64ab
Task: 9788
Story: 1744620
Story: 2003934
Create a base class to de-duplicate code across
the pxe and ipxe interfaces.
Only methods that do not have variation due to differences
in iPXE behavior.
Change-Id: I101f5ba7d44274d2b9d7d3a763198bc6fcc67e7a
Task: 26738
Story: 1628069
Moves the remaining private method test case code to pxe_utils
and updates tests to remove the temporary method remappings in
pxe.py.
Change-Id: Ic9ae2ef2802f1f17b213d5a196dde3b65981f0d6
Task: 23029
Story: 1628069
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
Moves common method calls out of the body of pxe.py into
pxe_utils, and accordingly removes some of the imports
and re-maps the methods for compatability, as unit tests
and methods have not yet been updated.
Tests and methods will be updated in the next patch.
Story: 1628069
Task: 26724
Change-Id: I717c49b99837b1785fc0080106414c6094dbf8eb
Provisioning fails if ironic node is configured with ``ramdisk``
deploy interface and PXE boot config file is not present for the
node.
Change-Id: Ic3a41b252751195a60e4757fee21cb2f62c3c7c2
Story: #2003532
Task: #24817
AgentDeploy already inherits from AgentDeployMixin and DeployInterface,
so there's no need to list them here.
Change-Id: Ia76e21330b012bdeb69a3d77b1544575d6d62513
* Breaks up and updates a few tests
* Switches some checks to be capability based
* Add decoratores to ramdisk deploy interface
* Switches ramdisk deploy interface to use deploy_steps.
Change-Id: Ief730a8bd9750a9ed6828506c3642f4dd7246c46
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 change collects boot-relalated functions into
the `boot_mode_utils.py` module to improve code clarity.
Change-Id: I1a2225d503deb382ba6021a6073c81cd03ca3175
Story: 1734131
Task: 10640
This commit will fix authentication in boot from volume (BFV) feature,
which use the volumes from Cinder for Baremetal via Ironic.
Each volume will need pair of account for authentication when perform
sanhook into SAN device via iPXE. And sandboot from drive 0x80 (default)
also need pair accounts same with the iscsi sanhook on drive 0x80 with
multi volumes has supported.
NOTE:
- We could add more than two volumes into iSCSI Boot Firmware Table(iBFT)
- Due to Linux does not support an iBFT that has more than two volumes,
thus BFV only support for add one etra volume. If over two volume in iBFT
then machine will raise "iBFT error: Control header is invalid!".
- Our code-base already for more than two volumes in iBFT, If Linux kernel
bugs[1] is fixing this issue then we can use BFV with more than two volumes.
Tested successfully on Fujitsu Baremetal Server TX2540 M1.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/acpi/actbl1.h#n1567
Co-authored-By: Hoang Trung Hieu <hieuht@vn.fujitsu.com>
Co-authored-By: Dao Cong Tien <tiendc@vn.fujitsu.com>
Change-Id: I98f658cced8491872d39adbd8e0a1a643dd24868
Story: #2001824
Task: #12573
Also fixes incorrect oneview tests that apparently used to be hidden by that.
Similarly, insufficient mocking in the PXE boot interface tests was fixed.
Now only test_manager uses mock_the_extension_manager.
Change-Id: Iaef9555337919706cd165adbbb2e1be9322f80b7
Also a few related errors based on some earlier investigation
may have been pulled in along the lines of E305.
Story: #2001985
Change-Id: Ifb2d3b481202fbd8cbb472e02de0f14f4d0809fd
``agent`` deploy interface do not call ``boot.prepare_instance``
if image being provisioned is whole disk image. This commit fixes
that issue.
It also updates ``validate`` method of neutron network interface
module to validate if it can support boot options requested for
instance image.
Change-Id: Ibd49d65f4512f2fa417794b66f4007d82f02e2ac
Story: 1713916
Task: 9259
Story: 1750958
Task: 9288
The kernel paramter 'initrd' is hard-coded as 'deploy_ramdisk' in iPXE
config template. A rescue ramdisk may fail to boot due to this wrong
paramter. This patch sets this 'initrd' paramter properly to
'deploy_ramdisk' or 'rescue_ramdisk' by adding a new pxe option.
Change-Id: I8ad1223dc289bbe915ee4ca8db66c8f80bf08f15
Closes-Bug: 1749860
This patch always builds PXE options for booting a user image even if
the provision state is related to rescue mode. When the state is
unrescuing, these options are necessary to boot a user image. When the
provision state is rescuing, these options are just ignored because
the PXE configuration is used at deployment mode.
Change-Id: I1ff51cab120e6612c71e5d9c45cf28797bc16e76
Closes-Bug: 1749433
Adds validate_rescue() method to boot interface to validate node's
boot properties related to rescue operation. This method is called
by the validate() method of rescue interface.
Closes-Bug: #1747467
Change-Id: Ib68d49a9cdb2ae4a5d43b90716c0a0c1166398c0
This removes the timing metric "validate_boot_option_for_trusted_boot"
because the validate_boot_parameters_for_trusted_boot() function is
an internal function that is called by PXEBoot.validate() -- which
is handled by the "PXEBoot.validate" metric. We shouldn't be emitting
metrics for such short-lived, internal functions.
Change-Id: Iaaa573fc4f128d6c3e20faf9c94259b352874eb8
Julia Kreger