Comment 10 for bug 1664521

Revision history for this message
Dougal Matthews (d0ugal) wrote :

I had another look at this, and think I actually understood it this time. This works in tripleoclient because it merges the templates and environments and adds them to the Mistral environment parameter_defaults.

Currently the order in which parameters are used is this:

1. Mistral environment parameter_defaults (so the CLI wins by settings parameters here)
2. Mistral environment passwords
3. Environment files
4. Template defaults

1 and 2 are merged and added here: https://github.com/openstack/tripleo-common/blob/master/tripleo_common/actions/templates.py#L273-L288

3. is added here: https://github.com/openstack/tripleo-common/blob/master/tripleo_common/actions/templates.py#L264-L271

So, this means that the CephClientKey in parameter_defaults (user set) then in passwords (generated) always wins over environment files. Only manual edits in the GUI would overwrite the generated passwords. This isn't specific to CephClientKey and will be the same for all generated passwords.

There are a couple of options that I see.

1. Users can disable password generation if they want to set them manually like this (but this is all or nothing, you can't stop generation for specific passwords only).

2. We change the way passwords are generated so they are only generated when no password is given in the environment file or template (we can't tell the difference after merging). This would mean moving the password generation to happen when a user deploys I think. Since at the moment passwords are generated before environments are enabled.

The first is likely a good workaround for now and the second option is a possible longer term fix, but it will require a fair bit of work.