chef-cookbooks
chef-cookbooks copied to clipboard
rcbops
Use FQDN for Keystone Endpoints
We need the ability to use a FQDN for Keystone endpoints, specifically when using SSL. Currently, when overwriting "uri" it will also use that as the bind address for HAproxy which causes an HAproxy misconfiguration.
Without using a FQDN with SSL endpoints, a certificate will show as invalid since it's tied to an FQDN and not an IP address. This means you have to use "--insecure" to talk to the APIs. rpcdaemon does not currently support using the "insecure" option.
@rpawlik What happens now if you just specify the endpoint uri in attrs w/ the full host name? I'd assume otherwise, it's using what Ohai sees in ["fqdn"]
Putting this in 4.2.3 milestone since there's a big batch of https related api fixes going in.
Also, can you elaborate on the infra a little bit? The hostnames (short/long), what it does now, what you expect, config snippets, etc? In this case, even when using fqdn, are the ssl certs self signed (so they would potentially invalid by name anyways), or are they using custom certs?
Basically, the more detail the better on this one. Thanks!
If you specify with a hostname, it causes HAproxy configuration issues because HAproxy needs an IP address. Here's what the customer gave us:
"I went through https://github.com/rcbops/chef-cookbooks/issues/463, but I have yet to find a valid solution for setting FQDN's for endpoints with HA controllers. One side affect of overriding 'uri' with a FQDN or 'host' with a FQDN of a VIP address is the FQDN gets set as 'bind_host' for that service. haproxy then has an invalid configuration.
Without FQDN's for the endpoint URI's, SSL certs are not trusted when https scheme is enabled. While you can pass '--insecure' to various commands, 'rpcdaemon' does not have an option to run in 'insecure' mode and does not start.
Can you send me an example chef environment that has endpoints set as FQDN's and https enabled? "
So it looks like we setting the HAproxy bind host to the same IP/hostname we're using for the URL endpoints.
Essentially, they want to use a valid hostname and https as the URL endpoints so they can use a valid certificate and not get any cert warnings.
@seancarlisle At this time, fixing this issue is not scheduled for any particular release. We are currently investigating a few rabbit holes that need fixing in OpenStack upstream.