[OSP12] 'Prepare command' missing API causes UI users requirement to run manual steps to create the containers .yaml files. Environment: ------------- openstack-tripleo-heat-templates-7.0.0-0.20170821194254.el7ost.noarch openstack-tripleo-ui-7.2.1-0.20170819031831.070a522.el7ost.noarch instack-7.0.1-0.20170726180523.9961055.el7ost.noarch instack-undercloud-7.2.1-0.20170821194210.el7ost.noarch openstack-tripleo-common-containers-7.4.1-0.20170818153039.7d74e83.el7ost.noarch docker-common-1.12.6-48.git0fdc778.el7.x86_64 Description : ------------- UI users running deployment should not be required to exit UI and switch to CLI mode to manually run 'openstack prepare command' that creates container .YMAL files: Commands (from CLI): --------------------- (-) wget http://download-node-02.eng.bos.redhat.com/rcm-guest/puddles/OpenStack/12.0-RHEL-7/latest_containers/container_images.yaml sudo openstack overcloud container image upload --verbose --config-file /home/stack/container_images.yaml (-) TAG=`curl http://download-node-02.eng.bos.redhat.com/rcm-guest/puddles/OpenStack/12.0-RHEL-7/latest_containers/container_images.yaml|awk -F':' '/imagename/ {print $NF; exit}'` (-) openstack overcloud container image prepare --namespace=docker-registry.engineering.redhat.com/rhosp12 --env-file=/home/stack/rhos12.yaml --prefix=openstack- --suffix=-docker --tag=$TAG
All of the logic for "openstack overcloud container image prepare" and the other commands live in tripleo-common. This was done deliberately so that in the future the UI could use the same library code to perform these tasks. Other than library code in tripleo-common, what else does the UI need to be able to run it?
Yes, the image preparing utilities are there. But there is no Mistral API (actions/workflows) supporting those which are needed by GUI. There is recurring problem that CLI works around using mistral API and accesses those utilities (business logic) directly rather than through Mistral API. Because it tends to create/modify deployment files locally rather than operating on Deployment Plan through common Mistral API. This has following consequences: - same business logic is implemented twice - in tripleoclient and tripleo-common (Mistral actions) - GUI and CLI workflow diverges - GUI is behind CLI in feature parity as features are considered complete when they are supported by CLI (rather than supported by common API) - bugs such as this one occurs If CLI used tripleo-common Mistral API, it would become much more lightweight because all of its business logic would live in tripleo-common (which needs to be implemented there anyway - to support GUI). See nodes management in tripleoclient for example.
For more information please see this upstream thread: http://lists.openstack.org/pipermail/openstack-dev/2017-September/122089.html
*** Bug 1459683 has been marked as a duplicate of this bug. ***
The proposed upstream solution is to add an action to the plan_management workflow which does a container prepare and insert the containers yaml into the existing plan. For OSP 12 this action won't take any inputs to modify the containers yaml, so the UI will be limited to deploying containers by pulling directly from the product registry. For OSP 13 a dedicated workflow for image management will be developed, which will allow the UI and CLI to control all aspects of pre-deployment image management (plan yaml, local registry upload, tag discovery)
Moving it to UI:DFG QA to verify .
Hi Steve. So I understand that, if you deploy from the GUI, the docker registry that will be used is always going to be the one from the www and there will be no local registry on the undercloud? That actually sounds like a nice solution. I just have a few questions: 1) At what point will the registry configuration be uploaded to the plan? Is it during plan creation, or is it when the user clicks on "deploy", or something else? 2) To which file is the configuration uploaded? Is it to plan-environment.yaml? 3) Where is the configuration taken from? In other words - where will the registry be (it might depend on a user's subscription) and how is its URL set? Thanks!
(In reply to Udi from comment #9) > Hi Steve. > > So I understand that, if you deploy from the GUI, the docker registry that > will be used is always going to be the one from the www and there will be no > local registry on the undercloud? Correct > That actually sounds like a nice solution. I just have a few questions: > 1) At what point will the registry configuration be uploaded to the plan? Is > it during plan creation, or is it when the user clicks on "deploy", or > something else? It is during plan creation, so the GUI user can see an edit the files which are created. > 2) To which file is the configuration uploaded? Is it to > plan-environment.yaml? Into a newly created file called environments/containers-default-parameters.yaml > 3) Where is the configuration taken from? In other words - where will the > registry be (it might depend on a user's subscription) and how is its URL > set? By running the prepare command with no arguments, so downstream patches to tripleo-common/container-images/overcloud_containers.yaml.j2 are needed to ensure that the correct registry/images/tag are used.
Since the overcloud_containers.yaml.j2 is processed during plan creation, to use the workaround Steve proposed, it is necessary to re-create the plan after changing that file. As part of the workflow run during plan creation, overcloud_containers.yaml.j2 is processed and it's output is used to generate environments/containers-default-parameters.yaml environment which is then automatically used for deployment. That's why updating overcloud_containers.yaml.j2 and re-processing it is not enough.
I can confirm that workarounds described above work. Udi, it is not necessary to directly update containers-default-parameters.yaml if you update or recreate the plan using GUI. That action will regenerate the environment file. My deployment currently failed with http://paste.openstack.org/show/627250/ I am not sure if it is related to other bug or a misconfiguration on my side. I'll try to investigate further.
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-2017:3457