Bug 1730638

Summary: openstack overcloud update run --nodes Controller fails with: The Stack (overcloud) could not be found
Product: Red Hat OpenStack Reporter: Nadav Halevy <nhalevy>
Component: openstack-mistralAssignee: Jose Luis Franco <jfrancoa>
Status: CLOSED NOTABUG QA Contact: nlevinki <nlevinki>
Severity: medium Docs Contact:
Priority: medium    
Version: 13.0 (Queens)CC: aschultz, beth.white, dmatthew, jfrancoa, jjoyce, jschluet, nhalevy, slinaber, tvignaud, vvoronko
Target Milestone: ---Keywords: Triaged, ZStream
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Keeping Red Hat Openstack Platform Updated 13
Last Closed: 2019-08-07 12:57:54 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Comment 5 Jose Luis Franco 2019-08-05 13:31:08 UTC
Hello Nadav,

I've been checking the logs and it seems there's a problem with the overcloud stack not being found already in the executor.log-20190716.gz, which are previous to the minor update. Could you please send the command used to deploying (overcloud deploy) as well as for running the overcloud update prepare? Did you use a custom stack name? It's the only logical reason I can find to not being able to locate the stack..that or some issue with the stack upon deployment.

Comment 6 Jose Luis Franco 2019-08-05 13:49:32 UTC
If you could locate the Jenkins job results from the job you used for deploying (I guess you used Customized-Deployment) would be helpful. Plus the full overcloud update prepare command. From the logs this looks to me as an incorrect usage of the updates workflow.

Comment 7 Nadav Halevy 2019-08-07 11:35:45 UTC
Hi Jose,

I believe that this was the Jenkins job I used: https://rhos-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/OSPD-Customized-Deployment-virt/11038/

The update prepare / update run commands I used are identical to what I wrote in the bug description.

Comment 8 Jose Luis Franco 2019-08-07 12:57:54 UTC
Hello Nadav,

Thanks for the answer. We can know now where the problem is. As stated in the documentation, when running the overcloud update prepare, you need to pass the very same templates which were passed during overcloud deploy. Therefore, the syntax for the "overcloud update prepare" should be like this:


openstack overcloud update prepare \
--timeout 100 \
--templates /usr/share/openstack-tripleo-heat-templates \
--stack overcloud \
--libvirt-type kvm \
--ntp-server clock1.rdu2.redhat.com \
-e /home/stack/virt/internal.yaml \
-e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
-e /home/stack/virt/network/network-environment.yaml \
-e /home/stack/virt/hostnames.yml \
-e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml \
-e /home/stack/virt/nodes_data.yaml \
-e /home/stack/virt/extra_templates.yaml \
-e /home/stack/virt/docker-images.yaml 

which defers quite a lot from what it was executed.

An easy trick, if you use infrared, is to locate the overcloud_deploy.sh script inside /home/stack directory from the undercloud, copy it into overcloud_update_prepare.sh and change the command from "openstack overcloud deploy" into "openstack overcloud update prepare". Pay attention to any other environment files you might need to include, as the new container images env file.

Please, try executing the procedure with the right update prepare parameters, and if you find this issue again feel free to re-open the bug. For the time being I'll close it as not a bug.