Can I make charmed Openstack services use internal APIs rather than public ones?

I’m starting from the position of having all my service endpoints defined the same for internal and public services. The APIs are in fact all private at this point, instances running in Openstack cannot reach them. I want to provide some proper public endpoints in order to bootstrap Juju within Openstack.

The setup uses nginx to proxy Horizon and novnc to the existing private API endpoints. I am trying to use the same nginx to proxy all the APIs, but I run in to a problem. After setting os-public-hostname to point to the nginx proxy, I now find e.g. openstack-dashboard trying to use the newly defined public API. Actually this API is only available to the public and not to the internals.

The documentation https://docs.openstack.org/security-guide/api-endpoints/api-endpoint-configuration-recommendations.html describes how to make such configurations but I don’t see any support for it in the charms. I expect I am going about this the wrong way.

Is there any advice about this please?

Update: I just noticed I can indeed set use-internal-endpoints=true in nova-cloud-controller and other places, but apparently not in openstack-dashboard. Problem half solved, but unable to log in to Horizon.

I think the right place to be asking this sort of question is in a bug report on the openstack charms themselves
https://bugs.launchpad.net/charm-openstack-dashboard

The openstack-dashboard charm has a config option called endpoint-type which you should be able to set to “internalURL” in order to tell the Horizon to use the internal endpoints. It is a bit inconsistent in that it doesn’t have the clear use-internal-endpoints=true option. I’ve raised bug 1895758 for the inconsistency.

@jameinel thanks yes. Having reported too many bugs that were not bugs I wasn’t sure, but point taken.

@billy-olsen I found that option and tried the setting suggested;

routergod@juju:~$ juju config openstack-dashboard endpoint-type
internalURL

But I have the same result. Trying to log in produces a message “Unable to establish connection to keystone endpoint.”

I raised bug 1895819 in relation to that last point.