Bug 1491796
| Summary: | [Openstack-containers][OSP12]: get rid of unnecessary RPMs installed on the overcloud images and are already installed within openstack containers. | ||
|---|---|---|---|
| Product: | Red Hat OpenStack | Reporter: | Omri Hochman <ohochman> |
| Component: | rhosp-director-images | Assignee: | Mike Burns <mburns> |
| Status: | CLOSED DUPLICATE | QA Contact: | Omri Hochman <ohochman> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 12.0 (Pike) | CC: | aschultz, jcoufal, m.andre, mbracho, mburns, rhallise, sasha |
| Target Milestone: | --- | Keywords: | FutureFeature, Triaged, ZStream |
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2018-07-13 18:24:06 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: | |||
|
Description
Omri Hochman
2017-09-14 17:27:34 UTC
This is wontfix for OSP 12. To fix this would require significant changes to the image build process that we can't take on in 12. We would have to either develop new image definitions or change all the image definitions upstream to remove the packages we're containerizing. Instead, we're going to handle this in 13 by not shipping or using the overcloud-full image. also that list is the undercloud, not the overcloud. Some of those packages can't be removed (neutron, for example) because their not containerized. (In reply to Mike Burns from comment #3) > also that list is the undercloud, not the overcloud. Some of those packages > can't be removed (neutron, for example) because their not containerized. Agree - It's problematic. but I think there is a little bit more to this than that. In case of leaving the RPMs on the overcloud, when doing upgrade we would need to start upgrade unnecessary osp11 RPMs to osp12, which will make the upgrade process time longer. In case we're excluding the update RPM from upgrade, we would be left with osp12 environment that has old osp11 RPMs. And if we are removing the RPMs before the osp11 upgrade begins - we need to match our clean-deployment tests since we would like the upgraded-environment and clean-deployment env to look the same. (which makes this bug relevant to osp12). The last point is, and I'm adding it as food for thought about this topic, If we decide to leave the dup RPMs on the overcloud nodes, we would probably need to keep having them available on the SAT/CDN and keep testing from there. (In reply to Omri Hochman from comment #4) > (In reply to Mike Burns from comment #3) > > also that list is the undercloud, not the overcloud. Some of those packages > > can't be removed (neutron, for example) because their not containerized. > > Agree - It's problematic. > but I think there is a little bit more to this than that. > > In case of leaving the RPMs on the overcloud, when doing upgrade we would > need to start upgrade unnecessary osp11 RPMs to osp12, which will make the > upgrade process time longer. yum update will take longer, yes, but we'd be talking about having a completely separate step during the upgrade that removes the redundant rpms. That's new time that would likely be just as long as the yum update. It's a one time cost, yes, but we don't have the code or logic for *what* to remove from the nodes. It's not "all OSP packages". It's not even "all OSP packages except neutron/cinder/manila and dependencies". There are other packages that are required like os-net-config, os-apply-config, etc... > > In case we're excluding the update RPM from upgrade, we would be left with > osp12 environment that has old osp11 RPMs. Yes, IIUC, this is already what is being done. We need to run yum upgrade on the base OS regardless of whether rpms are there or not. This is a requirement from the security team. > > And if we are removing the RPMs before the osp11 upgrade begins - we need to > match our clean-deployment tests since we would like the > upgraded-environment and clean-deployment env to look the same. (which > makes this bug relevant to osp12). Nit/Clarification: Removing pre-upgrade isn't an option --> it needs to be post upgrade after 12 is already running in containers. Otherwise, the cloud is down. It should probably be done as part of the upgrade process, maybe the converge step... A "clean" install and an upgraded install will mostly have the same packages installed as it stands today. All the rpms are included in overcloud-full image, so removing on upgrade would actually cause the images to diverge. It might be really interesting in 13 to see if we can do a rip/replace of the images so that we put a clean image down on each node that has no extra content. > > The last point is, and I'm adding it as food for thought about this topic, > > If we decide to leave the dup RPMs on the overcloud nodes, we would probably > need to keep having them available on the SAT/CDN and keep testing from > there. I'm not following this completely. We're doing a yum update during upgrade, so customers will move to the latest RPMs. We're still shipping RPMs even for the things that are containerized. It's basically a requirement that we keep shipping RPMs even if we were completely containerized and not supporting anything with just rpms. Note: moving needinfo to Maria. She is the PM for upgrades now. Something like this is probably partially captured with Bug 1484962 which is an rfe to stop doing openstack specific images. We did talk about this during the PTG for the containerized upgrade to be removing the software from the host when the conversion happened but I'm not sure the plan forward and it would unlikely be done during 12. On a related note, there is also bug 1470041 to remove RPMs for disabled services during upgrade. Note: openstack-selinux and all other selinux policies are loaded in to the host kernel. They should never be part of a container. *** This bug has been marked as a duplicate of bug 1566719 *** |