Bug 1805117

I guess this is a documentation deficiency. In the case that the overcloud will not have connectivity to the source registries, undercloud does and masquerading is not used. You would have to perform the container image prepare prior to doing the deploy.  The process would look like:


1) have ContainerImageRegistryLogin: True and push_destination: true in the container-image-prepare.yaml
2) run `openstack tripleo container image prepare -e container-image-prepare.yaml`
3) Update the container-image-prepare.yaml and remove the ContainerImageRegistryLogin: true
4) run the deploy with the new version of container-image-prepare.yaml

So if you've previously defined ContainerImageRegistryLogin: true and deployed, you need to set it to false to turn it off when you rerun the deploy. I'm running a deployment myself and it seems like you don't actually need to do ContainerImageRegistryLogin: true at all if you do the following >

1) openstack container image prepare defaults > container-image-prepare.yaml
2) add ContainerImageRegistryCredentials to container-image-prepare.yaml
3) Add container-image-prepare.yaml (with fully qualified path) to undercloud.conf
4) Install undercloud
5) Do various overcloud deployment preparations (overcloud images into glance, node imports, etc)
6) Do an overcloud deploy including -e container-image-prepare.yaml


The only time you need to ContainerImageRegistryLogin for the overcloud is if you using a source that requires authentication (registry.redhat.io / satellite server)

I'm able to reproduce the original error if I set ContainerImageRegistryLogin: true when the overcloud nodes do not have internet connectivity.  However, once updating it to be ContainerImageRegistryLogin: false and rerunning, the deployment works as expected.  I think this specific use case needs to be better documented.