Charms need config option to set public endpoint address

[Billy Olsen]

Charms determine the public URL based upon the public IP addresses that are available on the os-public-network. In some installations, the public IP is not available on the node itself, but is instead provided by a reverse proxy elsewhere. In these instances, an option should be made available to allow the publicURL to be specified so that the endpoints registered within keystone refer to the public URL specified.

For example, if my swift service is provided externally through https://files.example.com but the files.example.com host does not reside on the swift-proxy unit there is no way via the charm to advertise the publicURL in a publicly consumable manner.

[Peter Sabaini (peter-sabaini)]

One additional point re: motivation -- for a public service, you'd also want the SSL certs be issued by a ext. CA. Issuing certs for IP addresses is cumbersome and hard to maintain; ususally we try to stick to our wildcard *.c.c cert for economy

[Ante Karamatić (ivoks)]

Allowing publicURL to be configured is something that would be benefitial for all charms that create endpoints. Most of the time deployment only has private IPs, but people do NAT/proxy to those IPs. Problem is then with keystone who serves private IPs as endpoints.

[JuanJo Ciarlante (jjo)]

+1 we need this added to every relevant OS charm with a service
(in keystone catalog).

As a suggestion, please consider adding some minimal auto-templating, like
#1 public_url: https://{{service_name}}.os.example.com:{{service_port}}/{{service_path}}
or
#2 public_url: https://{{service_type}}.os.example.com:{{service_port}}/{{service_path}}

which would expand to e.g.
#1:
- https://keystone.os.example.com:5000/v2.0
- https://swift-proxy.os.example.com:8080/v1/AUTH_xxx
- https://nova-cloud-controller.os.example.com:8774/v2/yyy
#2:
- https://identity.os.example.com:5000/v2.0
- https://object-store.os.example.com:8080/v1/AUTH_xxx
- https://compute.os.example.com:8774/v2/yyy

FYI above would allow us to set a single 'override:' line at juju-deploy config.

[Billy Olsen (billy-olsen)]

I've provided a merge proposal for various charms which provides an os-public-hostname option allowing for a user to specify what the base hostname portion of the endpoint URLs is. It doesn't allow for a complete re-write of the API endpoint, but it does allow for the primary use cases to be addressed; NAT'ing the private IP and wildcard certificates.

[Corey Bryant (corey.bryant)]

Hi Billy, Do you have an mp for heat?