Hide Forgot
python-openstackclient: We're forced to run 'openstack overcloud container image prepare" twice with different namespace for generating --env-file and --images-file. Environment: instack-undercloud-7.1.1-0.20170714211622.el7ost.noarch openstack-puppet-modules-10.0.0-0.20170315222135.0333c73.el7.1.noarch openstack-tripleo-heat-templates-7.0.0-0.20170721174554.el7ost.noarch python-openstackclient-3.11.0-0.20170613232431.c69304e.el7ost.noarch To create an env-file we run: openstack overcloud container image prepare --namespace=<FQDN:PORT/namespace> --env-file <filename> ...<args> To create --images-file we run: openstack overcloud container image prepare --namespace <namespace> --images-file <filename> --pull-source <FQDN:PORT> 1) Providing a different namespace is confusing. 2) Can we make it possible generating both files in a single run.
To be clear, I think that when deploying from a local registry I think it is correct to run prepare twice, because you're preparing for two different tasks against two different registries. However I do want to fix the consistency issue of --namespace=<FQDN:PORT/namespace> vs --namespace <namespace> I've raised a bug upstream so that --pull-source is deprecated and --namespace=<FQDN:PORT/namespace> is used consistently.
In Queens the following commands will be replaced with a single command backed by a mistral workflow. This workflow will also be invoked from the UI: overcloud container image prepare overcloud container image tag discover overcloud container image upload
This is now ready for testing. If the local undercloud is being used, only a single prepare call is needed. Only the first prepare call is required, which needs to: - specify both output files --output-images-file and --output-env-file - specify a --push-destination argument with the <undercloud ip>:8787 This will result in an --output-env-file with appropriate undercloud registry image references
Verified OSP13 RC - prepare command need to be executed only once.
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, 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-2018:2086