Open Stack

On 09/09/15 04:10, SHTILMAN, Tomer (Tomer) wrote:
>
>
>>> 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
>
>> Zane wrote:
>> 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.
>
> Thanks Zane for your reply
> My understanding was that with keystone federation once you have a token issued by one keystone the other one respect it and there is no need to re-authenticate with the second keystone.

OK, that sounds close to what Kevin said as well, which was that you use 
your token from the local keystone to obtain a token from the remote 
keystone that will allow you to access the remote Heat. If that's the 
case we'll need to write some code to grab that other token, but either 
way it all sounds relatively straightforward without any security headaches.

I know there are people who want to do this with clouds that are not 
federated (and even people with custom resources for non-OpenStack 
clouds who want to use this) so we may still need to find a solution for 
the credential thing in the long term, but I see no reason not to start 
now by implementing the federation case - that will solve a big subset 
of the problem and doesn't foreclose any future development paths.

> My thinking was more of changing the remote stack resource to have in the context the heat_url of the other node ,I am not sure if credentials are needed here.

Not the heat_url, but the auth_url - we'll obtain the Heat endpoint from 
the remote keystone catalog, just like we do locally. But other than 
that, exactly - it's just another optional sub-property of the context 
on the remote stack resource.

> We are currently building in our lab multi cloud setup with keystone federation and I will check if my understating is correct, I am planning for propose a BP for this once will be clear

+1

> Thanks again
> Tomer
>
> __________________________________________________________________________
> 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
>