Open Stack

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

 

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

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130122/5eb4bfec/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6186 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130122/5eb4bfec/attachment.bin>