Bug 1381508
| Summary: | [RFE] Tripleo needs to support whole disk overcloud images | ||
|---|---|---|---|
| Product: | Red Hat OpenStack | Reporter: | Yolanda Robla <yroblamo> |
| Component: | openstack-tripleo-common | Assignee: | Yolanda Robla <yroblamo> |
| Status: | CLOSED ERRATA | QA Contact: | mlammon |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 11.0 (Ocata) | CC: | akarlsso, arkady_kanevsky, brault, cdevine, christopher_dearborn, dbecker, dcain, dtantsur, fduthill, fzdarsky, hbrock, jjoyce, jjung, John_walsh, jslagle, kurt_hey, mburns, mcornea, mlammon, morazi, nlevinki, racedoro, rajini.karthik, randy_perryman, rhel-osp-director-maint, sasha, sclewis, slinaber, smerrow, sreichar, tvignaud, yroblamo |
| Target Milestone: | Upstream M1 | Keywords: | FutureFeature, Triaged |
| Target Release: | 12.0 (Pike) | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| URL: | https://blueprints.launchpad.net/tripleo/+spec/build-whole-disk-images | ||
| Whiteboard: | upstream_milestone_pike-2 upstream_definition_approved upstream_status_not-started | ||
| Fixed In Version: | openstack-tripleo-common-7.3.1-0.20170720003002.f0ef9ac.el7ost | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-12-13 20:46:56 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: | |||
| Bug Blocks: | 1355903, 1389435, 1396159, 1434350, 1438574, 1442136, 1476985 | ||
|
Description
Yolanda Robla
2016-10-04 10:50:39 UTC
Changes to suport it landed on tripleo-client. It needs a new release to start using it. I'm leaving you assigned, as I know you've been working on it so far. Thanks! Also, if the patch you've landed was the last patch in this RFE, please feel free to move it to POST. Is it done now? Could you please update the status accordingly? It needs changes from diskimage-builder that have not landed yet. But at the moment we worked on alternatives, using guestfs, to get the overcloud-full image that is flat partition, and convert to whole disk: http://teknoarticles.blogspot.com.es/2016/12/start-using-whole-disk-images-with.html http://teknoarticles.blogspot.com.es/2016/12/how-to-encrypt-your-home-with-guestfs.html There is a pending article i need to write, about how to expand the filesystem after deployment, to consume the remaining disk space. Hi Yolanda, moving to ON_DEV as you're actively working on this. Whole disk support is already implemented in Ironic and I believe the TripleO client has already merged the code to support uploading images with "--whole-disk" into director's Glance. In any case this will only be possible to be used with custom Overcloud images as the stock images will be flat partition images, right? Yes, at the moment it can only be used witih custom overcloud images. There is no way from TripleO to generate it. Looks like more work has to be done here around building images, so I'm deferring this RFE to Pike. Also resetting the component to a more generic one. Related blueprint: https://blueprints.launchpad.net/tripleo/+spec/build-whole-disk-images Hi Yolanda, is all the code completed? This BZ can be set to POST if it is, as per https://bugs.launchpad.net/tripleo/+bug/1630203 I believe there isn't anything else pending, right? Code finally landed. But I'm working on CI jobs to produce the images. I also believe that some job needs to be done on tripleo, to produce the hardened image from the yaml file. This feature needs to land for OSP12 as Tech Preview, to get initial feedback from customers. On OSP13 the intention is to land it on production. We will also need it backported to OSP10. Alternatively we can patch overcloud image of OSP10 for JS (version TBD) as part of deployment tools, but still need support. Support for whole disk images is available in OSP10, see https://bugzilla.redhat.com/show_bug.cgi?id=1434350 . And about using a whole disk image in OSP10, you can take this as a reference: https://bugzilla.redhat.com/show_bug.cgi?id=1417231 So mlammon, for testing it, the image has not been packaged yet and it can take time, tied to https://bugzilla.redhat.com/show_bug.cgi?id=1459602 You can build the image manually and test it. You need to follow instructions on: https://docs.openstack.org/developer/tripleo-docs/basic_deployment/basic_deployment_cli.html And the command to build the image is: openstack overcloud image build --config-file /usr/share/tripleo-common/image-yaml/overcloud-hardened-images.yaml --config-file /usr/share/tripleo-common/image-yaml/overcloud-hardened-images-centos7.yaml --image-name overcloud-hardened-full Thanks Yolanda. Is it expected that built image will have multiple partitions? And, does it support LVM? Or do you want to have verified that the resulting image is a whole-disk overcloud image but without custom partitioning and LVM? Hi Ramon. So the image will have multiple partitions, but not LVM. Users could specify their own partitions exporting DIB_BLOCK_DEVICE_CONFIG var before building their own image (I need to create a blogpost + raise a documentation bug for it). Sorry, last comment was for the OSP12 version. For this 10/11 version, the image is generated with the script. And yes, the final image has LVM support. That blogpost will help on testing http://teknoarticles.blogspot.com.es/2017/07/build-and-use-security-hardened-images.html When users build the image as specified in comment #20 they'll need to specify their CDN or Satellite credentials. d-i-b has an element so I think this should be possible: https://docs.openstack.org/diskimage-builder/latest/elements/rhel-common/README.html Also with RHEL we have to have a base image: https://docs.openstack.org/diskimage-builder/latest/elements/rhel7/README.html Then, you can also add local repos, although I don't know if that will be necessary as when you use an activation key, it's usually associated to repositories so you could create an activation key for the OSP repos and use that. This is how to pass local repos: https://docs.openstack.org/diskimage-builder/latest/elements/yum/README.html Is there any other option for end users that will have subscriptions to achieve this? How does d-i-b know where the pike repos are? Mike showed that in his tests the build process failed to fetch the repo info with an error like this: -------------- Setting up Package Sacks http://download.lab.bos.redhat.com/rcm-guest/puddles/OpenStack/12.0-RHEL-7/2017-07-13.2/RH7-RHOS-DEVTOOLS-12.0/x86_64/os/repodata/repomd.xml: [Errno 14] HTTP Error 404 - Not Found Trying other mirror. To address this issue please refer to the below knowledge base article -------------- https://access.redhat.com/articles/1320623 So depending on CentOS/RHEL, several env vars need to be set. It's partially documented on http://tripleo-docs.readthedocs.io/en/latest/basic_deployment/basic_deployment_cli.html Additionally, we need to export DIB_YUM_REPO_CONF var, with the list of repos needed. I'll add this to my blogpost, to make it more complete, and also prepare it to be the base for future documentation. This can now be marked verified and tested. Whole Disk Image was tested and deployed into the overcloud containing the requirements of separate partition with the security hardened image created and deployed on many nodes. openstack overcloud image build --image-name overcloud-hardened-full --config-file /usr/share/openstack-tripleo-common/image-yaml/overcloud-hardened-images.yaml --config-file /usr/share/openstack-tripleo-common/image-yaml/overcloud-hardened-images-rhel7.yaml --verbose cd mv ~/images/overcloud-full.qcow2 ~/images/overcloud-full-old.qcow2 cp ~/images/overcloud-hardened-full.qcow2 overcloud-full.qcow2 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, 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-2017:3462 |