| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The troubleshooting kernel command line option nomodeset
unfortunately changes the way framebuffer interactions work
with graphics devices which in some cases can result in kernel
memory to be used for graphics updates. When this happens on
some specific hardware common in rack mount servers with baseboard
management controllers, this can cause the memory bus to become
locked for a brief time while the graphics update is occuring.
This locked memory bus means disk IO can become blocked,
and network cards can overflow their buffers resulting in
packet loss on top of the latency incurred by the graphics
update executing.
As such, we've removed the nomodeset option from default usage and
added a note describing its removal to the documentation along
with a release note.
Change-Id: I9084d88c3ec6f13bd64b8707892758fa87dd7f86
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
| |
Two calls to fileutils.ensure_tree were missing the follow-up chmod
for CONF.pxe.dir_permission. This is fixed with a local ensure_tree
function which creates the directory with the appropriate mode.
The configuration help for the permissions attributes clarify that the
system default umask is masked out on the supplied value.
Change-Id: I124d2ba09b0fc78b284c1ae871ca5a16fc44b8c9
|
| |
|
|
|
|
|
|
|
|
|
| |
Currently the default boot.ipxe is not suitable for ironic-inspector
in a standalone configuration. This change adds a new option
[pxe]ipxe_fallback_script that makes boot.ipxe fall back to the provided
script.
Story: #2009294
Task: #43982
Change-Id: Id5547885e75beafb4423e9e2056c79c54b286275
|
| |
|
|
|
|
|
| |
Adds capability to copy bootloader assets from the system OS
into the network boot folders on conductor startup.
Change-Id: Ica8f9472d0a2409cf78832166c57f2bb96677833
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The parameter has not had any effect in the code since
the dual stack PXE work went into place with Ironic as options
are now generated and transmitted to Neutron for both IPv4 and
IPv6. This option is only used by the internal
``dhcp_options_for_instance`` method in
``ironic.common.pxe_utils`` as a fallback if the calling method
does not specify a version. However a later change resulted in the
default behavior calling the dhcp option generation explicitly
to generate both IPv4 and IPv6 parameters, making the option
entirely redundant.
Third party drivers using the ``dhcp_options_for_instance`` method
should consider generating options for both IPv4 and IPv6 at all
times. See change
If7a296001e204ae0c9a49495731052ab33379628 for examples on how
to do this.
Change-Id: I343783389105f008ce6dafc8d25d93211710771a
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The bootloader default for ipxe, previously set to ipxe.efi
was, while consistent with the interface naming, a likely
setting that had to be overridden by most deployments,
as very little hardware can make use of ipxe.efi for network
booting, where as snponly.efi is realistically what should
be used in nearly all cases with the exception of some
extremely early UEFI supporting hardware, which may
happen to work with ipxe.efi *if* support for the network
card happens to be compiled in.
Note: This was likely never observable in CI as CI leverages
firmware with integrated iPXE binaries.
Change-Id: I808cf92c98339aa447b4799900066c310e15fd5b
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently handling of kernel_append_params is very inconsistent. This
change applies a straightforward process:
1. instance_info[kernel_append_params]
2. driver_info[kernel_append_params]
3. [pxe]kernel_append_params (renamed from pxe_append_params).
Also adds a helper for subsequent fixes in other drivers.
Change-Id: I79bcf4d8ef1f0f55a82e0991dd5bb1685b3f7957
Story: #2008902
Task: #42469
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I did something stupid when started driving forth the split of ipxe
from the pxe interface: I didn't think about the need to actually
separate bootloaders. In part, because the use case was a mixed
Power8/Power9 and x86 cluster. Mainly because the Power hardware
does not honor or care about the bootfile name provided over DHCP.
The firmware knows how to read the PXELINUX boot file format
and the machines are able to boot from there.
Where this all goes sideways is when:
* Enabled boot interfaces are set to ipxe,pxe
* No default boot interface is set
* Node is created without a default for x86 hardware.
* Node uses ipxe boot_interface, and creates files under /httpboot
* bootfile transmitted via DHCP is pxelinux.0.
Fun right?
The simple workaround for the power user is to just define the iPXE
loader, or maybe use UEFI. But that is neither here nor there, this
is still a bug and a possible use case is GRUB2 via PXE and iPXE.
Not that would really work via ipxe, but hopefully people get the
idea.
The solution kind of seems clear, duplicate configuration and
fallback if not defined.
Story: #2007003
Task: #40282
Change-Id: I4419254c23095929e52a0fda11789f2f5167dc6b
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Adds an ability to generate network boot templates even for nodes that
use local boot via the new ``[pxe]enable_netboot_fallback`` option.
This is required to work around the situation when switching boot devices
does not work reliably.
Depends-On: https://review.opendev.org/#/c/736191/
Change-Id: Id80f2d88f9c92ff102340309a526a9b3992c6038
Story: #2007610
Task: #39600
|
| |
|
|
|
|
|
|
| |
I have only checked the main configuration options and two generic
drivers, leaving everything else untouched. Added are options
that is possible and makes sense to reload.
Change-Id: I74c629bcaf50da7f829f0ec8c526d936b9d40b36
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We document that this can be disabled by setting the
[pxe]tftp_master_path config to "<None>", but don't
actually support it in code. oslo.config doesn't actually
translate that value to the Python None as we expect.
Allow disabling the cache by setting the config to the empty
string, as in "tftp_master_path=". This doesn't make sense as
a directory to use as a cache anyway, so it shouldn't break anyone.
Change-Id: Icc7d08ae47e0e450a612c922ae3d665c56880262
Story: 2004608
Task: 28506
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We document that this can be disabled by setting the
instance_master_path config to "<None>",
but don't actually support it in code. oslo.config doesn't actually
translate that value to the Python None as we expect.
Allow disabling the cache by setting the config to the empty string, as
in "instance_master_path=". This doesn't make sense as a directory to
use as a cache anyway, so it shouldn't break anyone.
Change-Id: I1bb62d55e3e18272fd5da355d63fd2c11a033acd
Story: 2004279
Task: 27829
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
Change-Id: I21d8d9b53feab2f101bbd7910fc64750ca5f5990
|
| |
|
|
|
|
|
|
|
|
|
| |
Some operators may wish to utilize different default folders
for their bootloaders to search for refernces to the asociated
configuration file.
This patch adds an option to the configuration file that allows
operators to change the default.
Change-Id: I9b8f97868aea74c1b1b458fe8f16ada1ff4ea579
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
oslo.config 5.2.0 changed some of the options
(oslo_config.cfg.StrOpt & PortOpt) so that
the choices parameter will now accept a sequence
of tuples, where each tuple is of the form
(choice, description).
If a description is not provided, the sample
config file is generated with
'<No description provided>' next to the choices.
This adds descriptions to the choices.
Change-Id: I7e32ff8e86d2760af49fd088188b94d19ca76e84
Closes-Bug: #1755914
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This implements agent based rescue interface.
Partial-Bug: #1526449
Co-Authored-By: Mario Villaplana <mario.villaplana@gmail.com>
Co-Authored-By: Aparna <aparnavtce@gmail.com>
Co-Authored-By: Shivanand Tendulker <stendulker@gmail.com>
Change-Id: I9b4c1278dc5fab7888fbfe586c15e31ed3958978
|
| |
|
|
|
|
|
|
|
|
|
| |
In commit[1], we allowed to specify permission to be applied to
TFTP directories using ``[pxe]/dir_permission``. This configuration
is an integer value. This patch adds a note stating that this value
should be an octal number.
[1] 0f7a85e1ecd7b3e7bdbc297f47a498139ed40107
Change-Id: Iba8d88bd6faba600d6b66d27f1700dae8dd29eee
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently method "_ensure_config_dirs_exist" creates tftpboot/<uuid>
dir with wrong permission. This is due to the system umask setting
which overrides the default permission of 0777 to 0755 or 0750. When
the permission is 0750, BM can't get deploy_kernel and ramdisk from
tftpserver. This may happen only when tftp process is launched from
other user than root and as result can't read files created by Ironic.
So this patch tries to fix the issue by explicitly changing the
permissions defined in the config option ``[pxe]/dir_permission``.
Change-Id: I3119ec7ae31bf82f716bf082fa4c3296d6aa3587
Closes-bug: #1655568
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Ironic is flexible for x86/x86_64 servers by supporting BIOS and UEFI.
But to deploy servers of other architectures, such as aarch64 or ppc64,
configuration(PXE boot file and config template) must be modified,
which means one Ironic conductor can only deploy baremetal machines of
one architecture.
This patch adds multi arch deployment support. For example, to deploy
x86_64 and aarch64 servers by one Ironic conductor.
Closes-Bug: #1582964
Change-Id: I628320aeb44b232a262d0843bc726a68d297e1f8
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This patch is changing the default bootloader for PXE + UEFI to Grub2.
Prior to this patch Elilo was the default but, Elilo is no longer
maintained with the last release dating 2014.
Ironic should have sane defaults therefore we should not rely on an
unmaintained project.
Change-Id: Ib34fcbd37e4698bf272582c96b1540b511b5a892
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
when iPXE is enabled, it is possible for the bootloader to download
the deploy kernel and ramdisk directly from Swift TempURL instead of
downloading them to conductor and serving from local HTTP server.
This patch adds the required logic and a new config option
`ipxe_use_swift` (default False), setting which to True enables
using Swift TempURLs for deploy ramdisk and kernel.
Note that local caching and serving for kernel and ramdisk of user image
is still performed for partition images that require non-local boot,
as moving those to use TempURLs will make it impossible for the user
to reboot the instance when TempURLs time out or image is deleted from
Glance/Swift.
Change-Id: I106cc6148c329e784bfbb5019fdfeb0509a9de09
Closes-Bug: #1526404
Co-Authored-By: Andrey Shestakov <ashestakov@mirantis.com>
|
|
|
Nova style refactor of config options in Ironic.
Change-Id: I99f954dcc0097fd62b8c6b538bd1577a09e71a35
Partial-Bug: #1561100
|
