<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 12 (filtered medium)"><!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@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;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
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;}
tt
{mso-style-priority:99;
font-family:"Courier New";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:788162129;
mso-list-type:hybrid;
mso-list-template-ids:1972645444 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1
{mso-list-id:1565527101;
mso-list-type:hybrid;
mso-list-template-ids:1816539752 -1538256148 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l1:level1
{mso-level-start-at:10;
mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;
mso-fareast-font-family:Calibri;
mso-bidi-font-family:"Times New Roman";}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></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 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'>Swift ACLs currently can be specified as<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'><project/tenant ID>:<username><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><project/tenant name>:<username><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>*:<username><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'>IDs are always globally unique regardless. Names (username, project/tenant name, etc), on the other hand, are currently required to be globally unique. But there are attempts to relax the globally uniqueness on names constraint. The notion of private domain is one of them. I am still unclear on how private domains will impact the existing services.<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=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo2'><![if !supportLists]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span style='mso-list:Ignore'>1.<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>How does private domain work in conjunction with public domains? If I have a user jdoe in private domain XYZ and another jdoe in a public domain ABC, how does not affect the existing Swift ACLs? Seems to me, private domain or not, Swift ACL will have to change once we relax this constraint.<o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo2'><![if !supportLists]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span style='mso-list:Ignore'>2.<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>How does private domain affect middleware? Are we going to have a X-Domain-ID, X-Domin-Name, and X-Is-Private-Domain headers?<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'>I think we need a full impact assessment before moving forward with this.<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'>Guang<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'><o:p> </o:p></span></p><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"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Dolph Mathews [mailto:dolph.mathews@gmail.com] <br><b>Sent:</b> Wednesday, January 23, 2013 9:52 AM<br><b>To:</b> OpenStack Development Mailing List<br><b>Subject:</b> Re: [openstack-dev] [swift] [keystone] Keystone v3 API domains in Swift<o:p></o:p></span></p></div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>On the surface, this seems to be defeating the purpose of introducing domains in the first place (allowing domain administrators to manage isolated groups of users & projects). I'm not sure why you'd need to switch away from tenant_id/project_id.<o:p></o:p></p></div><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 Wed, Jan 23, 2013 at 4:23 AM, Alexandra Shulman-Peleg <<a href="mailto:SHULMANA@il.ibm.com" target="_blank">SHULMANA@il.ibm.com</a>> wrote:<o:p></o:p></p><p class=MsoNormal><span style='font-family:"Tahoma","sans-serif"'>Hi,</span> <br><br><span style='font-family:"Tahoma","sans-serif"'>I would like to get back to this discussion and specify the exact syntax of ACLs that can be used when removing the global uniqueness constraint on user names. I wander whether we really need to prefix both the project_name and the username with the domain id? Especially, since on ACLs we mainly need to properly identify the user and not the project. So the notion of a project may not be required in this context? For example, in NFSv4 ACLs (also adopted by CDMI) users are identified by username@domain. So I wander whether on ACLs, in V3 we can simply switch from tenant_id:username to domain_id:username? This seems to fulfill the identification requirements and will give a very simple solution for the migration of existing v2 customers to private domains in V3 – assigning the new domain_id to match the old tenant_id will allow preserving all of the stored containers without the need to modify the containers' meta data.</span> <br><br><span style='font-family:"Tahoma","sans-serif"'>Best Regards,</span> <br><span style='font-family:"Tahoma","sans-serif"'>Alex. </span><br><br><br><br><span style='font-size:7.5pt;font-family:"Arial","sans-serif";color:#5F5F5F'>From: </span><span style='font-size:7.5pt;font-family:"Arial","sans-serif"'>"Yee, Guang" <<a href="mailto:guang.yee@hp.com" target="_blank">guang.yee@hp.com</a>></span> <br><span style='font-size:7.5pt;font-family:"Arial","sans-serif";color:#5F5F5F'>To: </span><span style='font-size:7.5pt;font-family:"Arial","sans-serif"'>OpenStack Development Mailing List <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>>, </span><br><span style='font-size:7.5pt;font-family:"Arial","sans-serif";color:#5F5F5F'>Date: </span><span style='font-size:7.5pt;font-family:"Arial","sans-serif"'>11/01/2013 10:31 PM</span> <o:p></o:p></p><div><p class=MsoNormal><span style='font-size:7.5pt;font-family:"Arial","sans-serif";color:#5F5F5F'>Subject: </span><span style='font-size:7.5pt;font-family:"Arial","sans-serif"'>Re: [openstack-dev] [swift] [keystone] Keystone v3 API domains in Swift</span> <o:p></o:p></p></div><div class=MsoNormal align=center style='text-align:center'><hr size=3 width="100%" noshade style='color:#A0A0A0' align=center></div><div><div><p class=MsoNormal><br><br><br><tt><span style='font-size:10.0pt'>As long as Swift URL stay the same we should be OK. Frankly, there aren't</span></tt><span style='font-size:10.0pt;font-family:"Courier New"'><br><tt>any strong arguments for changing it at this point. Whenever we remove the</tt><br><tt>globally uniqueness constraint on names, new Swift ACLs probably will need</tt><br><tt>to switch over to using namespacing.</tt><br><br><tt>domain_name.project_name:domain_name.username</tt><br><br><tt>something like that. Existing Swift ACLs should work fine since if the given</tt><br><tt>domain is the default (migrated) system domain, auth_token middleware should</tt><br><tt>not set the domains headers.</tt><br><br><br><tt>Guang</tt><br><br><br><tt>-----Original Message-----</tt><br><tt>From: David Chadwick [</tt></span><a href="mailto:d.w.chadwick@kent.ac.uk" target="_blank"><tt><span style='font-size:10.0pt'>mailto:d.w.chadwick@kent.ac.uk</span></tt></a><tt><span style='font-size:10.0pt'>] </span></tt><span style='font-size:10.0pt;font-family:"Courier New"'><br><tt>Sent: Friday, January 11, 2013 8:36 AM</tt><br><tt>To: OpenStack Development Mailing List</tt><br><tt>Subject: Re: [openstack-dev] [swift] [keystone] Keystone v3 API domains in</tt><br><tt>Swift</tt><br><br><tt>Hi Chuck</tt><br><br><tt>On 11/01/2013 15:59, Chuck Thier wrote:</tt><br><tt>> The Tenant_ID is in the URL</tt><br><tt>> (https://{SWIFT_IP}/v1/AUTH_{TENANT_ID}/{CONTAINER}/{OBJECT})</tt><br><tt>></tt><br><tt>> I think we have beaten this part to death a bit now, as we seem to all</tt><br><tt>> agree that we can continue this pattern with the V3 API. The one</tt><br><tt>> concern that I still have is how the ACLs will work, and weather or</tt><br><tt>> not that will need to change.</tt><br><tt>></tt><br><tt>> I'm also curious how the Keystone V3 API will work alongside V2 apis.</tt><br><br><tt>My opinion (only, I dont speak for anyone else) is as follows:</tt><br><br><tt>1. A v2 API system has no problems as it is working OK today</tt><br><tt>2. A v3 API system only, with domains added, should work OK tomorrow </tt><br><tt>otherwise the v3 API has problems</tt><br><tt>3. So the main point as you say is how do v2 and v3 systems interwork. I </tt><br><tt>suggest there is an intercept module, say in the Keystone pipeline, that </tt><br><tt>knows it is operating in a v2/v3 environment, and when it receives a v2 </tt><br><tt>request already containing a tenant_ID it knows it will comprise </tt><br><tt>domain:project and it can unpack it, and give the separate elements to </tt><br><tt>the rest of the V3 code for processing as in a v3 system. When the </tt><br><tt>intercept module receives a v2 request that needs a tenant ID returning </tt><br><tt>to it, it will encode up the domain and project as a tenant ID, and </tt><br><tt>return this to the v2 client. The v2 client will be blissfully unaware </tt><br><tt>that what it thinks is a tenant ID is actually a combination of domain </tt><br><tt>and project.</tt><br><br><tt>regards</tt><br><br><tt>david</tt><br><br><br><br><tt>></tt><br><tt>> --</tt><br><tt>> Chuck</tt><br><tt>></tt><br><tt>> On Thu, Jan 10, 2013 at 4:16 AM, David Chadwick <<a href="mailto:d.w.chadwick@kent.ac.uk" target="_blank">d.w.chadwick@kent.ac.uk</a>></tt><br><tt>wrote:</tt><br><tt>>> You have to ask, where does the Swift client get the tenant_Id from? Isnt</tt><br><tt>it</tt><br><tt>>> Keystone? So if Keystone returns project_ID:tenant_Id to swift as the</tt><br><tt>>> project_id string, then Swift can continue to use this as if nothing has</tt><br><tt>>> changed. Its just a string whose content has no meaning to Swift, but</tt><br><tt>whose</tt><br><tt>>> content does have meaning to Keystone. The Swift policy simply needs to</tt><br><tt>>> change the value of the tenant_id in its policy to the new value and it</tt><br><tt>>> should work the same</tt><br><tt>>></tt><br><tt>>> regards</tt><br><tt>>></tt><br><tt>>> David</tt><br><tt>>></tt><br><tt>>></tt><br><tt>>> On 09/01/2013 20:21, heckj wrote:</tt><br><tt>>>></tt><br><tt>>>> Given that domains are a segmentation of projects/tenants, then I</tt><br><tt>wouldn't</tt><br><tt>>>> expect to want to change it from a project_id representation to anything</tt><br><tt>>>> else.</tt><br><tt>>>></tt><br><tt>>>> -joe</tt><br><tt>>>></tt><br><tt>>>> On Jan 9, 2013, at 12:13 PM, Chuck Thier <<a href="mailto:cthier@gmail.com" target="_blank">cthier@gmail.com</a>> wrote:</tt><br><tt>>>>></tt><br><tt>>>>> Things are always easy, until you start thinking about backwards</tt><br><tt>>>>> compatibility. The storage urls for swift with keystone are currently</tt><br><tt>>>>> keyed off of the tenant_id (soon to be project_id), so you end up with</tt><br><tt>>>>> an endpoint url that looks something like</tt><br><tt>>>>> http://{SWIFT_IP}/v1/AUTH_{TENANT_ID} if you change that by adding</tt><br><tt>>>>> the domain, then you break any current users in your system, and you</tt><br><tt>>>>> can't use v2 and v3 auth contracts simultaneously.</tt><br><tt>>>>></tt><br><tt>>>>> --</tt><br><tt>>>>> Chuck</tt><br><tt>>>>></tt><br><tt>>>>> On Wed, Jan 9, 2013 at 1:37 PM, David Chadwick</tt><br><tt><<a href="mailto:d.w.chadwick@kent.ac.uk" target="_blank">d.w.chadwick@kent.ac.uk</a>></tt><br><tt>>>>> wrote:</tt><br><tt>>>>>></tt><br><tt>>>>>> I would have thought that the solution is conceptually rather</tt><br><tt>>>>>> straightforward. If domains can have their own project names and</tt><br><tt>>>>>> usernames,</tt><br><tt>>>>>> then you prefix the names with the domain ID or domain name to make</tt><br><tt>them</tt><br><tt>>>>>> globally unique again.</tt><br><tt>>>>>></tt><br><tt>>>>>> regards</tt><br><tt>>>>>></tt><br><tt>>>>>> David</tt><br><tt>>>>>></tt><br><tt>>>>>></tt><br><tt>>>>>></tt><br><tt>>>>>> On 09/01/2013 19:14, Yee, Guang wrote:</tt><br><tt>>>>>>></tt><br><tt>>>>>>></tt><br><tt>>>>>>> Yes. Swift ACLs <tenant_id>:<user_name>, <tenant_id>:<user_name>, and</tt><br><tt>>>>>>> *:<user_name> will be impacted if project (formely tenant) name and</tt><br><tt>>>>>>> user</tt><br><tt>>>>>>> name are no longer globally unique. We'll need to figure out a</tt><br><tt>>>>>>> migration</tt><br><tt>>>>>>> path before relaxing that constraint.</tt><br><tt>>>>>>></tt><br><tt>>>>>>></tt><br><tt>>>>>>> Guang</tt><br><tt>>>>>>></tt><br><tt>>>>>>></tt><br><tt>>>>>>> -----Original Message-----</tt><br><tt>>>>>>> From: Chuck Thier [</tt></span><a href="mailto:cthier@gmail.com" target="_blank"><tt><span style='font-size:10.0pt'>mailto:cthier@gmail.com</span></tt></a><tt><span style='font-size:10.0pt'>]</span></tt><span style='font-size:10.0pt;font-family:"Courier New"'><br><tt>>>>>>> Sent: Wednesday, January 09, 2013 10:48 AM</tt><br><tt>>>>>>> To: OpenStack Development Mailing List</tt><br><tt>>>>>>> Subject: Re: [openstack-dev] [swift] [keystone] Keystone v3 API</tt><br><tt>domains</tt><br><tt>>>>>>> in</tt><br><tt>>>>>>> Swift</tt><br><tt>>>>>>></tt><br><tt>>>>>>> Se responses inline:</tt><br><tt>>>>>>></tt><br><tt>>>>>>> On Wed, Jan 9, 2013 at 4:01 AM, Henry Nash</tt><br><tt><<a href="mailto:henryn@linux.vnet.ibm.com" target="_blank">henryn@linux.vnet.ibm.com</a>></tt><br><tt>>>>>>> wrote:</tt><br><tt>>>>>>>></tt><br><tt>>>>>>>></tt><br><tt>>>>>>>> So there are a couple of issues intertwined in this thread:</tt><br><tt>>>>>>>></tt><br><tt>>>>>>>> 1) Uniqueness of identifiers in Swift given the keystone Identity v3</tt><br><tt>>>>>>>> api.</tt><br><tt>>>>>>>> This is the issue of whether Swift uses tenant names (now called</tt><br><tt>>>>>>>> project</tt><br><tt>>>>>>>> names) at all to uniquely identify any objects - if it did, then it</tt><br><tt>>>>>>>> would</tt><br><tt>>>>>>>> need to also consider storing a domain name or id. From the</tt><br><tt>>>>>>>> discussion,</tt><br><tt>>>>>>></tt><br><tt>>>>>>></tt><br><tt>>>>>>> it</tt><br><tt>>>>>>>></tt><br><tt>>>>>>>></tt><br><tt>>>>>>>> sounds like tenant/project ID is used instead, which (from a</tt><br><tt>>>>>>>> uniqueness</tt><br><tt>>>>>>>> point of view) is fine. A separate issue exists needs to be</tt><br><tt>discussed</tt><br><tt>>>>>>>> around swift ACLs and whether username potentially becoming unique</tt><br><tt>>>>>>>> only</tt><br><tt>>>>>>>> within a domain will have an impact.</tt><br><tt>>>>>>>></tt><br><tt>>>>>>></tt><br><tt>>>>>>> For AuthN, you are correct, in that it only relies on tenant/project</tt><br><tt>>>>>>> ID. So, nothing has to be changed from that perspective. AuthZ is a</tt><br><tt>>>>>>> little more tricky. For ACLs with keystone, they are set as</tt><br><tt>>>>>>> TENANT:USER in any of the following patterns:</tt><br><tt>>>>>>></tt><br><tt>>>>>>> *:user_name - that user from any tenant has access</tt><br><tt>>>>>>> tenant_id:user_name - that user from that tenant id has access</tt><br><tt>>>>>>> tenant_name:user_name - that user from that tenant name has access</tt><br><tt>>>>>>></tt><br><tt>>>>>>> If project_name will not be unique in v3, then the</tt><br><tt>>>>>>> tenant_name:user_name format may have to be deprecated.</tt><br><tt>>>>>>></tt><br><tt>>>>>>> I would be interested to hear from providers that are using keystone</tt><br><tt>>>>>>> with swift and hear which of the above use cases they are using.</tt><br><tt>>>>>>></tt><br><tt>>>>>>></tt><br><tt>>>>>>>> 2) Given that keystone identity v3 domains are likely to be usually</tt><br><tt>>>>>>>> used</tt><br><tt>>>>>>></tt><br><tt>>>>>>></tt><br><tt>>>>>>> to</tt><br><tt>>>>>>>></tt><br><tt>>>>>>>></tt><br><tt>>>>>>>> represent an enterprise (or "account holder" in common cloud</tt><br><tt>>>>>>>> terminology)</tt><br><tt>>>>>>>> and contain the collection of projects owned by that enterprise, is</tt><br><tt>it</tt><br><tt>>>>>>>> important for Swift to have that domain knowledge? Will there be</tt><br><tt>>>>>>></tt><br><tt>>>>>>></tt><br><tt>>>>>>> operations</tt><br><tt>>>>>>>></tt><br><tt>>>>>>>></tt><br><tt>>>>>>>> either within swift (or more likely layered on top of swift) that</tt><br><tt>need</tt><br><tt>>>>>>></tt><br><tt>>>>>>></tt><br><tt>>>>>>> that</tt><br><tt>>>>>>>></tt><br><tt>>>>>>>></tt><br><tt>>>>>>>> information? E.g. How would someone layer a billing engine on top</tt><br><tt>of</tt><br><tt>>>>>>></tt><br><tt>>>>>>></tt><br><tt>>>>>>> swift</tt><br><tt>>>>>>>></tt><br><tt>>>>>>>></tt><br><tt>>>>>>>> that could collate all the swift containers that were part of one</tt><br><tt>>>>>>>> domain?</tt><br><tt>>>>>>>> Obviously that engine could call keystone with each project_id in</tt><br><tt>turn</tt><br><tt>>>>>>>> and</tt><br><tt>>>>>>>> find the domain_id.....but that sounds pretty inefficient.</tt><br><tt>>>>>>>></tt><br><tt>>>>>>></tt><br><tt>>>>>>> As is, containers can already be collated for a given tenant/project</tt><br><tt>>>>>>> id. The containers for a domain is then an aggregate of the project</tt><br><tt>>>>>>> ids associated to that domain.</tt><br><tt>>>>>>></tt><br><tt>>>>>>> I think the default should be that domains are not mapped in swift.</tt><br><tt>I</tt><br><tt>>>>>>> believe that this will also be required to facilitate backwards</tt><br><tt>>>>>>> compatibility, which brings up another interesting question -- Is</tt><br><tt>>>>>>> there an expectation that people will be able to run keystone auth</tt><br><tt>>>>>>> v2.0 and v3.0 side by side?</tt><br><tt>>>>>>></tt><br><tt>>>>>>> --</tt><br><tt>>>>>>> Chuck</tt><br><tt>>>>>>></tt><br><tt>>>>>>> _______________________________________________</tt><br><tt>>>>>>> OpenStack-dev mailing list</tt><br><tt>>>>>>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a></tt><br><tt>>>>>>> </tt></span><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank"><tt><span style='font-size:10.0pt'>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</span></tt></a><span style='font-size:10.0pt;font-family:"Courier New"'><br><tt>>>>>>></tt><br><tt>>>>>>></tt><br><tt>>>>>>></tt><br><tt>>>>>>> _______________________________________________</tt><br><tt>>>>>>> OpenStack-dev mailing list</tt><br><tt>>>>>>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a></tt><br><tt>>>>>>> </tt></span><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank"><tt><span style='font-size:10.0pt'>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</span></tt></a><span style='font-size:10.0pt;font-family:"Courier New"'><br><tt>>>>>>></tt><br><tt>>>>>></tt><br><tt>>>>>> _______________________________________________</tt><br><tt>>>>>> OpenStack-dev mailing list</tt><br><tt>>>>>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a></tt><br><tt>>>>>> </tt></span><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank"><tt><span style='font-size:10.0pt'>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</span></tt></a><span style='font-size:10.0pt;font-family:"Courier New"'><br><tt>>>>></tt><br><tt>>>>></tt><br><tt>>>>> _______________________________________________</tt><br><tt>>>>> OpenStack-dev mailing list</tt><br><tt>>>>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a></tt><br><tt>>>>> </tt></span><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank"><tt><span style='font-size:10.0pt'>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</span></tt></a><span style='font-size:10.0pt;font-family:"Courier New"'><br><tt>>>></tt><br><tt>>>></tt><br><tt>>>></tt><br><tt>>>> _______________________________________________</tt><br><tt>>>> OpenStack-dev mailing list</tt><br><tt>>>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a></tt><br><tt>>>> </tt></span><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank"><tt><span style='font-size:10.0pt'>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</span></tt></a><span style='font-size:10.0pt;font-family:"Courier New"'><br><tt>>>></tt><br><tt>>></tt><br><tt>>> _______________________________________________</tt><br><tt>>> OpenStack-dev mailing list</tt><br><tt>>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a></tt><br><tt>>> </tt></span><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank"><tt><span style='font-size:10.0pt'>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</span></tt></a><span style='font-size:10.0pt;font-family:"Courier New"'><br><tt>></tt><br><tt>> _______________________________________________</tt><br><tt>> OpenStack-dev mailing list</tt><br><tt>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a></tt><br><tt>> </tt></span><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank"><tt><span style='font-size:10.0pt'>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</span></tt></a><span style='font-size:10.0pt;font-family:"Courier New"'><br><tt>></tt><br><br><tt>_______________________________________________</tt><br><tt>OpenStack-dev mailing list</tt><br><tt><a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a></tt><br></span><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank"><tt><span style='font-size:10.0pt'>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</span></tt></a><o:p></o:p></p></div></div><p class=MsoNormal style='margin-bottom:12.0pt'><span style='font-size:10.0pt;font-family:"Courier New"'><br><tt>[attachment "smime.p7s" deleted by Alexandra Shulman-Peleg/Haifa/IBM] _______________________________________________</tt><br><tt>OpenStack-dev mailing list</tt><br><tt><a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a></tt><br></span><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank"><tt><span style='font-size:10.0pt'>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</span></tt></a><span style='font-size:10.0pt;font-family:"Courier New"'><br></span><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><p class=MsoNormal><o:p> </o:p></p></div></div></body></html>