Open Stack

On Thu, Feb 28, 2019 at 4:02 AM Jonathan Rosser <
jonathan.rosser at rd.bbc.co.uk> wrote:

>
> On 27/02/2019 20:49, Zane Bitter wrote:
> > 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?
> >
> The most concrete example I can give is that of a Magnum k8s deployment,
> where heat is used to create several VM and deploy software. Callback
> URLs are embedded into those VM and SoftwareDeployments, and the
> Callback URL must be accessible from the VM, this would always need to
> be something that could reasonably be called a "Public" endpoint.
>
> Conversely, heat itself needs to be able to talk to many other openstack
> components, defined in the [clients_*] config sections. It is reasonable
> to describe these interactions as being "Internal" - I may misunderstand
> some of this though.
>
> So here lies the issue - appropriate entries in heat.conf to make
> internal interactions between heat and horizon (one example) work in
> real-world deployments results in the keystone internal URL being placed
> in callbacks, and then SoftwareDemployments never complete as the
> internal keystone URL is not usually accessible to a VM. I suspect that
> there is not much coverage for this kind of network separation in gate
> tests.
>
>
I think the crux of issue is that we use the same keystone endpoint
(auth_uri/ www_authenticate_uri from 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.

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/www_authenticate_uri)
which is beyond my involvement with heat.

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.

[1]
https://github.com/openstack/heat/blob/master/heat/common/context.py#L255

[2]
https://github.com/openstack/heat/blob/master/heat/engine/resources/signal_responder.py#L106

[3]
https://github.com/openstack/heat/blob/master/heat/engine/clients/os/keystone/heat_keystoneclient.py

[4]
https://github.com/openstack/heat/commit/1e71566169d9ffb34ed4e1bdf3f264cbdbb567cb#diff-e3a36cd5713124c3901fb0e8c6016357


> > 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).
> >
> I think that as far as heat itself interacting with other openstack
> components is concerned there does not need to be more than one
> auth_url. However it is very important to make a distinction between the
> context in which the heat code runs and the context of a VM created by
> heat - any callback URL created must be valid for the context of the VM,
> not the heat code.
>
> > 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
> >
> Colleen makes some observations about the use of keystone config in heat
> - and interestingly suggests a seperate config entry for cases where a
> keystone URL should be handed on to another service. Mohammed and I have
> already discussed additional config options being a potential solution
> whilst trying to debug this.
>
> There are already examples of similar config options in heat.conf, such
> as "heat_waitcondition_server_url" - would additonal config items such
> as server_base_auth_url and signal_responder_auth_url be appropriate so
> that we can be totally explicit about the endpoints handed on to created
> VM?
>
>
>
>

-- 
Regards,
Rabi Mishra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190228/99b9c6ba/attachment-0001.html>