[openstack-dev] [Heat] Multi Node Stack - keystone federation

Fox, Kevin M Kevin.Fox at pnnl.gov
Tue Sep 8 16:01:53 UTC 2015


I think it lets you take a token on the identity cloud and provide it to the service cloud and get a token for that cloud. So I think it might do what we need without storing credentials.

Thanks,
Kevin
________________________________________
From: Zane Bitter [zbitter at redhat.com]
Sent: Tuesday, September 08, 2015 7:53 AM
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] [Heat] Multi Node Stack - keystone federation

On 07/09/15 05:27, SHTILMAN, Tomer (Tomer) wrote:
> Hi
>
> Currently in heat we have the ability to deploy a remote stack on a
> different region using OS::Heat::Stack and region_name in the context
>
> My question is regarding multi node , separate keystones, with keystone
> federation.
>
> Is there an option in a HOT template to send a stack to a different
> node, using the keystone federation feature?
>
> For example ,If I have two Nodes (N1 and N2) with separate keystones
> (and keystone federation), I would like to deploy a stack on N1 with a
> nested stack that will deploy on N2, similar to what we have now for regions

Short answer: no.

Long answer: this is something we've wanted to do for a while, and a lot
of folks have asked for it. We've been calling it multi-cloud (i.e.
multiple keystones, as opposed to multi-region which is multiple regions
with one keystone). In principle it's a small extension to the
multi-region stacks (just add a way to specify the auth_url as well as
the region), but the tricky part is how to authenticate to the other
clouds. We don't want to encourage people to put their login credentials
into a template. I'm not sure to what extent keystone federation could
solve that - I suspect that it does not allow you to use a single token
on multiple clouds, just that it allows you to obtain a token on
multiple clouds using the same credentials? So basically this idea is on
hold until someone comes up with a safe way to authenticate to the other
clouds. Ideas/specs welcome.

cheers,
Zane.

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



More information about the OpenStack-dev mailing list