Open Stack

On 01/22/2013 09:30 AM, David Chadwick wrote:
> I think a fully specified design document would be good before the 
> implementation is hardened :-)
That is a spec entry.

1.  We support multiple strategies for dealing with multiple domains
2.  We make specifying which strategy to use a config option
3.  We make it possible to add additional strategies either as follow on 
development or as a hot fix on a live deployment.


>
> 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
>>