[openstack-dev] [keystone] A default domain
Henry Nash
henryn at linux.vnet.ibm.com
Tue Jan 22 15:07:24 UTC 2013
OK, here is how I suggest we proceed:
First, there are two separate (but related) items:
1) How do we migrate v2 users across? I don't think anyone is arguing that they should not go into a default domain - we need a way of letting the v2 api work on users migrated across to Grizzly. Dolph has a change pending to create the default domain, which I will then pick up and do the actual migration code as part of the domain_scoping change (since I need domains to be fully supported for that). I suggest, we let Dolph's change go in since there is no debate about it.
2) What happens in v3 if a call is made to create an entity (user, group, project etc.) where the optional domain_id is not specified? That is what all the options relate to. There are really only 3 options (since Dolph's additions of D & E are actually duplicates of mine since I was not trying to suggest that we would override a domain_id if it IS specified). Dolph and I will bring forward the proposed design/blueprint that specifies the proposal for these v3 calls in more detail.
Does this sound like a plan?
Henry
On 22 Jan 2013, at 14:30, David Chadwick wrote:
> I think a fully specified design document would be good before the implementation is hardened :-)
>
> On 22/01/2013 12:47, Adam Young wrote:
>> On 01/22/2013 12:25 AM, Yee, Guang wrote:
>>>
>>> Is D) even possible, since token can only scope to one domain at a time?
>>>
>>> Guang
>>>
>>> *From:*Dolph Mathews [mailto:dolph.mathews at gmail.com]
>>> *Sent:* Saturday, January 19, 2013 7:26 AM
>>> *To:* OpenStack Development Mailing List
>>> *Subject:* Re: [openstack-dev] [keystone] A default domain
>>>
>>> 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
>>> <mailto: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
>>> <mailto: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?
>>>
>>
>> We create a component which is DomainResolutionStrategy. There are 5
>> concrete implementations, which map to A-E above. Specify which to use
>> in the config file.
>>
>>
>>> 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
>>> <mailto: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 <mailto: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
>>> <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
>>> <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
>>> <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
>>> <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
>>> <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
>>> <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
>>
>>
>>
>> _______________________________________________
>> 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
>
More information about the OpenStack-dev
mailing list