Open Stack

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