Description of problem: Updating the plan with a new tarball has no effect, the plan/swift container isn't updated with the new files. Version-Release number of selected component (if applicable): openstack-tripleo-ui-8.1.1-0.20180122135122.aef02d8.el7ost.noarch openstack-tripleo-common-8.3.1-0.20180123050218.el7ost.noarch How reproducible: 100% Steps to Reproduce: 1. In the UI, create a plan with the default templates 2. Locally, prepare a tarball with the same plan but two changes: edit the description in plan-environment.yaml and add a new file (e.g. random-new-file.yaml). 3. On the plans page in the UI, select "Edit" the plan create in step 1, and upload the tarball with the new files created in step 2 4. Plan updated successfully message shows up after a while Actual results: 5. If I click on edit, plan still has only 889 files and doesn't show my new file in the list 6. When I download the files from Swift, the new file isn't present and plan-environment.yaml doesn't contain my modification Expected results: 5. When I click on the plan 'Edit' files tab, I see 890 files 6. When I download the files from swift, I get my new and updated files Additional info: I tried with both 'selecting' the plan I wanted to update first, or leaving another default plan selected, but it didn't work in either case.
Appears to occur with both Firefox and Chrome.
After some team effort debugging, we discovered that the original tarballs used in this bug were faulty and that was the reason the plan update didn't work. When attempting a plan update with a correct tarball, it works fine. However, the issue of UI not displaying a failure message on failed plan update is still relevant. So this bug should be about fixing the UI so that it properly displays a failure message when a plan update fails.
After some more investigation, this is down to the Swift API not returning the correct status code. See bz 1560579 for more detail.
I wasn't able to make it fail. Verified: openstack-tripleo-ui-9.3.1-0.20180921180341.df30b55.el7ost.noarch
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-2019:0045