<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>