<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 05/23/2015 02:50 PM, Tim Bell wrote:<br>
</div>
<blockquote cite="mid:D1869778.327BE%25tim.bell@cern.ch" type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<div>Joe,</div>
<div><br>
</div>
<div>Thanks for the notes.</div>
<div><br>
</div>
<div>We had a productive discussion with the Glance folk on how to
share images across clouds (<a moz-do-not-send="true"
href="https://libertydesignsummit.sched.org/event/6b4a5dbd177cde2aad7a9927a82534d0#.VWDLPpOqqko">https://libertydesignsummit.sched.org/event/6b4a5dbd177cde2aad7a9927a82534d0#.VWDLPpOqqko</a>)
and we’ll be working on that spec.</div>
<div><br>
</div>
<div>We also had some forward looking discussions with the
Keystone team on how to manage multi-cloud nested projects. </div>
<div><br>
</div>
<div>As joe said, Federated identity is needed but giving users a
transparent exprience will take much, much more. </div>
<div><br>
</div>
<div>Are there blueprints created for this gap ?</div>
</blockquote>
I don't think so, as they really are cross-project blueprints.<br>
<br>
I was thinking that there needs to be an owner, and the down in the
big tent is something like this:<br>
<br>
Ceilometer is responsible for responding to events and kicking off
workflows<br>
<br>
Mistral is responsible for defining workflows.<br>
<br>
While neither should be essential, or required, we should have a
big-tent-only solution that people can use for reference.<br>
<br>
Keysteon can provide the "user first seen" event<br>
We need a time out for "user not seen since X" to archive their
work<br>
We then need a "Delete all resources" at a later date.<br>
If a project is deliberately deleted, we need to catch and clean up
those events as well.<br>
<br>
I suspect if we documented that much, we'd get most of the way home.<br>
<br>
<br>
<br>
<blockquote cite="mid:D1869778.327BE%25tim.bell@cern.ch" type="cite">
<div><br>
</div>
<div>Tim</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt;
text-align:left; color:black; BORDER-BOTTOM: medium none;
BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT:
0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid;
BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span>joe <<a
moz-do-not-send="true" href="mailto:joe@topjian.net">joe@topjian.net</a>><br>
<span style="font-weight:bold">Date: </span>Friday 22 May
2015 23:26<br>
<span style="font-weight:bold">To: </span>openstack-operators
<<a moz-do-not-send="true"
href="mailto:openstack-operators@lists.openstack.org">openstack-operators@lists.openstack.org</a>><br>
<span style="font-weight:bold">Subject: </span>[Openstack-operators]
Ops Keystone / Federation Session<br>
</div>
<div><br>
</div>
<div>
<div>
<div dir="ltr">Hello,
<div><br>
</div>
<div>Better late than never, here's a summary of the Ops
Keystone / Federation Session from this past Tuesday:</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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
<a moz-do-not-send="true"
href="https://etherpad.openstack.org/p/YVR-ops-federation">Etherpad</a>.
I think that shows there's a lot to be discussed with
regard to federated clouds.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Etherpad: <a moz-do-not-send="true"
href="https://etherpad.openstack.org/p/YVR-ops-federation">https://etherpad.openstack.org/p/YVR-ops-federation</a></div>
<div><br>
</div>
<div>Thanks,</div>
<div>Joe</div>
</div>
</div>
</div>
</span>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OpenStack-operators mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a>
</pre>
</blockquote>
<br>
</body>
</html>