Bug 1581756 - call to openstack overcloud containers image prepare returns almost empty list of containers
Summary: call to openstack overcloud containers image prepare returns almost empty lis...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-tripleo-heat-templates
Version: 14.0 (Rocky)
Hardware: Unspecified
OS: Unspecified
urgent
urgent
Target Milestone: Upstream M3
: 14.0 (Rocky)
Assignee: Steve Baker
QA Contact: Filip Hubík
URL:
Whiteboard:
: 1582149 (view as bug list)
Depends On: 1535971
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-05-23 14:55 UTC by Filip Hubík
Modified: 2018-10-11 16:18 UTC (History)
20 users (show)

Fixed In Version: python-tripleoclient-10.5.1-0.20180906012843.el7ost openstack-tripleo-heat-templates-9.0.0-0.20180919080945.0rc1.0rc1.el7ost
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1535971
Environment:
Last Closed: 2018-10-11 11:58:04 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Launchpad 1727347 0 None None None 2018-08-29 23:19:36 UTC
OpenStack gerrit 597726 0 None MERGED Handle sparse resource registry in build_service_filter 2020-04-13 16:10:58 UTC

Comment 4 Filip Hubík 2018-05-30 13:31:00 UTC 
*** Bug 1582149 has been marked as a duplicate of this bug. ***
Comment 5 Filip Hubík 2018-05-30 14:02:23 UTC 
In OSP14, I was able to workaround this successfully with passing arguments:

-e /usr/share/openstack-tripleo-heat-templates/environments/docker.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/docker-ha.yaml

to

$ openstack overcloud container image prepare ...
# but openstack overcloud deploy left intact without these included
(likely since https://bugzilla.redhat.com/show_bug.cgi?id=1579361 fix is inclulded in current deployments)

Infrared workaround: https://review.gerrithub.io/c/redhat-openstack/infrared/+/412461 is also proved working.

Will this be made part of THT or should we use workaround?
Comment 8 Steve Baker 2018-06-05 22:53:17 UTC 
The python-tripleoclient patch 0001-DOWNSTREAM-ONLY-Always-include-docker-environment-fi.patch needs to be reapplied, but that code has moved to tripleo-common. I might find a way of making this patch a bit more maintainable, so its mostly upstream with a downstream switch
Comment 9 Steve Baker 2018-06-06 00:25:54 UTC 
Actually I'm not sure this is a blocker. I would recommend the using the workaround in comment #5 until the workflow-container-prepare documentation is available.

Once workflow-container-prepare is available, "openstack overcloud container image prepare" won't be run at all, and the prepare code is always run in a context where docker.yaml and docker-ha.yaml are already in the environment, because the prepare happens during the actual deploy.
Comment 10 Steve Baker 2018-06-11 20:54:03 UTC 
It looks like Infrared has a workaround in place now. Can AutomationBlocker be removed?
Comment 14 Jaromir Coufal 2018-06-20 12:49:58 UTC 
Dropping the OSP14 blocker since we are not in blocker mode for this release, but let's make sure it lands in OSP14.
Comment 17 Steve Baker 2018-08-29 23:21:02 UTC 
I have a better upstream fix which should solve this class of problems.
Comment 21 Filip Hubík 2018-10-11 11:58:04 UTC 
I am not able to verify this bug.

Deploying old puddle 2018-05-16.2 with fixed packages results in tough dependency conflicts with no promise that such old deployment could even work and deploy OC if resolved.

On the contrary new OSP14 puddle 2018-10-08.4 might contain fixes, but it uses different deployment flow without "openstack overcloud container image prepare" during OC stage, it uses containerized UC where such step is replaced by "openstack tripleo container image prepare..." during UC stage and these extra yamls are not needed at all.
Note You need to log in before you can comment on or make changes to this bug.