<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 01/22/2013 12:25 AM, Yee, Guang
wrote:<br>
</div>
<blockquote
cite="mid:C73B35E94B12854596094F2CA866854950B17AE0@G9W0344.americas.hpqcorp.net"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<meta name="Generator" content="Microsoft Word 12 (filtered
medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Is
D) even possible, since token can only scope to one domain
at a time? <o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Guang<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #B5C4DF
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">
Dolph Mathews [<a class="moz-txt-link-freetext" href="mailto:dolph.mathews@gmail.com">mailto:dolph.mathews@gmail.com</a>] <br>
<b>Sent:</b> Saturday, January 19, 2013 7:26 AM<br>
<b>To:</b> OpenStack Development Mailing List<br>
<b>Subject:</b> Re: [openstack-dev] [keystone] A default
domain<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">Yay! I'd be curious if anyone is
particularly in favor of D, otherwise I think we should run
with A.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><br clear="all">
<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">-Dolph<o:p></o:p></p>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Sat, Jan 19, 2013 at 3:38 AM, Henry
Nash <<a moz-do-not-send="true"
href="mailto:henryn@linux.vnet.ibm.com" target="_blank">henryn@linux.vnet.ibm.com</a>>
wrote:<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<div>
<p class="MsoNormal">On 19 Jan 2013, at 05:19, Dolph
Mathews wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Fri, Jan 18, 2013 at
8:23 AM, Henry Nash <<a
moz-do-not-send="true"
href="mailto:henryn@linux.vnet.ibm.com"
target="_blank">henryn@linux.vnet.ibm.com</a>>
wrote:<o:p></o:p></p>
<div>
<p class="MsoNormal">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:<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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). <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">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). <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">b) Always create the
entity in the default domain<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">c) Insist on the
specification of a domain if more than
just the default domain exists (i.e. it's
a multi-domain configuration)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:8.0pt;font-family:"Arial","sans-serif"">d)
Always insist on the specification of a
domain</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-family:"Arial","sans-serif"">e)
Create the entity in the domain of the
user doing the creation, unless another
domain is specified.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-family:"Arial","sans-serif"">(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).</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-family:"Arial","sans-serif"">(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.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-family:"Arial","sans-serif"">(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)</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-family:"Arial","sans-serif"">(D)
is obvious, but perhaps inconvenient for a
subset of users (those that ONLY
administer their own domain).</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-family:"Arial","sans-serif"">(E)
offers the convenience of (A) with the
power of (D). I can't think of a use case
that this breaks?</span><o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<br>
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.<br>
<br>
<br>
<blockquote
cite="mid:C73B35E94B12854596094F2CA866854950B17AE0@G9W0344.americas.hpqcorp.net"
type="cite">
<div class="WordSection1">
<div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<p class="MsoNormal">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!<o:p></o:p></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<div>
<div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<blockquote
style="border:none;border-left:solid #CCCCCC
1.0pt;padding:0in 0in 0in
6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal">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:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Other
ideas/comments?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="color:#888888"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span
style="color:#888888">Henry<o:p></o:p></span></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal">On 16 Jan
2013, at 22:00, Dolph Mathews
wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
<div>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">-Dolph<o:p></o:p></p>
</div>
<p class="MsoNormal"
style="margin-bottom:12.0pt"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On
Wed, Jan 16, 2013 at
1:57 PM, Brant Knudson
<<a
moz-do-not-send="true"
href="mailto:blk@acm.org" target="_blank">blk@acm.org</a>> wrote:<o:p></o:p></p>
<div>
<p class="MsoNormal">Dolph
-<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<p class="MsoNormal">The
bp mentions
migration, but it
doesn't mention
new installs. Does
a new install
automatically get
the default
domain?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The
bp says that you
can also not have
a default domain,
but the <span
style="font-size:7.0pt;font-family:"Arial","sans-serif";color:#333333">default_domain_id </span>configuration
option has a
default. What do I
set the
configuration
option to if I
don't have a
default domain?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="color:#888888"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span
style="color:#888888">- Brant<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span
style="color:#888888"><o:p> </o:p></span></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal"
style="margin-bottom:12.0pt"><o:p> </o:p></p>
<div>
<div>
<div>
<p
class="MsoNormal">On
Tue, Jan 15,
2013 at 2:42 PM,
Dolph Mathews
<<a
moz-do-not-send="true"
href="mailto:dolph.mathews@gmail.com" target="_blank">dolph.mathews@gmail.com</a>>
wrote:<o:p></o:p></p>
</div>
</div>
<blockquote
style="border:none;border-left:solid
#CCCCCC
1.0pt;padding:0in
0in 0in
6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<div>
<p
class="MsoNormal">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).<o:p></o:p></p>
<div>
<p
class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p
class="MsoNormal">
<a
moz-do-not-send="true"
href="https://blueprints.launchpad.net/keystone/+spec/default-domain"
target="_blank">https://blueprints.launchpad.net/keystone/+spec/default-domain</a><o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p
class="MsoNormal">Feedback
appreciated,<br
clear="all">
<o:p></o:p></p>
<div>
<div>
<p
class="MsoNormal"><o:p> </o:p></p>
</div>
<p
class="MsoNormal">-Dolph<o:p></o:p></p>
</div>
</div>
</div>
<p
class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<div>
<p
class="MsoNormal"
style="margin-bottom:12.0pt">_______________________________________________<br>
OpenStack-dev
mailing list<br>
<a
moz-do-not-send="true"
href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a
moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><o:p></o:p></p>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal"
style="margin-bottom:12.0pt"><br>
_______________________________________________<br>
OpenStack-dev mailing
list<br>
<a
moz-do-not-send="true"
href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a
moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
<p class="MsoNormal">_______________________________________________<br>
OpenStack-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:OpenStack-dev@lists.openstack.org"
target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</div>
<p class="MsoNormal"
style="margin-bottom:12.0pt"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:OpenStack-dev@lists.openstack.org"
target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><o:p></o:p></p>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<p class="MsoNormal">_______________________________________________<br>
OpenStack-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:OpenStack-dev@lists.openstack.org"
target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OpenStack-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>