Open Stack

On 05/23/2015 02:50 PM, Tim Bell wrote:
> Joe,
>
> Thanks for the notes.
>
> We had a productive discussion with the Glance folk on how to share 
> images across clouds 
> (https://libertydesignsummit.sched.org/event/6b4a5dbd177cde2aad7a9927a82534d0#.VWDLPpOqqko) 
> and we’ll be working on that spec.
>
> We also had some forward looking discussions with the Keystone team on 
> how to manage multi-cloud nested projects.
>
> As joe said, Federated identity is needed but giving users a 
> transparent exprience will take much, much more.
>
> Are there blueprints created for this gap ?
I don't think so, as they really are cross-project blueprints.

I  was thinking that there needs to be an owner, and the down in the big 
tent is something like this:

Ceilometer is responsible for responding to events and kicking off workflows

Mistral is responsible for defining workflows.

While neither should be essential, or required, we should have a 
big-tent-only solution that people can use for reference.

Keysteon can provide the "user first seen" event
We need a time out for "user not seen since X"  to archive their work
We then need a "Delete all resources"  at a later date.
If a project is deliberately deleted, we need to catch and clean up 
those events as well.

I suspect if we documented that much, we'd get most of the way home.



>
> Tim
>
> From: joe <joe at topjian.net <mailto:joe at topjian.net>>
> Date: Friday 22 May 2015 23:26
> To: openstack-operators <openstack-operators at lists.openstack.org 
> <mailto:openstack-operators at lists.openstack.org>>
> Subject: [Openstack-operators] Ops Keystone / Federation Session
>
> Hello,
>
> Better late than never, here's a summary of the Ops Keystone / 
> Federation Session from this past Tuesday:
>
> First, I want to thank everyone from the Keystone team for attending 
> the session -- it was very cool to have you guys on-hand to directly 
> answer questions and give input and insight into the various items 
> being discussed.
>
> This was the first time we had a discussion session dedicated to this 
> topic and we could have easily spent entire sessions on each of the 
> main items listed in the Etherpad 
> <https://etherpad.openstack.org/p/YVR-ops-federation>. I think that 
> shows there's a lot to be discussed with regard to federated clouds.
>
> The biggest discussion item to come out of the session was that a 
> federated cloud means so much more than just "Keystone". Allocating, 
> restricting, automatic provisioning, reporting, and cleanup of any 
> type of OpenStack-enabled resource in a federated cloud are all areas 
> Operators are interested in learning about, but those areas are either 
> not well defined (perhaps because what works for one federation won't 
> work for another), are not possible to do yet, or are possible but 
> Operators aren't sure how to implement them.
>
> I encourage operators who are interested in this area to keep the 
> discussion going on this list by sharing your questions, concerns, and 
> trials. As well, I hope to see this topic in future Ops meetups and 
> tracks as a more formal way to touch base on this area.
>
> Etherpad: https://etherpad.openstack.org/p/YVR-ops-federation
>
> Thanks,
> Joe
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150525/905edbf4/attachment.html>