<div dir="ltr">It's not; we dropped it from the list of required attributes, but you can still provide one.</div><div class="gmail_extra"><br clear="all"><div><div><br></div>-Dolph</div>
<br><br><div class="gmail_quote">On Fri, Feb 1, 2013 at 11:56 AM, Ali, Haneef <span dir="ltr"><<a href="mailto:haneef.ali@hp.com" target="_blank">haneef.ali@hp.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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"><font color="#888888">Haneef<br>
</font></span><div class="im HOEnZb"><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>
</div><div class="im HOEnZb">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<br>
<br>
</div><div class="HOEnZb"><div class="h5">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>
> > (https://{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>
> http://{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><br>
</div></div></blockquote></div><br></div>