*** Bug 1582149 has been marked as a duplicate of this bug. ***
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
$ 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?
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
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.
It looks like Infrared has a workaround in place now. Can AutomationBlocker be removed?
Dropping the OSP14 blocker since we are not in blocker mode for this release, but let's make sure it lands in OSP14.
I have a better upstream fix which should solve this class of problems.
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.