<font size=2 face="Tahoma">Hi,</font>
<br>
<br><font size=2 face="Tahoma">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.</font>
<br>
<br><font size=2 face="Tahoma">Best Regards,</font>
<br><font size=2 face="Tahoma">Alex.   </font>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:      
 </font><font size=1 face="sans-serif">"Yee, Guang"
<guang.yee@hp.com></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:      
 </font><font size=1 face="sans-serif">OpenStack Development
Mailing List <openstack-dev@lists.openstack.org>, </font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:      
 </font><font size=1 face="sans-serif">11/01/2013 10:31 PM</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:    
   </font><font size=1 face="sans-serif">Re: [openstack-dev]
[swift] [keystone] Keystone v3 API domains in Swift</font>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>As long as Swift URL stay the same we should be OK.
Frankly, there aren't<br>
any strong arguments for changing it at this point. Whenever we remove
the<br>
globally uniqueness constraint on names, new Swift ACLs probably will need<br>
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
given<br>
domain is the default (migrated) system domain, auth_token middleware should<br>
not set the domains headers.<br>
<br>
<br>
Guang<br>
<br>
<br>
-----Original Message-----<br>
From: David Chadwick [</font></tt><a href=mailto:d.w.chadwick@kent.ac.uk><tt><font size=2>mailto:d.w.chadwick@kent.ac.uk</font></tt></a><tt><font size=2>]
<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 domains
in<br>
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
all<br>
> agree that we can continue this pattern with the V3 API.  The
one<br>
> concern that I still have is how the ACLs will work, and weather or<br>
> 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<br>
2. A v3 API system only, with domains added, should work OK tomorrow <br>
otherwise the v3 API has problems<br>
3. So the main point as you say is how do v2 and v3 systems interwork.
I <br>
suggest there is an intercept module, say in the Keystone pipeline, that
<br>
knows it is operating in a v2/v3 environment, and when it receives a v2
<br>
request already containing a tenant_ID it knows it will comprise <br>
domain:project and it can unpack it, and give the separate elements to
<br>
the rest of the V3 code for processing as in a v3 system. When the <br>
intercept module receives a v2 request that needs a tenant ID returning
<br>
to it, it will encode up the domain and project as a tenant ID, and <br>
return this to the v2 client. The v2 client will be blissfully unaware
<br>
that what it thinks is a tenant ID is actually a combination of domain
<br>
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 <d.w.chadwick@kent.ac.uk><br>
wrote:<br>
>> You have to ask, where does the Swift client get the tenant_Id
from? Isnt<br>
it<br>
>> Keystone? So if Keystone returns project_ID:tenant_Id to swift
as the<br>
>> project_id string, then Swift can continue to use this as if nothing
has<br>
>> changed. Its just a string whose content has no meaning to Swift,
but<br>
whose<br>
>> content does have meaning to Keystone. The Swift policy simply
needs to<br>
>> change the value of the tenant_id in its policy to the new value
and it<br>
>> should work the same<br>
>><br>
>> regards<br>
>><br>
>> David<br>
>><br>
>><br>
>> On 09/01/2013 20:21, heckj wrote:<br>
>>><br>
>>> Given that domains are a segmentation of projects/tenants,
then I<br>
wouldn't<br>
>>> expect to want to change it from a project_id representation
to anything<br>
>>> else.<br>
>>><br>
>>> -joe<br>
>>><br>
>>> On Jan 9, 2013, at 12:13 PM, Chuck Thier <cthier@gmail.com>
wrote:<br>
>>>><br>
>>>> Things are always easy, until you start thinking about
backwards<br>
>>>> compatibility.  The storage urls for swift with keystone
are currently<br>
>>>> keyed off of the tenant_id (soon to be project_id), so
you end up with<br>
>>>> 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 you<br>
>>>> 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>
<d.w.chadwick@kent.ac.uk><br>
>>>> 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,<br>
>>>>> then you prefix the names with the domain ID or domain
name to make<br>
them<br>
>>>>> 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>,
<tenant_id>:<user_name>, and<br>
>>>>>> *:<user_name> will be impacted if project
(formely tenant) name and<br>
>>>>>> user<br>
>>>>>> name are no longer globally unique. We'll need
to figure out a<br>
>>>>>> migration<br>
>>>>>> path before relaxing that constraint.<br>
>>>>>><br>
>>>>>><br>
>>>>>> Guang<br>
>>>>>><br>
>>>>>><br>
>>>>>> -----Original Message-----<br>
>>>>>> From: Chuck Thier [</font></tt><a href=mailto:cthier@gmail.com><tt><font size=2>mailto:cthier@gmail.com</font></tt></a><tt><font size=2>]<br>
>>>>>> Sent: Wednesday, January 09, 2013 10:48 AM<br>
>>>>>> To: OpenStack Development Mailing List<br>
>>>>>> Subject: Re: [openstack-dev] [swift] [keystone]
Keystone v3 API<br>
domains<br>
>>>>>> in<br>
>>>>>> Swift<br>
>>>>>><br>
>>>>>> Se responses inline:<br>
>>>>>><br>
>>>>>> On Wed, Jan 9, 2013 at 4:01 AM, Henry Nash<br>
<henryn@linux.vnet.ibm.com><br>
>>>>>> 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 Identity v3<br>
>>>>>>> api.<br>
>>>>>>> This is the issue of whether Swift uses tenant
names (now called<br>
>>>>>>> project<br>
>>>>>>> names) at all to uniquely identify any objects
- if it did, then it<br>
>>>>>>> would<br>
>>>>>>> need to also consider storing a domain name
or id.  From the<br>
>>>>>>> discussion,<br>
>>>>>><br>
>>>>>><br>
>>>>>> it<br>
>>>>>>><br>
>>>>>>><br>
>>>>>>> sounds like tenant/project ID is used instead,
which (from a<br>
>>>>>>> uniqueness<br>
>>>>>>> point of view) is fine.  A separate issue
exists needs to be<br>
discussed<br>
>>>>>>> around swift ACLs and whether username potentially
becoming unique<br>
>>>>>>> only<br>
>>>>>>> within a domain will have an impact.<br>
>>>>>>><br>
>>>>>><br>
>>>>>> For AuthN, you are correct, in that it only relies
on tenant/project<br>
>>>>>> ID.  So, nothing has to be changed from that
perspective.  AuthZ is a<br>
>>>>>> little more tricky. For ACLs with keystone, they
are set as<br>
>>>>>> TENANT:USER in any of the following 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>
>>>>>><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 keystone<br>
>>>>>> 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 usually<br>
>>>>>>> used<br>
>>>>>><br>
>>>>>><br>
>>>>>> to<br>
>>>>>>><br>
>>>>>>><br>
>>>>>>> represent an enterprise (or "account
holder" in common cloud<br>
>>>>>>> terminology)<br>
>>>>>>> and contain the collection of projects owned
by that enterprise, is<br>
it<br>
>>>>>>> important for Swift to have that domain knowledge?
 Will there be<br>
>>>>>><br>
>>>>>><br>
>>>>>> operations<br>
>>>>>>><br>
>>>>>>><br>
>>>>>>> either within swift (or more likely layered
on top of swift) that<br>
need<br>
>>>>>><br>
>>>>>><br>
>>>>>> that<br>
>>>>>>><br>
>>>>>>><br>
>>>>>>> information?  E.g. How would someone
layer a billing engine on top<br>
of<br>
>>>>>><br>
>>>>>><br>
>>>>>> swift<br>
>>>>>>><br>
>>>>>>><br>
>>>>>>> that could collate all the swift containers
that were part of one<br>
>>>>>>> domain?<br>
>>>>>>> Obviously that engine could call keystone
with each project_id in<br>
turn<br>
>>>>>>> and<br>
>>>>>>> find the domain_id.....but  that sounds
pretty inefficient.<br>
>>>>>>><br>
>>>>>><br>
>>>>>> As is, containers can already be collated for
a given tenant/project<br>
>>>>>> id.  The containers for a domain is then
an aggregate of the project<br>
>>>>>> 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
backwards<br>
>>>>>> compatibility, which brings up another interesting
question -- Is<br>
>>>>>> there an expectation that people will be able
to run keystone auth<br>
>>>>>> v2.0 and v3.0 side by side?<br>
>>>>>><br>
>>>>>> --<br>
>>>>>> Chuck<br>
>>>>>><br>
>>>>>> _______________________________________________<br>
>>>>>> OpenStack-dev mailing list<br>
>>>>>> OpenStack-dev@lists.openstack.org<br>
>>>>>> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> _______________________________________________<br>
>>>>>> OpenStack-dev mailing list<br>
>>>>>> OpenStack-dev@lists.openstack.org<br>
>>>>>> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
>>>>>><br>
>>>>><br>
>>>>> _______________________________________________<br>
>>>>> OpenStack-dev mailing list<br>
>>>>> OpenStack-dev@lists.openstack.org<br>
>>>>> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
>>>><br>
>>>><br>
>>>> _______________________________________________<br>
>>>> OpenStack-dev mailing list<br>
>>>> OpenStack-dev@lists.openstack.org<br>
>>>> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
>>><br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> OpenStack-dev mailing list<br>
>>> OpenStack-dev@lists.openstack.org<br>
>>> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
>>><br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> OpenStack-dev@lists.openstack.org<br>
>> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> OpenStack-dev@lists.openstack.org<br>
> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
OpenStack-dev@lists.openstack.org<br>
</font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
[attachment "smime.p7s" deleted by Alexandra Shulman-Peleg/Haifa/IBM]
_______________________________________________<br>
OpenStack-dev mailing list<br>
OpenStack-dev@lists.openstack.org<br>
</font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
</font></tt>
<br>