<font size=2 face="sans-serif">+1</font>
<br>
<br><font size=2 face="sans-serif">Thanks Henry for your clear and easy
to read summary of the proposal!</font>
<br>
<br><font size=2 face="sans-serif">--Brad</font>
<br><font size=2 face="sans-serif"><br>
Brad Topol, Ph.D.<br>
IBM Distinguished Engineer<br>
OpenStack<br>
(919) 543-0646<br>
Internet: btopol@us.ibm.com<br>
Assistant: Cindy Willman (919) 268-5296</font>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">Henry Nash <henryn@linux.vnet.ibm.com></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">David Chadwick <d.w.chadwick@kent.ac.uk></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Cc:
</font><font size=1 face="sans-serif">OpenStack Development
Mailing List <openstack-dev@lists.openstack.org></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">01/23/2013 11:49 AM</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">Re: [openstack-dev]
[keystone] A default domain</font>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>So, as previously described, what has been proposed
is:<br>
<br>
- v2 tenants/users are migrated across to the default domain - the v2 api
will continue to access these entities<br>
- If a cloud provider does (using the v3 api) create domains, then any
users/groups/projects created within those domains are simply not visible
via the v2 api. A v3 client can, of course, create entities in the
default domain....and those would be visible via the v2 api<br>
- The fact that a default domain exists at all is hidden from the v2 api
(i.e. domain_id attributes from all entities in the default domain are
filtered out)<br>
- A v2 client has no need to see domain roles, since it can't ask for them
(i.e. it can't ask for a domain scoped token), and would not know how to
interpret them anyway (i.e. the related policy file would not know about
domain roles either)<br>
- More complex versions of the above indeed possible, but so far we have
considered them more confusing to make them worthwhile<br>
<br>
Henry<br>
On 23 Jan 2013, at 15:32, David Chadwick wrote:<br>
<br>
> Isnt it more complex than this? What if an V3 admin has set up an
OpenStack system with multiple domains, but some services are still using
the V2 API. In this case they cant (or shouldn't) all occupy the default
domain. Rather, as I argued in an earlier posting, there should be an intercept
module in the Keystone code that converts the domain and role into <domain><separator><role>
(where separator is a configurable string according to culture, language,
char set etc.) and returns this to the V2 api as the role (since it does
not know about domains). Then the reverse conversion is done when the V2
API passes in the role. The only thing the V2 service needs to do is change
its policy so that wherever role is specified in a rule it is now replaced
by <domain><separator><role> as the role string. A string
is just a string to a policy engine so it wont care that the string is
now longer and has some hidden internal meaning.<br>
> <br>
> regards<br>
> <br>
> David<br>
> <br>
> <br>
> On 22/01/2013 15:07, Henry Nash wrote:<br>
>> OK, here is how I suggest we proceed:<br>
>> <br>
>> First, there are two separate (but related) items:<br>
>> <br>
>> 1) How do we migrate v2 users across? I don't think anyone
is arguing that they should not go into a default domain -
we need a way of letting the v2 api work on users migrated across to Grizzly.
Dolph has a change pending to create the default domain, which I
will then pick up and do the actual migration code as part of the domain_scoping
change (since I need domains to be fully supported for that). I suggest,
we let Dolph's change go in since there is no debate about it.<br>
>> 2) What happens in v3 if a call is made to create an entity (user,
group, project etc.) where the optional domain_id is not specified? That
is what all the options relate to. There are really only 3 options
(since Dolph's additions of D & E are actually duplicates of mine since
I was not trying to suggest that we would override a domain_id if it IS
specified). Dolph and I will bring forward the proposed design/blueprint
that specifies the proposal for these v3 calls in more detail.<br>
>> <br>
>> Does this sound like a plan?<br>
>> <br>
>> Henry<br>
>> <br>
>> On 22 Jan 2013, at 14:30, David Chadwick wrote:<br>
>> <br>
>>> I think a fully specified design document would be good before
the implementation is hardened :-)<br>
>>> <br>
>>> On 22/01/2013 12:47, Adam Young wrote:<br>
>>>> On 01/22/2013 12:25 AM, Yee, Guang wrote:<br>
>>>>> <br>
>>>>> Is D) even possible, since token can only scope to
one domain at a time?<br>
>>>>> <br>
>>>>> Guang<br>
>>>>> <br>
>>>>> *From:*Dolph Mathews [</font></tt><a href=mailto:dolph.mathews@gmail.com><tt><font size=2>mailto:dolph.mathews@gmail.com</font></tt></a><tt><font size=2>]<br>
>>>>> *Sent:* Saturday, January 19, 2013 7:26 AM<br>
>>>>> *To:* OpenStack Development Mailing List<br>
>>>>> *Subject:* Re: [openstack-dev] [keystone] A default
domain<br>
>>>>> <br>
>>>>> Yay! I'd be curious if anyone is particularly in favor
of D, otherwise<br>
>>>>> I think we should run with A.<br>
>>>>> <br>
>>>>> <br>
>>>>> -Dolph<br>
>>>>> <br>
>>>>> On Sat, Jan 19, 2013 at 3:38 AM, Henry Nash <henryn@linux.vnet.ibm.com<br>
>>>>> <</font></tt><a href=mailto:henryn@linux.vnet.ibm.com><tt><font size=2>mailto:henryn@linux.vnet.ibm.com</font></tt></a><tt><font size=2>>>
wrote:<br>
>>>>> <br>
>>>>> On 19 Jan 2013, at 05:19, Dolph Mathews wrote:<br>
>>>>> <br>
>>>>> <br>
>>>>> <br>
>>>>> On Fri, Jan 18, 2013 at 8:23 AM, Henry Nash <henryn@linux.vnet.ibm.com<br>
>>>>> <</font></tt><a href=mailto:henryn@linux.vnet.ibm.com><tt><font size=2>mailto:henryn@linux.vnet.ibm.com</font></tt></a><tt><font size=2>>>
wrote:<br>
>>>>> <br>
>>>>> Building on the question on how the v3 APIs might
operation (e.g.<br>
>>>>> create user, project etc.) when the (optional) domain_id
is<br>
>>>>> omitted....first some goals:<br>
>>>>> <br>
>>>>> 1) We want those cloud providers who don't need domains
to be able to<br>
>>>>> use either the v2 or v3 api calls - i.e. they can
use the latest s/w<br>
>>>>> and still operate their cloud like it was in Folsom
(in terms of<br>
>>>>> keystone user-project relationships).<br>
>>>>> <br>
>>>>> 2) For operators that start using domains, we want
it to be<br>
>>>>> conceptually obvious what sets of entities that various
api calls will<br>
>>>>> be able to see. This needs to take into account
domains with private<br>
>>>>> user or project namespaces.<br>
>>>>> <br>
>>>>> Taking this bp as a stating point in terms of having
a default domain<br>
>>>>> (that will contain any pre-Girzzly user and projects/tenants),
what<br>
>>>>> happens when a v3 API call is made to create a user
or project without<br>
>>>>> specifying a domain? The options are:<br>
>>>>> <br>
>>>>> a) Create the entity in the domain of the user doing
the creation. If<br>
>>>>> this is a user that exists in the default domain (e.g.
a pre-Grizzly<br>
>>>>> user), then that's where the new resource goes (I
would assume we<br>
>>>>> treat "admin" as being in the default domain).<br>
>>>>> <br>
>>>>> b) Always create the entity in the default domain<br>
>>>>> <br>
>>>>> c) Insist on the specification of a domain if more
than just the<br>
>>>>> default domain exists (i.e. it's a multi-domain configuration)<br>
>>>>> <br>
>>>>> d) Always insist on the specification of a domain<br>
>>>>> <br>
>>>>> e) Create the entity in the domain of the user doing
the creation,<br>
>>>>> unless another domain is specified.<br>
>>>>> <br>
>>>>> (A) is broken in use cases where I need to be allowed
to create users<br>
>>>>> in other domains (creating domains and users to administer
them, for<br>
>>>>> instance).<br>
>>>>> <br>
>>>>> (B) is broken for the same reason; I shouldn't have
to create an<br>
>>>>> object and then move it to where I want it to go.<br>
>>>>> <br>
>>>>> (C) brings up some questions that I worry will only
lead to bug<br>
>>>>> reports (what if I deleted the default domain but
I still have this<br>
>>>>> other domain that doesn't match the default_domain_id,
etc)<br>
>>>>> <br>
>>>>> (D) is obvious, but perhaps inconvenient for a subset
of users (those<br>
>>>>> that ONLY administer their own domain).<br>
>>>>> <br>
>>>>> (E) offers the convenience of (A) with the power of
(D). I can't think<br>
>>>>> of a use case that this breaks?<br>
>>>>> <br>
>>>> <br>
>>>> We create a component which is DomainResolutionStrategy.
There are 5<br>
>>>> concrete implementations, which map to A-E above. Specify
which to use<br>
>>>> in the config file.<br>
>>>> <br>
>>>> <br>
>>>>> Actually this is what I meant by (a)....since I was
listing the<br>
>>>>> options for what we do when the user does NOT specify
the optional<br>
>>>>> domain in the create call...so we are in violent agreement!<br>
>>>>> <br>
>>>>> <br>
>>>>> <br>
>>>>> Allied to this is authentication....since
a domain specifier is<br>
>>>>> also optional in terms of the v3 auth
details, which is relevant<br>
>>>>> if username rather than user_id is specified:<br>
>>>>> <br>
>>>>> i) user name (and project name for that
matter) are still unique<br>
>>>>> across all domains (including the default
domain) except for those<br>
>>>>> domains with a private name space. So
it would be perfectly<br>
>>>>> possible to authenticate by searching
for a user/project name in<br>
>>>>> any domain other than those with private
name spaces. The<br>
>>>>> advantage of this is that a domain specifier
is ONLY required to<br>
>>>>> access a domain with a private user namespace
- access to all<br>
>>>>> other domains doesn't need to worry about
domains in terms of<br>
>>>>> authentication (this is what is described
in the domain-name-space<br>
>>>>> blueprint). The only question is
whether this passes the test 2)<br>
>>>>> above in terms of being obvious. The
alternative is to insist on<br>
>>>>> a domain specifier to get to authenticate
any user not in the<br>
>>>>> default domain.<br>
>>>>> <br>
>>>>> ii) The v2 authentication remains unchanged,
of course, and will<br>
>>>>> look for the user and tenant name in
the default domain. In<br>
>>>>> theory, we could let such calls use the
same search as i) to allow<br>
>>>>> users who are not part of a private domain
to authenticate via the<br>
>>>>> v2 API. However, I think this definitely
fails the 2) obvious<br>
>>>>> test and so we should not do this.<br>
>>>>> <br>
>>>>> In terms of which of the options a),
b) or c) we should chose in<br>
>>>>> the creation question above, I think
b) is unlikely to match<br>
>>>>> typical use cases (i.e. if you have domains
and have created users<br>
>>>>> within them, you are unlikely to often
want to create users in the<br>
>>>>> default domain). So the choice
is between a) and c). While c)<br>
>>>>> certainly provides no ambiguity, I would
think that a) would match<br>
>>>>> the most common usage patterns, and is
also not disruptive if you<br>
>>>>> missed off specifying the domain by mistake
(since you only affect<br>
>>>>> your own domain).<br>
>>>>> <br>
>>>>> Other ideas/comments?<br>
>>>>> <br>
>>>>> Henry<br>
>>>>> <br>
>>>>> On 16 Jan 2013, at 22:00, Dolph Mathews
wrote:<br>
>>>>> <br>
>>>>> <br>
>>>>> <br>
>>>>> New installs run through the migration
process of course, so they<br>
>>>>> would end up with a default domain, even
if there's nothing<br>
>>>>> referencing it. The v2 API would not
work out of the box, otherwise.<br>
>>>>> <br>
>>>>> If you didn't want to support the v2
API in your deployment, you'd<br>
>>>>> have to manually remove the v2-related
pipelines from your<br>
>>>>> keystone.conf, and then you could manually
delete the default<br>
>>>>> domain through SQL (if desired -- it's
still a valid domain on<br>
>>>>> v3). Attempting to delete it through
the v3 API would break the v2<br>
>>>>> API, hence the desire to deny that behavior
and force a manual<br>
>>>>> process. All of these constraints could
be removed in the<br>
>>>>> Grizzly+2 timeframe, if we see fit to
no longer support v2 at all<br>
>>>>> (at that point, the data migration could
be revised to only create<br>
>>>>> a default domain *if it was necessary
based on existing data*, so<br>
>>>>> fresh Grizzly+2 installs would be empty
out of the box).<br>
>>>>> <br>
>>>>> Alternatively, if you wanted to expose
a different domain on v2,<br>
>>>>> you could also create & configure
it on v3, and then set your<br>
>>>>> default_domain_id to that domain's ID,
and then delete the unused<br>
>>>>> 'default' domain through the API (e.g.
DELETE<br>
>>>>> /v3/domains/default). You could use a
similar process to<br>
>>>>> completely circumvent the dont-delete-the-default-domain
check.<br>
>>>>> <br>
>>>>> LDAP support for domains is trailing
at the moment, so I'm<br>
>>>>> speaking mostly with an eye toward SQL,
but the default_domain_id<br>
>>>>> will apply there as well -- we just won't
be able to create the<br>
>>>>> domain for you.<br>
>>>>> <br>
>>>>> All that said, although it's relatively
early in the grizzly-m3<br>
>>>>> cycle, I don't imagine you will want
to deploy Grizzly without v2<br>
>>>>> support as there will still be v2 clients
in use, even among the<br>
>>>>> core projects.<br>
>>>>> <br>
>>>>> -Dolph<br>
>>>>> <br>
>>>>> On Wed, Jan 16, 2013 at 1:57 PM, Brant
Knudson <blk@acm.org<br>
>>>>> <</font></tt><a href=mailto:blk@acm.org><tt><font size=2>mailto:blk@acm.org</font></tt></a><tt><font size=2>>>
wrote:<br>
>>>>> <br>
>>>>> Dolph -<br>
>>>>> <br>
>>>>> The bp mentions migration, but it doesn't
mention new installs.<br>
>>>>> Does a new install automatically get
the default domain?<br>
>>>>> <br>
>>>>> The bp says that you can also not have
a default domain, but the<br>
>>>>> default_domain_id configuration option
has a default. What do I<br>
>>>>> set the configuration option to if I
don't have a default domain?<br>
>>>>> <br>
>>>>> The bp says that an attempt to delete
the default domain will<br>
>>>>> result in 403 Forbidden. In the case
where there is no default<br>
>>>>> domain you should get a 404 Not Found
rather than 403.<br>
>>>>> <br>
>>>>> - Brant<br>
>>>>> <br>
>>>>> On Tue, Jan 15, 2013 at 2:42 PM, Dolph
Mathews<br>
>>>>> <dolph.mathews@gmail.com <</font></tt><a href=mailto:dolph.mathews@gmail.com><tt><font size=2>mailto:dolph.mathews@gmail.com</font></tt></a><tt><font size=2>>>
wrote:<br>
>>>>> <br>
>>>>> Per today's keystone meeting,
I wrote a blueprint for the<br>
>>>>> default domain solution,
in order to provide an assumed scope<br>
>>>>> for v2 API operations (which
is not domain-aware), including<br>
>>>>> authentication and validation,
in the context of a deployment<br>
>>>>> with v3 API users (which
are domain-aware).<br>
>>>>> <br>
>>>>> </font></tt><a href="https://blueprints.launchpad.net/keystone/+spec/default-domain"><tt><font size=2>https://blueprints.launchpad.net/keystone/+spec/default-domain</font></tt></a><tt><font size=2><br>
>>>>> <br>
>>>>> Feedback appreciated,<br>
>>>>> <br>
>>>>> -Dolph<br>
>>>>> <br>
>>>>> _______________________________________________<br>
>>>>> OpenStack-dev mailing list<br>
>>>>> OpenStack-dev@lists.openstack.org<br>
>>>>> <</font></tt><a href="mailto:OpenStack-dev@lists.openstack.org"><tt><font size=2>mailto:OpenStack-dev@lists.openstack.org</font></tt></a><tt><font size=2>><br>
>>>>> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
>>>>> <br>
>>>>> <br>
>>>>> _______________________________________________<br>
>>>>> OpenStack-dev mailing list<br>
>>>>> OpenStack-dev@lists.openstack.org<br>
>>>>> <</font></tt><a href="mailto:OpenStack-dev@lists.openstack.org"><tt><font size=2>mailto:OpenStack-dev@lists.openstack.org</font></tt></a><tt><font size=2>><br>
>>>>> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
>>>>> <br>
>>>>> _______________________________________________<br>
>>>>> OpenStack-dev mailing list<br>
>>>>> OpenStack-dev@lists.openstack.org<br>
>>>>> <</font></tt><a href="mailto:OpenStack-dev@lists.openstack.org"><tt><font size=2>mailto:OpenStack-dev@lists.openstack.org</font></tt></a><tt><font size=2>><br>
>>>>> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
>>>>> <br>
>>>>> <br>
>>>>> _______________________________________________<br>
>>>>> OpenStack-dev mailing list<br>
>>>>> OpenStack-dev@lists.openstack.org<br>
>>>>> <</font></tt><a href="mailto:OpenStack-dev@lists.openstack.org"><tt><font size=2>mailto:OpenStack-dev@lists.openstack.org</font></tt></a><tt><font size=2>><br>
>>>>> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
>>>>> <br>
>>>>> _______________________________________________<br>
>>>>> OpenStack-dev mailing list<br>
>>>>> OpenStack-dev@lists.openstack.org<br>
>>>>> <</font></tt><a href="mailto:OpenStack-dev@lists.openstack.org"><tt><font size=2>mailto:OpenStack-dev@lists.openstack.org</font></tt></a><tt><font size=2>><br>
>>>>> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
>>>>> <br>
>>>>> <br>
>>>>> _______________________________________________<br>
>>>>> OpenStack-dev mailing list<br>
>>>>> OpenStack-dev@lists.openstack.org<br>
>>>>> <</font></tt><a href="mailto:OpenStack-dev@lists.openstack.org"><tt><font size=2>mailto:OpenStack-dev@lists.openstack.org</font></tt></a><tt><font size=2>><br>
>>>>> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
>>>>> <br>
>>>>> <br>
>>>>> <br>
>>>>> _______________________________________________<br>
>>>>> OpenStack-dev mailing list<br>
>>>>> OpenStack-dev@lists.openstack.org<br>
>>>>> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
>>>> <br>
>>>> <br>
>>>> <br>
>>>> _______________________________________________<br>
>>>> OpenStack-dev mailing list<br>
>>>> OpenStack-dev@lists.openstack.org<br>
>>>> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
>>>> <br>
>>> <br>
>>> _______________________________________________<br>
>>> OpenStack-dev mailing list<br>
>>> OpenStack-dev@lists.openstack.org<br>
>>> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
>>> <br>
>> <br>
>> <br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> OpenStack-dev@lists.openstack.org<br>
>> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
>> <br>
> <br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
OpenStack-dev@lists.openstack.org<br>
</font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
<br>
</font></tt>
<br>