Open Stack

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130122/5af2d73e/attachment.html>