On 20/02/19 1:40 PM, Jonathan Rosser wrote: > In openstack-ansible we are trying to help a number of our end users > with their heat deployments, some of them in conjunction with magnum. > > There is some uncertainty with how the following heat.conf sections > should be configured: > > [clients_keystone] > auth_uri = ... > > [keystone_authtoken] > www_authenticate_uri = ... > > It does not appear to be possible to define a set of internal or > external keystone endpoints in heat.conf which allow the following: > > * The orchestration panels being functional in horizon > * Deployers isolating internal openstack from external networks > * Deployers using self signed/company cert on the external endpoint > * Magnum deployments completing > * Heat delivering an external endpoint at [1] > * Heat delivering an external endpoint at [2] > > There are a number of related bugs: > > https://bugs.launchpad.net/openstack-ansible/+bug/1814909 > https://bugs.launchpad.net/openstack-ansible/+bug/1811086 > https://storyboard.openstack.org/#!/story/2004808 > https://storyboard.openstack.org/#!/story/2004524 Based on this and your comment on IRC[1] - and correct me if I'm misunderstanding here - the crux of the issue is that the Keystone auth_url must be accessed via different addresses depending on which network the request is coming from? I don't think this was ever contemplated as a use case in developing Heat. For my part, I certainly always assumed that while the Keystone catalog could contain different Public/Internal/Admin endpoints for each service, there was only a single place to access the catalog (i.e. each cloud had a single unique auth_url). It's entirely possible this wasn't a valid assumption about the how clouds would/should be deployed in practice. If that's the case then we likely need some richer configuration options. The design of the Keystone catalog predates both the existence of Heat and the idea that cloud workloads might have reason to access the OpenStack APIs, and nobody is really an expert on both although we've gotten better at communicating. [1] http://eavesdrop.openstack.org/irclogs/%23heat/%23heat.2019-02-26.log.html#t2019-02-26T17:14:14 > Any help we could get from the heat team to try to understand the root > cause of these issues would be really helpful. > > Jon. > > > [1] > https://github.com/openstack/heat/blob/master/heat/engine/resources/server_base.py#L87 > > > [2] > https://github.com/openstack/heat/blob/master/heat/engine/resources/signal_responder.py#L106 > >