Open Stack

I care more about the expected behavior as a client than as a deployer.


-Dolph


On Tue, Jan 22, 2013 at 6:47 AM, Adam Young <ayoung at redhat.com> 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<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>
> 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?****
>
>
> 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> 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****
>
> ** **
>
>
> _______________________________________________
> OpenStack-dev mailing listOpenStack-dev at lists.openstack.orghttp://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/ea790ed7/attachment.html>