Open Stack

Yes. Swift ACLs <tenant_id>:<user_name>, <tenant_id>:<user_name>, and
*:<user_name> will be impacted if project (formely tenant) name and user
name are no longer globally unique. We'll need to figure out a migration
path before relaxing that constraint.


Guang


-----Original Message-----
From: Chuck Thier [mailto:cthier at gmail.com] 
Sent: Wednesday, January 09, 2013 10:48 AM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [swift] [keystone] Keystone v3 API domains in
Swift

Se responses inline:

On Wed, Jan 9, 2013 at 4:01 AM, Henry Nash <henryn at linux.vnet.ibm.com>
wrote:
> So there are a couple of issues intertwined in this thread:
>
> 1) Uniqueness of identifiers in Swift given the keystone Identity v3 api.
> This is the issue of whether Swift uses tenant names (now called project
> names) at all to uniquely identify any objects - if it did, then it would
> need to also consider storing a domain name or id.  From the discussion,
it
> sounds like tenant/project ID is used instead, which (from a uniqueness
> point of view) is fine.  A separate issue exists needs to be discussed
> around swift ACLs and whether username potentially becoming unique only
> within a domain will have an impact.
>

For AuthN, you are correct, in that it only relies on tenant/project
ID.  So, nothing has to be changed from that perspective.  AuthZ is a
little more tricky. For ACLs with keystone, they are set as
TENANT:USER in any of the following patterns:

*:user_name - that user from any tenant has access
tenant_id:user_name - that user from that tenant id has access
tenant_name:user_name - that user from that tenant name has access

If project_name will not be unique in v3, then the
tenant_name:user_name format may have to be deprecated.

I would be interested to hear from providers that are using keystone
with swift and hear which of the above use cases they are using.


> 2) Given that keystone identity v3 domains are likely to be usually used
to
> represent an enterprise (or "account holder" in common cloud terminology)
> and contain the collection of projects owned by that enterprise, is it
> important for Swift to have that domain knowledge?  Will there be
operations
> either within swift (or more likely layered on top of swift) that need
that
> information?  E.g. How would someone layer a billing engine on top of
swift
> that could collate all the swift containers that were part of one domain?
> Obviously that engine could call keystone with each project_id in turn and
> find the domain_id.....but  that sounds pretty inefficient.
>

As is, containers can already be collated for a given tenant/project
id.  The containers for a domain is then an aggregate of the project
ids  associated to that domain.

I think the default should be that domains are not mapped in swift.  I
believe that this will also be required to facilitate backwards
compatibility, which brings up another interesting question -- Is
there an expectation that people will be able to run keystone auth
v2.0 and v3.0 side by side?

--
Chuck

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6186 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130109/dd31625c/attachment.bin>