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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
