Don't have separate protocols/ports for Keystone v3
authorZane Bitter <zbitter@redhat.com>
Wed, 24 Feb 2016 17:04:59 +0000 (12:04 -0500)
committerJuan Antonio Osorio Robles <jaosorior@redhat.com>
Mon, 11 Apr 2016 04:50:28 +0000 (04:50 +0000)
commitd773227e7d18165750bd86a79b95d14bbc3702d9
tree5d1d7c055f556c6c242b2526890cb4664bba63b4
parent49bae7f298c636887797d5c586328afb4241d8ff
Don't have separate protocols/ports for Keystone v3

The change in ab068a824ed51e78bf111387223e58e885ec5c84 is described as
temporary, so it would be better if it did not affect the EndpointMap
parameter (which is effectively a public interface, since it may be
overridden in an environment file). No configuration should end up with
different ports/protocols/hosts for Keystone v2 and v3, and somebody
customising them should not have to account for them separately. Nor
should things break when the need to distinguish between v2 and v3
endpoints goes away.

This change removes the KeystoneV3* keys from the EndpointMap input and
uses the Keystone* keys instead, so that any change to the internal
organisation becomes transparent to the user.

Change-Id: If4cdd9232f4dbc9f2af651bbdfe68f09dc26ed2e
environments/enable-tls.yaml
network/endpoints/endpoint_data.yaml
network/endpoints/endpoint_map.yaml