<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";
color:black;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";
color:black;}
span.hoenzb
{mso-style-name:hoenzb;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;
color:black;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";
color:black;}
span.EmailStyle22
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body bgcolor="white" lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Do we really want swift to make ACL decision based on an attribute which may or may not be there( since it is optional)?
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Thanks<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Haneef<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext"> Adam Young [mailto:ayoung@redhat.com]
<br>
<b>Sent:</b> Friday, February 01, 2013 12:47 PM<br>
<b>To:</b> openstack-dev@lists.openstack.org<br>
<b>Subject:</b> Re: [openstack-dev] [swift] [keystone] Keystone v3 API domains in Swift<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On 02/01/2013 01:27 PM, Dolph Mathews wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">It's not; we dropped it from the list of required attributes, but you can still provide one.<o:p></o:p></p>
</div>
</blockquote>
<p class="MsoNormal">According to GYee's latest submission, it would be in <br>
<br>
extra:{email:address}<br>
<br>
But we haven;t yet nailed down that proposal<br>
<br>
<br>
<br>
<br>
<o:p></o:p></p>
<div>
<p class="MsoNormal"><br clear="all">
<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">-Dolph<o:p></o:p></p>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Fri, Feb 1, 2013 at 11:56 AM, Ali, Haneef <<a href="mailto:haneef.ali@hp.com" target="_blank">haneef.ali@hp.com</a>> wrote:<o:p></o:p></p>
<p class="MsoNormal">Are you sure that token contains email-address? I don't see that as required field in user creation in v3.<br>
<br>
Thanks<br>
<span class="hoenzb"><span style="color:#888888">Haneef</span></span><o:p></o:p></p>
<div>
<p class="MsoNormal"><br>
-----Original Message-----<br>
From: David Chadwick [mailto:<a href="mailto:d.w.chadwick@kent.ac.uk">d.w.chadwick@kent.ac.uk</a>]<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">Sent: Friday, February 01, 2013 3:06 AM<br>
To: OpenStack Development Mailing List<br>
Subject: Re: [openstack-dev] [swift] [keystone] Keystone v3 API domains in Swift<o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal">Since the token contains the email address of the user, isnt it possible to use this in the ACL?<br>
<br>
regards<br>
<br>
David<br>
<br>
On 23/01/2013 10:23, Alexandra Shulman-Peleg wrote:<br>
> Hi,<br>
><br>
> I would like to get back to this discussion and specify the exact<br>
> syntax of ACLs that can be used when removing the global uniqueness<br>
> constraint on user names. I wander whether we really need to prefix<br>
> both the project_name and the username with the domain id? Especially,<br>
> since on ACLs we mainly need to properly identify the user and not the project.<br>
> So the notion of a project may not be required in this context? For<br>
> example, in NFSv4 ACLs (also adopted by CDMI) users are identified by<br>
> username@domain. So I wander whether on ACLs, in V3 we can simply<br>
> switch from tenant_id:username to domain_id:username? This seems to<br>
> fulfill the identification requirements and will give a very simple<br>
> solution for the migration of existing v2 customers to private domains<br>
> in V3 - assigning the new domain_id to match the old tenant_id will<br>
> allow preserving all of the stored containers without the need to<br>
> modify the containers' meta data.<br>
><br>
> Best Regards,<br>
> Alex.<br>
><br>
><br>
><br>
> From: "Yee, Guang" <<a href="mailto:guang.yee@hp.com">guang.yee@hp.com</a>><br>
> To: OpenStack Development Mailing List<br>
> <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>>,<br>
> Date: 11/01/2013 10:31 PM<br>
> Subject: Re: [openstack-dev] [swift] [keystone] Keystone v3 API<br>
> domains in Swift<br>
> ----------------------------------------------------------------------<br>
> --<br>
><br>
><br>
><br>
> As long as Swift URL stay the same we should be OK. Frankly, there<br>
> aren't any strong arguments for changing it at this point. Whenever we<br>
> remove the globally uniqueness constraint on names, new Swift ACLs<br>
> probably will need to switch over to using namespacing.<br>
><br>
> domain_name.project_name:domain_name.username<br>
><br>
> something like that. Existing Swift ACLs should work fine since if the<br>
> given domain is the default (migrated) system domain, auth_token<br>
> middleware should not set the domains headers.<br>
><br>
><br>
> Guang<br>
><br>
><br>
> -----Original Message-----<br>
> From: David Chadwick [mailto:<a href="mailto:d.w.chadwick@kent.ac.uk">d.w.chadwick@kent.ac.uk</a>]<br>
> Sent: Friday, January 11, 2013 8:36 AM<br>
> To: OpenStack Development Mailing List<br>
> Subject: Re: [openstack-dev] [swift] [keystone] Keystone v3 API<br>
> domains in Swift<br>
><br>
> Hi Chuck<br>
><br>
> On 11/01/2013 15:59, Chuck Thier wrote:<br>
> > The Tenant_ID is in the URL<br>
> > (<a href="https://">https://</a>{SWIFT_IP}/v1/AUTH_{TENANT_ID}/{CONTAINER}/{OBJECT})<br>
> ><br>
> > I think we have beaten this part to death a bit now, as we seem to<br>
> all > agree that we can continue this pattern with the V3 API. The<br>
> one > concern that I still have is how the ACLs will work, and<br>
> weather or > not that will need to change.<br>
> ><br>
> > I'm also curious how the Keystone V3 API will work alongside V2 apis.<br>
><br>
> My opinion (only, I dont speak for anyone else) is as follows:<br>
><br>
> 1. A v2 API system has no problems as it is working OK today 2. A v3<br>
> API system only, with domains added, should work OK tomorrow otherwise<br>
> the v3 API has problems 3. So the main point as you say is how do v2<br>
> and v3 systems interwork. I suggest there is an intercept module, say<br>
> in the Keystone pipeline, that knows it is operating in a v2/v3<br>
> environment, and when it receives a v2 request already containing a<br>
> tenant_ID it knows it will comprise domain:project and it can unpack<br>
> it, and give the separate elements to the rest of the V3 code for<br>
> processing as in a v3 system. When the intercept module receives a v2<br>
> request that needs a tenant ID returning to it, it will encode up the<br>
> domain and project as a tenant ID, and return this to the v2 client.<br>
> The v2 client will be blissfully unaware that what it thinks is a<br>
> tenant ID is actually a combination of domain and project.<br>
><br>
> regards<br>
><br>
> david<br>
><br>
><br>
><br>
> ><br>
> > --<br>
> > Chuck<br>
> ><br>
> > On Thu, Jan 10, 2013 at 4:16 AM, David Chadwick<br>
> <<a href="mailto:d.w.chadwick@kent.ac.uk">d.w.chadwick@kent.ac.uk</a>><br>
> wrote:<br>
> >> You have to ask, where does the Swift client get the tenant_Id from?<br>
> Isnt<br>
> it<br>
> >> Keystone? So if Keystone returns project_ID:tenant_Id to swift as<br>
> the >> project_id string, then Swift can continue to use this as if<br>
> nothing has >> changed. Its just a string whose content has no<br>
> meaning to Swift, but whose >> content does have meaning to Keystone.<br>
> The Swift policy simply needs to >> change the value of the tenant_id<br>
> in its policy to the new value and it >> should work the same >> >><br>
> regards >> >> David >> >> >> On 09/01/2013 20:21, heckj wrote:<br>
> >>><br>
> >>> Given that domains are a segmentation of projects/tenants, then I<br>
> wouldn't >>> expect to want to change it from a project_id<br>
> representation to anything >>> else.<br>
> >>><br>
> >>> -joe<br>
> >>><br>
> >>> On Jan 9, 2013, at 12:13 PM, Chuck Thier <<a href="mailto:cthier@gmail.com">cthier@gmail.com</a>> wrote:<br>
> >>>><br>
> >>>> Things are always easy, until you start thinking about backwards<br>
> >>>> compatibility. The storage urls for swift with keystone are<br>
> currently >>>> keyed off of the tenant_id (soon to be project_id), so<br>
> you end up with >>>> an endpoint url that looks something like >>>><br>
> <a href="http://">http://</a>{SWIFT_IP}/v1/AUTH_{TENANT_ID} if you change that by adding<br>
> >>>> the domain, then you break any current users in your system, and<br>
> you >>>> can't use v2 and v3 auth contracts simultaneously.<br>
> >>>><br>
> >>>> --<br>
> >>>> Chuck<br>
> >>>><br>
> >>>> On Wed, Jan 9, 2013 at 1:37 PM, David Chadwick<br>
> <<a href="mailto:d.w.chadwick@kent.ac.uk">d.w.chadwick@kent.ac.uk</a>> >>>> wrote:<br>
> >>>>><br>
> >>>>> I would have thought that the solution is conceptually rather<br>
> >>>>> straightforward. If domains can have their own project names and<br>
> >>>>> usernames, >>>>> then you prefix the names with the domain ID<br>
> or domain name to make them >>>>> globally unique again.<br>
> >>>>><br>
> >>>>> regards<br>
> >>>>><br>
> >>>>> David<br>
> >>>>><br>
> >>>>><br>
> >>>>><br>
> >>>>> On 09/01/2013 19:14, Yee, Guang wrote:<br>
> >>>>>><br>
> >>>>>><br>
> >>>>>> Yes. Swift ACLs <tenant_id>:<user_name>,<br>
> <tenant_id>:<user_name>, and >>>>>> *:<user_name> will be impacted if<br>
> project (formely tenant) name and >>>>>> user >>>>>> name are no<br>
> longer globally unique. We'll need to figure out a >>>>>> migration<br>
> >>>>>> path before relaxing that constraint.<br>
> >>>>>><br>
> >>>>>><br>
> >>>>>> Guang<br>
> >>>>>><br>
> >>>>>><br>
> >>>>>> -----Original Message-----<br>
> >>>>>> From: Chuck Thier [mailto:<a href="mailto:cthier@gmail.com">cthier@gmail.com</a>] >>>>>> Sent:<br>
> Wednesday, January 09, 2013 10:48 AM >>>>>> To: OpenStack Development<br>
> Mailing List >>>>>> Subject: Re: [openstack-dev] [swift] [keystone]<br>
> Keystone v3 API domains >>>>>> in >>>>>> Swift >>>>>> >>>>>> Se<br>
> responses inline:<br>
> >>>>>><br>
> >>>>>> On Wed, Jan 9, 2013 at 4:01 AM, Henry Nash<br>
> <<a href="mailto:henryn@linux.vnet.ibm.com">henryn@linux.vnet.ibm.com</a>> >>>>>> wrote:<br>
> >>>>>>><br>
> >>>>>>><br>
> >>>>>>> So there are a couple of issues intertwined in this thread:<br>
> >>>>>>><br>
> >>>>>>> 1) Uniqueness of identifiers in Swift given the keystone<br>
> Identity v3 >>>>>>> api.<br>
> >>>>>>> This is the issue of whether Swift uses tenant names (now<br>
> called >>>>>>> project >>>>>>> names) at all to uniquely identify<br>
> any objects - if it did, then it >>>>>>> would >>>>>>> need to also<br>
> consider storing a domain name or id. From the >>>>>>> discussion,<br>
> >>>>>> >>>>>> >>>>>> it >>>>>>> >>>>>>> >>>>>>> sounds like<br>
> tenant/project ID is used instead, which (from a >>>>>>> uniqueness<br>
> >>>>>>> point of view) is fine. A separate issue exists needs to be<br>
> discussed >>>>>>> around swift ACLs and whether username potentially<br>
> becoming unique >>>>>>> only >>>>>>> within a domain will have an<br>
> impact.<br>
> >>>>>>><br>
> >>>>>><br>
> >>>>>> For AuthN, you are correct, in that it only relies on<br>
> tenant/project >>>>>> ID. So, nothing has to be changed from that<br>
> perspective. AuthZ is a >>>>>> little more tricky. For ACLs with<br>
> keystone, they are set as >>>>>> TENANT:USER in any of the following<br>
> patterns:<br>
> >>>>>><br>
> >>>>>> *:user_name - that user from any tenant has access >>>>>><br>
> tenant_id:user_name - that user from that tenant id has access >>>>>><br>
> tenant_name:user_name - that user from that tenant name has access<br>
> >>>>>> >>>>>> If project_name will not be unique in v3, then the<br>
> >>>>>> tenant_name:user_name format may have to be deprecated.<br>
> >>>>>><br>
> >>>>>> I would be interested to hear from providers that are using<br>
> keystone >>>>>> with swift and hear which of the above use cases they are using.<br>
> >>>>>><br>
> >>>>>><br>
> >>>>>>> 2) Given that keystone identity v3 domains are likely to be<br>
> usually >>>>>>> used >>>>>> >>>>>> >>>>>> to >>>>>>> >>>>>>><br>
> >>>>>>> represent an enterprise (or "account holder" in common cloud<br>
> >>>>>>> terminology) >>>>>>> and contain the collection of projects<br>
> owned by that enterprise, is it >>>>>>> important for Swift to have<br>
> that domain knowledge? Will there be >>>>>> >>>>>> >>>>>><br>
> operations >>>>>>> >>>>>>> >>>>>>> either within swift (or more<br>
> likely layered on top of swift) that need >>>>>> >>>>>> >>>>>> that<br>
> >>>>>>> >>>>>>> >>>>>>> information? E.g. How would someone layer a<br>
> billing engine on top of >>>>>> >>>>>> >>>>>> swift >>>>>>><br>
> >>>>>>> >>>>>>> that could collate all the swift containers that were<br>
> part of one >>>>>>> domain?<br>
> >>>>>>> Obviously that engine could call keystone with each<br>
> project_id in turn >>>>>>> and >>>>>>> find the domain_id.....but<br>
> that sounds pretty inefficient.<br>
> >>>>>>><br>
> >>>>>><br>
> >>>>>> As is, containers can already be collated for a given<br>
> tenant/project >>>>>> id. The containers for a domain is then an<br>
> aggregate of the project >>>>>> ids associated to that domain.<br>
> >>>>>><br>
> >>>>>> I think the default should be that domains are not mapped in swift.<br>
> I<br>
> >>>>>> believe that this will also be required to facilitate<br>
> backwards >>>>>> compatibility, which brings up another interesting<br>
> question -- Is >>>>>> there an expectation that people will be able<br>
> to run keystone auth >>>>>> v2.0 and v3.0 side by side?<br>
> >>>>>><br>
> >>>>>> --<br>
> >>>>>> Chuck<br>
> >>>>>><br>
> >>>>>> _______________________________________________<br>
> >>>>>> OpenStack-dev mailing list<br>
> >>>>>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a> >>>>>><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> >>>>>><br>
> >>>>>><br>
> >>>>>><br>
> >>>>>> _______________________________________________<br>
> >>>>>> OpenStack-dev mailing list<br>
> >>>>>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a> >>>>>><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> >>>>>><br>
> >>>>><br>
> >>>>> _______________________________________________<br>
> >>>>> OpenStack-dev mailing list<br>
> >>>>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a> >>>>><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> >>>><br>
> >>>><br>
> >>>> _______________________________________________<br>
> >>>> OpenStack-dev mailing list<br>
> >>>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a> >>>><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> >>><br>
> >>><br>
> >>><br>
> >>> _______________________________________________<br>
> >>> OpenStack-dev mailing list<br>
> >>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a> >>><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> >>><br>
> >><br>
> >> _______________________________________________<br>
> >> OpenStack-dev mailing list<br>
> >> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> >> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> ><br>
> > _______________________________________________<br>
> > OpenStack-dev mailing list<br>
> > <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> ><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> [attachment "smime.p7s" deleted by Alexandra Shulman-Peleg/Haifa/IBM]<br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><o:p></o:p></p>
</div>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal"><br>
<br>
<br>
<o:p></o:p></p>
<pre>_______________________________________________<o:p></o:p></pre>
<pre>OpenStack-dev mailing list<o:p></o:p></pre>
<pre><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><o:p></o:p></pre>
<pre><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><o:p></o:p></pre>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</body>
</html>