Description of problem: The command openstack overcloud deploy generates passwords when it is first executed and stores them in file. If the user then changes to another directory and re-runs the deploy, it will perform a stack update but generate the passwords again. Steps to Reproduce: 1. openstack overcloud deploy 2. cd /tmp (or anywhere other than the CWD) 3. openstack overcloud deploy Actual results: Passwords are re-generated and sent to Heat again, which attempts to reconfigure the passwords on all services. Expected results: Passwords should never be generated on a stack update, the command should complain loudly that the password file can't be found. Related: https://bugzilla.redhat.com/show_bug.cgi?id=1303246
When you say "complain loudly" are you asking for it to stop & not do the update, or should it prompt the user for permission to continue?
(In reply to Ryan Brown from comment #2) > When you say "complain loudly" are you asking for it to stop & not do the > update, or should it prompt the user for permission to continue? I think it should probably stop and not do the update. If anyone has a compelling reason we could add a flag to continue anyway.
This bug did not make the OSP 8.0 release. It is being deferred to OSP 10.
I believe this has been merged as of 8 months ago https://review.openstack.org/#/c/275661/
The passwords file is no longer being generate; the passwords are stored in Mistral now. We should still make sure that the passwords are not being re-generated and overwritten on stack updates.
Works in python-tripleoclient-5.3.0-7.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://rhn.redhat.com/errata/RHEA-2016-2948.html