Open Stack

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
>