Description:
There was an error in the fix that was committed in commit 42cfbbc8bfbaa401d6e774b58cb78f4bbaccc2d9 in THT. The relevant data that is written to clouds.yaml is constructed here:
https://github.com/openstack/tripleo-heat-templates/blob/master/deployment/keystone/keystone-container-puppet.yaml#L746-L760
The problem here is that the auth_url refers to the public endpoint, whereas the CA cert defined there is for the internal endpoint. That is, the parameter InternalTLSCAFile is only supposed to be used to refer to the ca cert used for TLS on internal endpoints.
Now, you would not see a problem if you had a deployment with TLS-Everywhere where all the certs (both public and private) are issued by the IPA server.
Nor would you see a problem with just public TLS - although this is somewhat lucky because the parameter InternalTLSCAFile is really being used incorrectly to refer to where the public TLS CA cert is located. In this case, the deployment can work because the InternalTLSCAFile is not being used on the internal interfaces. It can however lead to weird upgrade problems and has in fact led to some infrared failures.
Where you will definitely see a problem though is when you try to set up an environment where the public interface cert is issued by a given cert ("public TLS") and the internal interfaces are protected by certs issued by IPA. This is essentially the environment that is set up when we try to do a brownfield deployment. That is , update a public TLS only system to have tls-everywhere but keep the public certs intact.
It won't work because what you need to insert to allow the undercloud to reach keystone in cloud.yaml (on the public interface) is not the same as what is needed to set up the internal interfaces correctly.
I tested this - and there is simply no way to make it work. You can't use the same parameter to make both public and private interfaces happy.
What I did test though, was adding a new parameter ExternalTLSCAFile - which I defaulted to "" to the keystone template. This is after all exactly what we are describing in clouds.yaml. With that change, I was able to get the brownfield deployment to work.
Fix proposed to branch: master
Review: https:/