Description of problem: With OSP-d 7.3 we introduced SSL support for the overcloud public endoints. We should also get instructions for how to enable SSL when deploying with an external load balancer. Here are the SSL docs for the regular deployment: http://docs-draft.openstack.org/06/265006/3/check/gate-tripleo-docs-docs/379ec1c//doc/build/html/advanced_deployment/ssl.html When deploying with an external load balancer we need to basically combine the ssl environments and the external load balancer environment files. A deploy command example is: openstack overcloud deploy --templates ~/templates/my-overcloud \ -e ~/templates/my-overcloud/environments/network-isolation.yaml \ -e ~/templates/network-environment.yaml \ -e ~/templates/enable-tls-external-lb.yaml \ -e ~/templates/inject-trust-anchor.yaml \ -e ~/templates/my-overcloud/environments/external-loadbalancer-vip.yaml \ -e ~/templates/external-lb.yaml \ -e /home/stack/templates/firstboot-environment.yaml \ --control-scale 3 \ --compute-scale 1 \ --ntp-server 10.5.26.10 \ --libvirt-type qemu enable-tls-external-lb.yam can contain an emtpy string for the SSLCertificate, SSLIntermediateCertificate and SSLKey parameters because they will be stored on the loadbalanacer itself. inject-trust-anchor.yaml should contain the root ca certificate. This type of the deployment corresponds to the following scenario: SSL on load balancer. Configure standard (non-SSL) on the controllers, still using the external load balancer environment. Configure the external SSL load balancer to terminate the SSL, and use basic unencrypted HTTP between the load balancer and the controllers.
Ben, could you please advise on the proper content of enable-tls.yaml when using an external load balancer? According to my tests passing an enable-tls.yaml that doesn't contain the SSLCertificate, SSLIntermediateCertificate and SSLKey parameters, only the EndpointMap fails with: Deploying templates in the directory /home/stack/templates/my-overcloud Stack failed with status: Resource CREATE failed: resources[1]: resources.Controller.Property error: resources.NodeTLSData.properties: Property SSLKey not assigned ERROR: openstack Heat Stack create failed. The environment looks like this: parameter_defaults: EndpointMap: [endpoint map entries from enable-tls.yaml] If it contains the parameters as empty strings then deployment completes ok: parameter_defaults: SSLCertificate: '' SSLIntermediateCertificate: '' SSLKey: '' EndpointMap: [endpoint map entries from enable-tls.yaml] Also if the parameters contain the certificates and the key as with a regular deployment then it completes ok.
It should not be looking for those parameters with just the EndpointMap. Do you have the resource_registry entry from enable-tls.yaml somewhere also? That's what tells Heat to look for the certificate parameters.
Moving the proposed doc text from the other bug to this one.
My bad, I was still having the resource_registry entry in the enable-tls.yaml. Thanks for the help. Here is the environment that I used to pass the deployment: stack@instack:~>>> cat ~/templates/enable-tls-external-lb.yaml parameter_defaults: EndpointMap: CeilometerAdmin: {protocol: 'http', port: '8777', host: 'IP_ADDRESS'} CeilometerInternal: {protocol: 'http', port: '8777', host: 'IP_ADDRESS'} CeilometerPublic: {protocol: 'https', port: '13777', host: 'CLOUDNAME'} CinderAdmin: {protocol: 'http', port: '8776', host: 'IP_ADDRESS'} CinderInternal: {protocol: 'http', port: '8776', host: 'IP_ADDRESS'} CinderPublic: {protocol: 'https', port: '13776', host: 'CLOUDNAME'} GlanceAdmin: {protocol: 'http', port: '9292', host: 'IP_ADDRESS'} GlanceInternal: {protocol: 'http', port: '9292', host: 'IP_ADDRESS'} GlancePublic: {protocol: 'https', port: '13292', host: 'CLOUDNAME'} GlanceRegistryAdmin: {protocol: 'http', port: '9191', host: 'IP_ADDRESS'} GlanceRegistryInternal: {protocol: 'http', port: '9191', host: 'IP_ADDRESS'} GlanceRegistryPublic: {protocol: 'https', port: '9191', host: 'IP_ADDRESS'} # Not set on the loadbalancer yet. HeatAdmin: {protocol: 'http', port: '8004', host: 'IP_ADDRESS'} HeatInternal: {protocol: 'http', port: '8004', host: 'IP_ADDRESS'} HeatPublic: {protocol: 'https', port: '13004', host: 'CLOUDNAME'} HorizonPublic: {protocol: 'https', port: '443', host: 'CLOUDNAME'} KeystoneAdmin: {protocol: 'http', port: '35357', host: 'IP_ADDRESS'} KeystoneInternal: {protocol: 'http', port: '5000', host: 'IP_ADDRESS'} KeystonePublic: {protocol: 'https', port: '13000', host: 'CLOUDNAME'} NeutronAdmin: {protocol: 'http', port: '9696', host: 'IP_ADDRESS'} NeutronInternal: {protocol: 'http', port: '9696', host: 'IP_ADDRESS'} NeutronPublic: {protocol: 'https', port: '13696', host: 'CLOUDNAME'} NovaAdmin: {protocol: 'http', port: '8774', host: 'IP_ADDRESS'} NovaInternal: {protocol: 'http', port: '8774', host: 'IP_ADDRESS'} NovaPublic: {protocol: 'https', port: '13774', host: 'CLOUDNAME'} NovaEC2Admin: {protocol: 'http', port: '8773', host: 'IP_ADDRESS'} NovaEC2Internal: {protocol: 'http', port: '8773', host: 'IP_ADDRESS'} NovaEC2Public: {protocol: 'https', port: '13773', host: 'CLOUDNAME'} NovaVNCProxyAdmin: {protocol: 'http', port: '6080', host: 'IP_ADDRESS'} NovaVNCProxyInternal: {protocol: 'http', port: '6080', host: 'IP_ADDRESS'} NovaVNCProxyPublic: {protocol: 'https', port: '13080', host: 'CLOUDNAME'} SwiftAdmin: {protocol: 'http', port: '8080', host: 'IP_ADDRESS'} SwiftInternal: {protocol: 'http', port: '8080', host: 'IP_ADDRESS'} SwiftPublic: {protocol: 'https', port: '13808', host: 'CLOUDNAME'}
Yeah, that should work. Maybe the doc text should explicitly say not to include the resource_registry?
Was looking through my backlog and found this BZ. I revised the Ext LB Guide since the environment files have changed for OSP10. For Ext LB, you no longer need the enable-tls.yaml file. However the endpoint map has been moved to its own file (or rather files -- one for DNS and one for IP). Plus you still need the file to inject the CA. Here's the revised content: https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/11/html-single/external_load_balancing_for_the_overcloud/#configuring_ssl_for_load_balancing @Ben and Marius -- How does it look? Anything further we need to add to this section?
I've never actually deployed with an external loadbalancer, but the process sounds right to me.
Closing this BZ as it appears to be resolved.