What problem/issue/behavior are you having trouble with? What do you expect to see? When deploying the Overcloud, passwords for OpenStack services like Neutron or Cinder are generated to be some random value. However, once the Overcloud is deployed there's not established procedure for changing any of these passwords. A typical use case for this: let's say the password for either the Overcloud "admin" user, or "neutron" or "glance" is compromised. The typical counteraction consists of generating a new, secure password, and reconfiguring the compromised user to use the new password. As far as we can see from the documentation, this procedure is not documented. Where are you experiencing the behavior? What environment? In the ovecloud OSP7 clusters. When does the behavior occur? Frequently? Repeatedly? At certain times? Hasn't happened yet, but the probability of this happening in the future is non-zero.
This bug did not make the OSP 8.0 release. It is being deferred to OSP 10.
Is this possible in Tripleo? To regenerate the generated passwords when doing a redeploy? It is not Keystone specific, as the same kind of thing would be needed for Rabbit, and for databases.
Using the CLI most users would get initial passwords generated via python-tripleoclient. These CLI passwords can be overridden by environment variables on the CLI by specifying something like (for glance) OVERCLOUD_GLANCE_PASSWORD. Python-tripleoclient uses these environment variables to construct a heat environment to set all of these passwords. If an end user wanted to change a password for one of the services (manually) and have it re-deployed via Heat then one could create a custom Heat environment file and append it onto the 'overcloud deploy' command with a -e. So something like: parameters_defaults: GlancePassword: fooboar This would set the Glance password to the hard coded value above. All of this works today and should allow changing passwords driven via Heat. The tricker parts of this are where these passwords apply to keystone and or mysql database settings that also need to be update. In some cases the puppet providers should take care of updating passwords for these services accordingly. In others there may be manual changes required for cluster type password changes and there is probably still feature work to do on this front (Rabbit and Mysql password changes for example).
Hi Dan, It seems that AdminPassword can not be set in this way. parameter_defaults: AdminPassword: "redhatgss" The deployment itself succeeded but the endpoints are abnormal: Only the endpoints for nova were created. MariaDB [keystone]> select interface,url,enabled from endpoint; +-----------+---------------------------------+---------+ | interface | url | enabled | +-----------+---------------------------------+---------+ | internal | http://192.168.124.21:5000/v2.0 | 1 | | public | http://10.11.48.181:5000/v2.0 | 1 | | admin | http://192.0.2.14:35357/v2.0 | 1 | +-----------+---------------------------------+---------+ Is this a known bug or do I need to file a new one ? Best Regards, Chen
Sorry not nova endpoints but keystone endpoints...
Chen: This might be a new, but related bug. I'm going to try and replicate this myself today.
Changing deployed passwords is in the same problem space as rotating passwords, closing as duplicate. *** This bug has been marked as a duplicate of bug 1337297 ***