Open Stack

On Fri, Jan 18, 2013 at 8:23 AM, Henry Nash <henryn at linux.vnet.ibm.com>wrote:

> Building on the question on how the v3 APIs might operation (e.g. create
> user, project etc.) when the (optional) domain_id is omitted....first some
> goals:
>
> 1) We want those cloud providers who don't need domains to be able to use
> either the v2 or v3 api calls - i.e. they can use the latest s/w and still
> operate their cloud like it was in Folsom (in terms of keystone
> user-project relationships).
> 2) For operators that start using domains, we want it to be conceptually
> obvious what sets of entities that various api calls will be able to see.
>  This needs to take into account  domains with private user or project
> namespaces.
>
> Taking this bp as a stating point in terms of having a default domain
> (that will contain any pre-Girzzly user and projects/tenants), what happens
> when a v3 API call is made to create a user or project without specifying a
> domain?  The options are:
> a) Create the entity in the domain of the user doing the creation.  If
> this is a user that exists in the default domain (e.g. a pre-Grizzly user),
> then that's where the new resource goes (I would assume we treat "admin" as
> being in the default domain).
> b) Always create the entity in the default domain
> c) Insist on the specification of a domain if more than just the default
> domain exists (i.e. it's a multi-domain configuration)
>
>
d) Always insist on the specification of a domain
e) Create the entity in the domain of the user doing the creation, unless
another domain is specified.

(A) is broken in use cases where I need to be allowed to create users in
other domains (creating domains and users to administer them, for instance).

(B) is broken for the same reason; I shouldn't have to create an object and
then move it to where I want it to go.

(C) brings up some questions that I worry will only lead to bug reports
(what if I deleted the default domain but I still have this other domain
that doesn't match the default_domain_id, etc)

(D) is obvious, but perhaps inconvenient for a subset of users (those that
ONLY administer their own domain).

(E) offers the convenience of (A) with the power of (D). I can't think of a
use case that this breaks?


> Allied to this is authentication....since a domain specifier is also
> optional in terms of the v3 auth details, which is relevant if username
> rather than user_id is specified:
>
> i) user name (and project name for that matter) are still unique across
> all domains (including the default domain) except for those domains with a
> private name space.  So it would be perfectly possible to authenticate by
> searching for a user/project name in any domain other than those with
> private name spaces.  The advantage of this is that a domain specifier is
> ONLY required to access a domain with a private user namespace - access to
> all other domains doesn't need to worry about domains in terms of
> authentication (this is what is described in the domain-name-space
> blueprint).  The only question is whether this passes the test 2) above in
> terms of being obvious.  The alternative is to insist on a domain specifier
> to get to authenticate any user not in the default domain.
> ii) The v2 authentication remains unchanged, of course, and will look for
> the user and tenant name in the default domain.  In theory, we could let
> such calls use the same search as i) to allow users who are not part of a
> private domain to authenticate via the v2 API.  However, I think this
> definitely fails the 2) obvious test and so we should not do this.
>
> In terms of which of the options a), b) or c) we should chose in the
> creation question above, I think b) is unlikely to match typical use cases
> (i.e. if you have domains and have created users within them, you are
> unlikely to often want to create users in the default domain).  So the
> choice is between a) and c).  While c) certainly provides no ambiguity, I
> would think that a) would match the most common usage patterns, and is also
> not disruptive if you missed off specifying the domain by mistake (since
> you only affect your own domain).
>
> Other ideas/comments?
>
> Henry
>
>
> On 16 Jan 2013, at 22:00, Dolph Mathews wrote:
>
> New installs run through the migration process of course, so they would
> end up with a default domain, even if there's nothing referencing it. The
> v2 API would not work out of the box, otherwise.
>
> If you didn't want to support the v2 API in your deployment, you'd have to
> manually remove the v2-related pipelines from your keystone.conf, and then
> you could manually delete the default domain through SQL (if desired --
> it's still a valid domain on v3). Attempting to delete it through the v3
> API would break the v2 API, hence the desire to deny that behavior and
> force a manual process. All of these constraints could be removed in the
> Grizzly+2 timeframe, if we see fit to no longer support v2 at all (at that
> point, the data migration could be revised to only create a default domain
> *if it was necessary based on existing data*, so fresh Grizzly+2 installs
> would be empty out of the box).
>
> Alternatively, if you wanted to expose a different domain on v2, you could
> also create & configure it on v3, and then set your default_domain_id to
> that domain's ID, and then delete the unused 'default' domain through the
> API (e.g. DELETE /v3/domains/default). You could use a similar process to
> completely circumvent the dont-delete-the-default-domain check.
>
> LDAP support for domains is trailing at the moment, so I'm speaking mostly
> with an eye toward SQL, but the default_domain_id will apply there as well
> -- we just won't be able to create the domain for you.
>
> All that said, although it's relatively early in the grizzly-m3 cycle, I
> don't imagine you will want to deploy Grizzly without v2 support as there
> will still be v2 clients in use, even among the core projects.
>
> -Dolph
>
>
> On Wed, Jan 16, 2013 at 1:57 PM, Brant Knudson <blk at acm.org> wrote:
>
>> Dolph -
>>
>> The bp mentions migration, but it doesn't mention new installs. Does a
>> new install automatically get the default domain?
>>
>> The bp says that you can also not have a default domain, but the default_
>> domain_id configuration option has a default. What do I set the
>> configuration option to if I don't have a default domain?
>>
>> The bp says that an attempt to delete the default domain will result in
>> 403 Forbidden. In the case where there is no default domain you should get
>> a 404 Not Found rather than 403.
>>
>> - Brant
>>
>>
>>
>> On Tue, Jan 15, 2013 at 2:42 PM, Dolph Mathews <dolph.mathews at gmail.com>wrote:
>>
>>> Per today's keystone meeting, I wrote a blueprint for the default domain
>>> solution, in order to provide an assumed scope for v2 API operations (which
>>> is not domain-aware), including authentication and validation, in the
>>> context of a deployment with v3 API users (which are domain-aware).
>>>
>>>   https://blueprints.launchpad.net/keystone/+spec/default-domain
>>>
>>> Feedback appreciated,
>>>
>>> -Dolph
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> 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
>>
>>
> _______________________________________________
> OpenStack-dev mailing list
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130118/d6aa4afb/attachment.html>