aboutsummaryrefslogtreecommitdiffstats
path: root/environments/tls-endpoints-public-dns.yaml
AgeCommit message (Collapse)AuthorFilesLines
2016-08-23Move resource registry override to enable-tls.yamlJuan Antonio Osorio Robles1-3/+0
It makes more sense for the enable-tls.yaml file to contain the resource registry override, since it contains parameters that are actually used there. Also, this allows us to reuse the tls-endpoints-public-* files for other methods of enabling TLS (such as with certmonger). Change-Id: I98c63d0007e61968c0490a474eddb42548891fa6
2016-08-12Decouple EndpointMap from SSL certificate paramsBen Nemec1-0/+55
Having the endpoint map in the same environment as the SSL certificate parameters means that every time a service is added to the overcloud, the user must remember to update their copy of enable-tls.yaml to reflect the new service. To avoid this, let's separate the SSL EndpointMap from the SSL certificates so users can simply pass the shipped list of SSL endpoints and only have to customize the certificate env file. As and added bonus, this means they won't have to put the certificates in enable-tls.yaml specifically. The parameters can be set anywhere, and will be used as long as one of the tls-endpoints envs is also specified. inject-trust-anchor.yaml is not changed, but it could already be used in the same fashion. The root certificate param could be set in any env passed after inject-trust-anchor.yaml, and then inject-trust-anchor.yaml would only be responsible for setting the appropriate resource_registry entry. This way there is no need to customize the in-tree inject-trust-anchor.yaml either. Change-Id: I38eabb903b8382e6577ccc97e21fbb9d09c382b3