Open Stack

On 27/02/19 4:13 PM, Colleen Murphy wrote:
> Hi,
> 
> On Wed, Feb 20, 2019, at 7: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 = ...
> 
> I know very little about heat, but  I think there's some confusion about what [keystone_authtoken]/www_authenticate_uri is for, and after grepping a bit I think heat is misusing it. www_authenticate_uri (formerly known as auth_uri) is meant to be used by keystonemiddleware to set the WWW-Authenticate header in its response when a client request fails to present a valid keystone token. It's a wsgi middleware, so heat shouldn't be using it or even be aware of it. You would normally set it to keystone's public endpoint since it's what the server would present to an end user to help them retry their request. If the client already knows the right auth URL and grabs a token beforehand, it will never see what's in www_authenticate_uri.

Thanks Colleen!

> Heat appears to be using it for its own purposes, which I think is not advisable. If heat needs to provide other subsystems or services with a URL for keystone, it should do that in a separate config.

Ooh, I know this one because Johannes schooled me on it a couple of 
months back :)

We actually do have a separate config, it's [clients_keystone]/auth_uri. 
If, and only if, the user does not provide a value for that, we fall 
back to using the value in [keystone_authtoken]/www_authenticate_uri.

https://git.openstack.org/cgit/openstack/heat/tree/heat/common/endpoint_utils.py#n25

> I don't really have enough heat knowledge to make a recommendation for the issues below. While keystoneauth provides a way to filter the service catalog by admin/internal/public endpoint, it obviously doesn't help much when you don't know where keystone is yet.

Yeah, that seems to be the heart of the problem. 
[clients_keystone]/auth_uri is being used in multiple different ways for 
different things that may have different access to the various networks 
(some of which Heat has no control over - we give the user the URL and 
it's up to them where it is called from).

cheers,
Zane.

> Colleen
> 
>>
>> 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
>>
>> 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
>>
>>
>