Bug 1964179
Summary: | [RFE] Deploy whole disk images by default | ||
---|---|---|---|
Product: | Red Hat OpenStack | Reporter: | Steve Baker <sbaker> |
Component: | python-tripleoclient | Assignee: | Steve Baker <sbaker> |
Status: | CLOSED ERRATA | QA Contact: | David Rosenfeld <drosenfe> |
Severity: | high | Docs Contact: | |
Priority: | high | ||
Version: | 17.0 (Wallaby) | CC: | broose, hbrock, jparoly, jslagle, mariel, mburns, morazi, nlevinki, pweeks, racedoro, ramishra, spower, vaggarwa |
Target Milestone: | Alpha | Keywords: | FutureFeature, Triaged |
Target Release: | 17.0 | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | diskimage-builder-3.14.1-0.20211030102050.311621a.el8ost openstack-tripleo-image-elements-13.1.3-0.20211003011245.a04969b.el9ost openstack-tripleo-common-15.4.1-0.20211030010444.c404125.el9ost tripleo-ansible-3.3.1-0.20211005230418.d59d6f4.el9ost python-tripleoclient-16.4.1-0.20211016013626.c22f23a.el9ost | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2022-09-21 12:14:57 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | 1964175 | ||
Bug Blocks: | 1419948 |
Description
Steve Baker
2021-05-24 22:44:20 UTC
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 |