Open Stack

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