<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">On Thu, Feb 28, 2019 at 4:02 AM Jonathan Rosser <<a href="mailto:jonathan.rosser@rd.bbc.co.uk">jonathan.rosser@rd.bbc.co.uk</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
On 27/02/2019 20:49, Zane Bitter wrote:<br>
> On 20/02/19 1:40 PM, Jonathan Rosser wrote:<br>
>> In openstack-ansible we are trying to help a number of our end users <br>
>> with their heat deployments, some of them in conjunction with magnum.<br>
>><br>
>> There is some uncertainty with how the following heat.conf sections <br>
>> should be configured:<br>
>><br>
>> [clients_keystone]<br>
>> auth_uri = ...<br>
>><br>
>> [keystone_authtoken]<br>
>> www_authenticate_uri = ...<br>
>><br>
>> It does not appear to be possible to define a set of internal or <br>
>> external keystone endpoints in heat.conf which allow the following:<br>
>><br>
>>   * The orchestration panels being functional in horizon<br>
>>   * Deployers isolating internal openstack from external networks<br>
>>   * Deployers using self signed/company cert on the external endpoint<br>
>>   * Magnum deployments completing<br>
>>   * Heat delivering an external endpoint at [1]<br>
>>   * Heat delivering an external endpoint at [2]<br>
>><br>
>> There are a number of related bugs:<br>
>><br>
>> <a href="https://bugs.launchpad.net/openstack-ansible/+bug/1814909" rel="noreferrer" target="_blank">https://bugs.launchpad.net/openstack-ansible/+bug/1814909</a><br>
>> <a href="https://bugs.launchpad.net/openstack-ansible/+bug/1811086" rel="noreferrer" target="_blank">https://bugs.launchpad.net/openstack-ansible/+bug/1811086</a><br>
>> <a href="https://storyboard.openstack.org/#!/story/2004808" rel="noreferrer" target="_blank">https://storyboard.openstack.org/#!/story/2004808</a><br>
>> <a href="https://storyboard.openstack.org/#!/story/2004524" rel="noreferrer" target="_blank">https://storyboard.openstack.org/#!/story/2004524</a><br>
><br>
> Based on this and your comment on IRC[1] - and correct me if I'm <br>
> misunderstanding here - the crux of the issue is that the Keystone <br>
> auth_url must be accessed via different addresses depending on which <br>
> network the request is coming from?<br>
><br>
The most concrete example I can give is that of a Magnum k8s deployment, <br>
where heat is used to create several VM and deploy software. Callback <br>
URLs are embedded into those VM and SoftwareDeployments, and the <br>
Callback URL must be accessible from the VM, this would always need to <br>
be something that could reasonably be called a "Public" endpoint.<br>
<br>
Conversely, heat itself needs to be able to talk to many other openstack <br>
components, defined in the [clients_*] config sections. It is reasonable <br>
to describe these interactions as being "Internal" - I may misunderstand <br>
some of this though.<br>
<br>
So here lies the issue - appropriate entries in heat.conf to make <br>
internal interactions between heat and horizon (one example) work in <br>
real-world deployments results in the keystone internal URL being placed <br>
in callbacks, and then SoftwareDemployments never complete as the <br>
internal keystone URL is not usually accessible to a VM. I suspect that <br>
there is not much coverage for this kind of network separation in gate <br>
tests.<br>
<br></blockquote><div><br></div><div>I think the crux of issue is that we use the same keystone endpoint (auth_uri/ <span class="gmail-im">www_authenticate_uri from </span>clients_keystone/keystone_authtoken sections in heat.conf) when creating the auth_plugins in the context[1], heat internal keystone objects[3] and the keystone auth_url[2] we pass on to the instances for signaling.<br></div><div><br></div><div>We've auth_url middleware that sets X-Auth-Url header in the request by reading the above config options.  There is probably some history[4] (i.e on why we fallback to use [keystone_authtoken]auth_uri/<span class="gmail-im">www_authenticate_uri) which is beyond my involvement with heat.<br></span></div><div><span class="gmail-im"><br></span></div><div><span class="gmail-im">AFAICT, we're aware of this problem for sometime and no one ever tried to fix it. I think we can provide a separate config option for what auth_url we send to the instances as they may not  be in the same network, as the ones like other services use.<br></span></div><div><br></div><div>[1] <a href="https://github.com/openstack/heat/blob/master/heat/common/context.py#L255">https://github.com/openstack/heat/blob/master/heat/common/context.py#L255</a><br></div><div><br></div><div>[2]  <a href="https://github.com/openstack/heat/blob/master/heat/engine/resources/signal_responder.py#L106">https://github.com/openstack/heat/blob/master/heat/engine/resources/signal_responder.py#L106</a></div><div><br></div><div>[3] <a href="https://github.com/openstack/heat/blob/master/heat/engine/clients/os/keystone/heat_keystoneclient.py">https://github.com/openstack/heat/blob/master/heat/engine/clients/os/keystone/heat_keystoneclient.py</a></div><div><br></div><div>[4] <a href="https://github.com/openstack/heat/commit/1e71566169d9ffb34ed4e1bdf3f264cbdbb567cb#diff-e3a36cd5713124c3901fb0e8c6016357">https://github.com/openstack/heat/commit/1e71566169d9ffb34ed4e1bdf3f264cbdbb567cb#diff-e3a36cd5713124c3901fb0e8c6016357</a><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> I don't think this was ever contemplated as a use case in developing <br>
> Heat. For my part, I certainly always assumed that while the Keystone <br>
> catalog could contain different Public/Internal/Admin endpoints for <br>
> each service, there was only a single place to access the catalog <br>
> (i.e. each cloud had a single unique auth_url).<br>
><br>
I think that as far as heat itself interacting with other openstack <br>
components is concerned there does not need to be more than one <br>
auth_url. However it is very important to make a distinction between the <br>
context in which the heat code runs and the context of a VM created by <br>
heat - any callback URL created must be valid for the context of the VM, <br>
not the heat code.<br>
<br>
> It's entirely possible this wasn't a valid assumption about the how <br>
> clouds would/should be deployed in practice. If that's the case then <br>
> we likely need some richer configuration options. The design of the <br>
> Keystone catalog predates both the existence of Heat and the idea that <br>
> cloud workloads might have reason to access the OpenStack APIs, and <br>
> nobody is really an expert on both although we've gotten better at <br>
> communicating.<br>
><br>
> [1] <br>
> <a href="http://eavesdrop.openstack.org/irclogs/%23heat/%23heat.2019-02-26.log.html#t2019-02-26T17:14:14" rel="noreferrer" target="_blank">http://eavesdrop.openstack.org/irclogs/%23heat/%23heat.2019-02-26.log.html#t2019-02-26T17:14:14</a><br>
><br>
Colleen makes some observations about the use of keystone config in heat <br>
- and interestingly suggests a seperate config entry for cases where a <br>
keystone URL should be handed on to another service. Mohammed and I have <br>
already discussed additional config options being a potential solution <br>
whilst trying to debug this.<br>
<br>
There are already examples of similar config options in heat.conf, such <br>
as "heat_waitcondition_server_url" - would additonal config items such <br>
as server_base_auth_url and signal_responder_auth_url be appropriate so <br>
that we can be totally explicit about the endpoints handed on to created VM?<br>
<br>
<br>
<br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Regards,</div>Rabi Mishra<div><br></div></div></div></div></div></div></div></div></div></div></div>