curious

[Krieger, Orran]

What you know about this: https://wiki.openstack.org/wiki/Inter_Cloud_Resource_Federation#InterCloud_Resource_Federation_.28Alliance.29

[Adam Young]

On 11/06/2014 07:43 PM, Krieger, Orran wrote:
> What you know about this: https://wiki.openstack.org/wiki/Inter_Cloud_Resource_Federation#InterCloud_Resource_Federation_.28Alliance.29

Yeah, it came up at the Summit. It is mostly a service for
synchronizing in large scale deployements. I discussed it with Arvind
and it does not address the MOC use cases.

[Krieger, Orran]

thanks! How did the summit go? How about discussions on the critical specs for us?

[Adam Young]

On 11/11/2014 06:50 AM, Krieger, Orran wrote:
> thanks! How did the summit go? How about discussions on the critical specs for us?

It went well: lots of different directions, some MOC related, some less
so. I ran the distributed signing thing past a few people, and they all
seemed to get it, but it wasn't a pressing priority: if MOC developers
make it happen, I think it will get in.


Using it on the message broker was a matter of some concern; signing
every message might be too expensive. One option that we came up with
was to have a deliber message router for cross openstack messages;

example:
BU owns cinder, Harvard owns nova

Cinder client on a Harvard compute box needs to send to the BU cinder.
The message goes out unsigned. Then, a message listener picks it off
the message bus, signes it, and posts it to the MOC message bus. BU
client on the MOC messsage bus picks up the message, verifies the
signatur, and posts it to the BU message bus. Might be a simpler
integration point.


There was a lot of discussion about policy, and there was concern that
the two Keystone servers would need to keep Role definitions in sync.
It might be better if we always mapped a token at the Keystone server
level to make sure the roles reflect what each organization defines them
to be.

[Brent Holden]

I thought that the cascading OpenStack talk would have been more similar to MOC. Similar but different in that it's essentially one set of OpenStack endpoints that proxy to other endpoints that its aware of. It doesn't necessarily solve the interaction issues by allowing services interaction amongst multiple regions, but I thought you guys might be interested in it:

https://wiki.openstack.org/wiki/OpenStack_cascading_solution


-brent

--
Brent Holden, RHC{E,{D,S}S,{V,}A}
Chief Field Architect, East | Red Hat Inc.

Mobile: +1 (617) 823-7849
Email: br...@redhat.com