© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
Hey James, some comments:
- Please add a note to config.yaml or docs stating ssl_cert + ssl_key are expected to be input as base64 encoded.
- Once I realized that, I did a juju set openstack-dashboard ssl_key="$(cat /tmp/key | base64)" ssl_cert="$(cat tmp/cert | base64)" but was getting base64 decode errors in config-changed, needed to update the horizon-common cert config function:
key=$2
- echo $cert | base64 -d > /etc/ssl/
- echo $key | base64 -d > /etc/ssl/
+ echo $cert | base64 -di > /etc/ssl/
+ echo $key | base64 -di > /etc/ssl/
chmod 0600 /etc/ssl/
- I don't think its a blocker, but one issue with putting SSL termination behind haproxy is that all service units are sharing the same certificate. When deploying with custom certificates, its the deployers responsibility to provide a certificate that will work for all dashboard hosts. When using hacluster/VIP, a cert signed for a single common name (the VIP) would work. However, if we want to use keystone-provided certificates (I hope to), when there is no VIP/hacluster, the generated certificate will only be signed for the eligible leader at the time the keystone <-> dashboard relation is made. This will work okay initially, but if that initial leader host goes away and requests start hitting another node in the service group, a certificate for an invalid host will be used and a browser warning. This is less of an issue for the dashboard since it ends with a browser warning, but more of an issue if we plan on using this configuration for the internal openstack API traffic.
- Also, can you please include the latest openstack-common helper from lp:~openstack-charmers/openstack-charm-helpers/ha-helpers and rebase your changes to that code against the latest? It'll make syncing these changes easier once this merges, and I expect we'll be using the haproxy changes elsewhere.