Bug 1853417
| Summary: | container image prepare assumes default tag of 16.0 always exists even when it doesn't in a filtered content view | ||
|---|---|---|---|
| Product: | Red Hat OpenStack | Reporter: | James Slagle <jslagle> |
| Component: | openstack-tripleo-common | Assignee: | James Slagle <jslagle> |
| Status: | CLOSED ERRATA | QA Contact: | David Rosenfeld <drosenfe> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 16.0 (Train) | CC: | aschultz, broose, bshephar, dvd, emacchi, jhajyahy, kecarter, marjones, mburns, slinaber |
| Target Milestone: | z2 | Keywords: | Triaged |
| Target Release: | 16.1 (Train on RHEL 8.2) | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | openstack-tripleo-common-11.4.1-0.20200727073831.96886e8.el8ost | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-10-28 15:38:12 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: | 1853419 | ||
|
Comment 1
Brendan Shephard
2020-07-23 23:55:47 UTC
I think I might have misunderstood the intention of default_tag there. So I unset it in my container-images-prepare.yaml, and let it default to true as set in container-images/container_image_prepare_defaults.yaml by that patch. Gave it another shot and still getting the same thing unfortunately. I probably jumped the gun a bit here anyway since it's still ON_DEV. (In reply to Brendan Shephard from comment #2) > I think I might have misunderstood the intention of default_tag there. So I > unset it in my container-images-prepare.yaml, and let it default to true as > set in container-images/container_image_prepare_defaults.yaml by that patch. > > Gave it another shot and still getting the same thing unfortunately. I > probably jumped the gun a bit here anyway since it's still ON_DEV. as you realized, default_tag is not something that you explicitly set in the values for ContainerImagePrepare. When you apply the patch, it should cause the latest tag available in the CV to be used, as long as you have not also specified an explicit "tag" key in ContainerImagePrepare. You may still run into issues if the CV were to say have a filter for 16.0, which points to a version that is also not available in the CV. That's just how satellite works based on my understanding. I can help you verify that the patch does the right thing, but would need to know a few things: How was it applied? How are you running openstack tripleo container image prepare? Need to see the command, and all environment files. How is the CV setup in satellite, what are the filters? And what is the CV container repo url? one thing to note is that if the container image prepare process is just running as part of the normal openstack overcloud deploy, then you will need to make sure the patch is applied to tripleo-common in the mistral_executor container, since mistral is executing ansible in a container with it's own filesystem and tripleo-common (not the same as what is on the host). based on the line numbers in the traceback, I'm not sure the patch is actually being used. Hey man, If you're happy that it works, then I'm happy. I initially tried patching the various files from your patch here: https://review.opendev.org/changes/741622/revisions/589ac8ac0d5a14ce4aa831892d3b0a4a31e29674/patch?zip But for whatever reason I didn't have the required $ patch foo to use the patch command. I ended up just copying the raw files from your change into their various directories. Then to test it, I was just using: sudo openstack tripleo container image prepare -e ~/containers-prepare-parameter.yaml --debug From the Satellite site, I was able to use podman to pull the container from the Content View. So I'm fairly confident that should have been working. The path is: name_prefix: osp-apac-library-osp16-cv-osp16_containers Where osp-apac is the org, I didn't have any environments setup (Production, Development, etc), so Library is the environment, osp16-cv is the Content View and osp16_containers is the product. I didn't restart any of the services or modify any of the containers after I added in your changed scripts, but I did try adding random print statements in to make sure I was using the right image_uploader.py file. And in the ContainerImagePrepare, I removed the tag: 16.0, and left tag_from_label: although, I did have that default_tag: argument which I realized I wasn't able to set there. But I guess it shouldn't have made a difference in that case? Regardless, as I said, if you're happy with it. Then I'm confident that it is fine and was just something I missed while I was testing it. Testplan: Setup a satellite server with a Content View with container repositories. Add a tag filter on the Content View so that only certain tags are included. You can try with different tag filters, e.g., the latest, not the latest, the latest symlinked version (16.1). Setup your ContainerImagePrepare parameter per the director docs, https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.1/html-single/director_installation_and_usage/index#preparing-a-satellite-server-for-container-images Do *not* specify an explicit tag that you used for the Content View, or the default tag for the container images in ContainerImagePrepare. With this fix, that should now be discovered automatically during the container image prepare step. To try a negative test, you could specify an explicit tag in ContainerImagePrepare that you know does not exist in the Content View filter, but perhaps does exist in the upstream repo. It should be filtered out in the Content View, and then container image prepare should fail with a 404 or not found. I have tested this behavior on Satellite 6.7 with curl. curl the fully sync'd product repository for openstack-aodh-api from the satellite: (undercloud) [cloud-user@osp16 ~]$ curl -L https://tripleo-03.tripleo.lab.eng.bos.redhat.com:5000/v2/org1-openstack_16-rhosp-rhel8_openstack-aodh-api/tags/list | jq . % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 429 100 429 0 0 4125 0 --:--:-- --:--:-- --:--:-- 4125 100 205 100 205 0 0 1045 0 --:--:-- --:--:-- --:--:-- 3253 { "name": "org1-openstack_16-rhosp-rhel8_openstack-aodh-api", "tags": [ "16.0-97", "16.0-93", "16.0-95", "16.1-50-source", "16.1", "16.0", "16.0-105", "16.0-104", "16.1-50", "16.0-82", "16.1-45", "16.0-79" ] } Notice that all tags are returned. Now, curl the content view repository where I've added an include filter on only the 16.0-93 tag. THe environment is called "library", and the content view is called "osp16": (undercloud) [cloud-user@osp16 ~]$ curl -L https://tripleo-03.tripleo.lab.eng.bos.redhat.com:5000/v2/org1-library-osp16-openstack_16-rhosp-rhel8_openstack-aodh-api/tags/list | jq . % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 461 100 461 0 0 4564 0 --:--:-- --:--:-- --:--:-- 4564 100 95 100 95 0 0 482 0 --:--:-- --:--:-- --:--:-- 482 { "name": "org1-library-osp16-openstack_16-rhosp-rhel8_openstack-aodh-api", "tags": [ "16.0-93" ] } Only the 16.0-93 tag is returned as expected. With the patch from this bz, tripleo-common should now discover that only the 16.0-93 tag exists in the repository and use that, as long as you didn't explicitly ask for a different version. Run satellite deployment without tag parameter and default_tag set to false in container image prepare yaml Mistake on verification also compose not ready yet Deployed undercloud and overcloud using satellite filtered content view 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 (Red Hat OpenStack Platform 16.1 bug fix and enhancement 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-2020:4284 |