Open Stack

Thanks Henry this is very helpful. A few comments below

On 27/01/2013 10:43, Henry Nash wrote:
> David,
>
> So a few things are going on here:
>
> 1) Traditionally (in the pre-domain world), user name was "globally
> unique"....which really means unique within all openstack services
> sharing a keystone instance.  The same was true of tenant name.
> 2) In v3, if we kept this the same, then enterprises would find this
> restriction (particularly the one for tenants) unacceptable - some of
> them will expect free-rein over what they can call any names attribute
> (e.g. project name, user name etc.) inside the domain in which they are
> being hosted

So one would assume that they would want the same freedom for role names 
as well. So why isnt this included?

> 3) So v3, optionally allows the creation of a domain with a private name
> space for user names and/or project names

and one would have thought, for role names as well.

> 4) For Users, when they are created, you can optionally specify the
> domain they are "owned by".  If you specify a domain (say, "Kent") which
> was created with a private user name space, then for that specific user,
> its name only has to be unique within that domain (i.e. there can be
> other "David"'s in other private user space domains as well as a "David"
> shared across all other non-private domains).   That is what the comment
> is trying to say.

Understood thanks. As I am currently looking at the V3 documentation I 
will suggest some alternative wording for the text that confused me.

> 5) To answer your other questions specifically:
> - How do you tell if a user name is globally or domain-unique?  For a v3
> api, the domain_id of the owning domain is in the user entity, look that
> up and see if it is has the 'private_user_namespace' flag set to True.

Whilst this clearly works, it would be better from an efficiency 
perspective if a recipient did not need to do the look up in order to 
know. By always providing the domain name with the user name, this 
provides the solution and means the lookup is not needed, since if it is 
a private name, you are given the private domain it belongs to and in 
which it is unique, and if it is a global name, you are given the public 
(or private) domain in which it belongs and in which it is still unique. 
Since the CSP always gets both of these bits of information, then it 
will not mess up the authz decision (and not give the wrong user 
access), so no lookup is needed. (In effect, from the recipients 
perspective, you are treating all usernames as if they were local to the 
domain, even if some of them are not).


> - Who is the owner of a "globally unique username"?  It can be any
> domain that has 'private_user_namespace' flag set to False, including
> the default domain
> On 26 Jan 2013, at 17:08, Dolph Mathews wrote:
> - In your example of the two different domains, these would not be the
> same user in the current implementation that is underway - i.e. a user
> is either globally-unique or domain-unique.

Ok, got this now, thanks

David

 >
> As an aside, we had the discussion as to whether we should just say that
> all domains have private name spaces....although we are trying to
> balance (as usual) backward compatibility with adding new features.  For
> instance, one implication of a domain with a private user namespace is
> that, as Dolph says, you must either supply user_ID or username+domain
> in order to authenticate.  We wanted to keep that requirement to ONLY
> those domains that really needed it...not make it the norm for v3.  This
> would, for instance, allow a Folsom cloud provider, who hosts many
> individual or small enterprise accounts, to upgrade to Grizzly and
>
> a) Continue to host all those existing accounts (by default the all
> users and projects will be in the default domain)
> b) Start to add medium enterprises in domains (who perhaps are happy
> without private namespaces)...without affecting a)
> c) Start to add some larger enterprises in domains with their own
> private namespaces...without affecting a) or b)
>
> Henry
>
>> Relevant blueprint:
>> https://blueprints.launchpad.net/keystone/+spec/domain-name-spaces
>>
>> Corresponding spec change: https://review.openstack.org/#/c/18805/
>>
>> These changes have not been implemented yet.
>>
>> Essentially it's an opt-in change of behavior per domain. Auth for
>> users and projects within those domains must either be identified by
>> globally-unique ID, or a combinations of owning domain and
>> user/project name.
>>
>> Users and projects are namespaced by their owning domain, so the
>> configuration of two different domains wouldn't apply to a single user
>> or project.
>>
>>
>> -Dolph
>>
>>
>> On Sat, Jan 26, 2013 at 4:04 AM, David Chadwick
>> <d.w.chadwick at kent.ac.uk <mailto:d.w.chadwick at kent.ac.uk>> wrote:
>>
>>     The keystone v3 API contains the following statement in the Users
>>     section
>>
>>     Either globally or domain unique username, depending on owning domain.
>>
>>     Can someone explain what this means please.
>>
>>     More specifically, this states that a username is either globally
>>     unique across all domains, or is locally defined in a domain.
>>
>>     First question. How can anyone tell the difference between a
>>     globally unique username and a domain specific username?
>>
>>     Second, who or what is the owning domain for a globally unique
>>     username?
>>
>>     Finally why should the owning domain determine whether the
>>     username is globally unique or not? What if owning domain 1
>>     determines that username1 is globally unique and owning domain 2
>>     determines that username1 is locally unique to itself?
>>
>>     thanks
>>
>>     David
>>
>>
>>     _________________________________________________
>>     OpenStack-dev mailing list
>>     OpenStack-dev at lists.openstack.__org
>>     <mailto:OpenStack-dev at lists.openstack.org>
>>     http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev
>>     <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> <mailto:OpenStack-dev at lists.openstack.org>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>