Upstream spec: https://review.opendev.org/c/openstack/tripleo-specs/+/788850/5/specs/xena/whole-disk-default.rst The capability to build and deploy a whole-disk overcloud image has been available for many releases, but it is time to switch to this as the default. Doing this will avoid the following issues and bring the following benefits: * As of RHEL-8.4, grub will stop support for installing the bootloader on a UEFI system. ironic-python-agent depends on grub installs to set up EFI boot with partition images, so UEFI boot will stop working when RHEL 8.4 is used. * Other than this new grub behaviour, keeping partition boot working in ironic-python-agent has been a development burden and involves code complexity which is avoided for whole-disk deployments. * TripleO users are increasingly wanting to deploy with UEFI Secure Boot enabled, this is only possible with whole-disk images that use the signed shim bootloader. * Partition images need to be distributed with kernel and ramdisk files, adding complexity to file management of deployed images compared to a single whole-disk image file. * The requirements for a hardened image includes having separate volumes for root, data etc. All TripleO users get the security benefit of hardened images when a whole-disk image is used. Wherever the partition image overcloud-full.qcow2 is built, published, or used needs to be updated to use overcloud-hardened-uefi-full.qcow2 by default. This RFE will be considered complete when it is possible to follow the default path in the documentation and the result is an overcloud deployed with whole-disk images.
A few areas we need to check with this: NFV deployments often use different layouts. Are there any concerns there? RealTime deployments use virt-customize to update the kernel and a couple other things in the images. Does that process need to change? Once this change is made, do we need overcloud-full at all anymore? Note: this is only targeted for OSP 17 at this point. 16.2 is based on RHEL 8.4. Is it also impacted? or have we worked around the issues?
(In reply to Mike Burns from comment #1) > A few areas we need to check with this: > > NFV deployments often use different layouts. Are there any concerns there? Building their own whole-disk images for specific needs is still supported and encouraged. But it would be useful to capture their requirements just in case their needs can be met by the published image with minor changes. > RealTime deployments use virt-customize to update the kernel and a couple > other things in the images. Does that process need to change? The process needs to be tested and updated, but I think the basic approach will still work. Also it would be good to capture their requirements, just in case the virt-customize can be replaced with a whole-disk image build yaml customize like [1] [1] https://opendev.org/openstack/tripleo-common/src/branch/master/image-yaml/overcloud-realtime-compute-python3.yaml > Once this change is made, do we need overcloud-full at all anymore? I don't think so, it would be least disruptive to publish both while all the automation is updated but then we could stop publishing overcloud-full. Alternately you could immediately stop publishing overcloud-full, and just fix everything to unblock the build pipeline, this can be worked out under bug #1964175 > Note: this is only targeted for OSP 17 at this point. 16.2 is based on > RHEL 8.4. Is it also impacted? or have we worked around the issues? I think you're referring to the grub2-install issue with RHEL 8.4, the fix is ready and being tracked in #1961784
There may be followup fixes required, but all the changes for this RFE are now in 17 builds.
*** Bug 1381111 has been marked as a duplicate of this bug. ***
Important: The UEFI portions require LVM, so, these images have an LVM layout instead of basic partitioning like the overcloud-full images.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Release of components for Red Hat OpenStack Platform 17.0 (Wallaby)), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2022:6543