Open Stack

Yay! I'd be curious if anyone is particularly in favor of D, otherwise I
think we should run with A.


-Dolph


On Sat, Jan 19, 2013 at 3:38 AM, Henry Nash <henryn at linux.vnet.ibm.com>wrote:

>
> On 19 Jan 2013, at 05:19, Dolph Mathews wrote:
>
>
> 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?
>
>
> Actually this is what I meant by (a)....since I was listing the options
> for what we do when the user does NOT specify the optional domain in the
> create call...so we are in violent agreement!
>
>
>
>> 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
>>
>>
> _______________________________________________
> 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/20130119/b4439449/attachment.html>