<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 04/04/14 14:05, Michael Elder wrote:<br>
</div>
<blockquote
cite="mid:OF072999A9.8055EEDA-ON85257CB0.0004D243-85257CB0.0005FFAA@us.ibm.com"
type="cite"><font face="Arial" size="2">Hello,</font>
<br>
<br>
<font face="Arial" size="2">I'm looking for insights about the
interaction
between keystone and the software configuration work that's gone
into Icehouse
in the last month or so. </font>
<br>
<br>
<font face="Arial" size="2">I've found that when using software
configuration,
the KeystoneV2 is broken because the
server.py#_create_transport_credentials()
explicitly depends on KeystoneV3 methods. </font>
<br>
<br>
<font face="Arial" size="2">Here's what I've come across:</font>
<br>
<br>
<font face="Arial" size="2">In the following commit, the
introduction
of _create_transport_credentials() on server.py begins to create
a user
for each OS::Nova::Server resource in the template:</font>
<br>
<br>
<font face="Arial" size="2">commit
b776949ae94649b4a1eebd72fabeaac61b404e0f</font>
<br>
<font face="Arial" size="2">Author: Steve Baker
<a class="moz-txt-link-rfc2396E" href="mailto:sbaker@redhat.com"><sbaker@redhat.com></a></font>
<br>
<font face="Arial" size="2">Date: Mon Mar 3 16:39:57 2014 +1300</font>
<br>
<font face="Arial" size="2">Change: </font><a
moz-do-not-send="true"
href="https://review.openstack.org/#/c/77798/"><font
color="blue" face="Arial" size="2">https://review.openstack.org/#/c/77798/</font></a>
<br>
<br>
<font face="Arial" size="2">server.py lines 470-471:</font>
<br>
<br>
<font face="Arial" size="2"> </font><font color="blue"
face="Arial" size="2">if</font><font face="Arial" size="2">
<i>self</i>.user_data_software_config():</font>
<br>
<font face="Arial" size="2">
<i>self</i>._create_transport_credentials()</font>
<br>
<br>
<font face="Arial" size="2">With the introduction of this change,
each
server resource which is provisioned results in the creation of
a new user
ID. The call delegates through to stack_user.py lines 40-54:</font>
<br>
<br>
<br>
<font face="Arial" size="2"> </font><font color="blue"
face="Arial" size="2">def</font><font face="Arial" size="2">
<b>_create_user</b>(<i>self</i>):</font>
<br>
<font face="Arial" size="2"> </font><font color="#c0c0c0"
face="Arial" size="2">#
Check for stack user project, create if not yet set</font>
<br>
<font face="Arial" size="2"> </font><font color="blue"
face="Arial" size="2">if</font><font face="Arial" size="2">
</font><font color="blue" face="Arial" size="2">not</font><font
face="Arial" size="2">
<i>self</i>.stack.stack_user_project_id:</font>
<br>
<font face="Arial" size="2">
project_id = <i>self</i>.keystone().create_stack_domain_project(</font>
<br>
<font face="Arial" size="2">
<i>self</i>.stack.id)</font>
<br>
<font face="Arial" size="2">
<i>self</i>.stack.set_stack_user_project_id(project_id)</font>
<br>
<font face="Arial" size="2"> </font>
<br>
<font face="Arial" size="2"> </font><font color="#c0c0c0"
face="Arial" size="2">#
Create a <u>keystone</u> user in the stack domain project</font>
<br>
<font face="Arial" size="2"> user_id = <i>self</i>.keystone().create_stack_domain_user(</font>
<br>
<font face="Arial" size="2">
username=<i>self</i>.physical_resource_name(), ##
HERE THE USERNAME IS SET TO THE RESOURCE NAME</font>
<br>
<font face="Arial" size="2">
password=<i>self</i>.password,</font>
<br>
<font face="Arial" size="2">
project_id=<i>self</i>.stack.stack_user_project_id)</font>
<br>
<br>
<font face="Arial" size="2"> </font><font color="#c0c0c0"
face="Arial" size="2">#
Store the ID in resource data, for compatibility with
SignalResponder</font>
<br>
<font face="Arial" size="2"> db_api.resource_data_set(<i>self</i>,
</font><font color="#00a000" face="Arial" size="2"><i>'user_id'</i></font><font
face="Arial" size="2">,
user_id)</font>
<br>
<br>
<font face="Arial" size="2">My concerns with this approach: </font>
<br>
<br>
<font face="Arial" size="2">- Each resource is going to result in
the
creation of a unique user in Keystone. That design point seems
hardly teneble
if you're provisioning a large number of templates by an
organization every
day. </font>
<br>
</blockquote>
Compared to the resources consumed by creating a new nova server (or
a keystone token!), I don't think creating new users will present a
significant overhead.<br>
<br>
As for creating users bound to resources, this is something heat has
done previously but we're doing it with more resources now. With
havana heat (or KeystoneV2) those users will be created in the same
project as the stack launching user, and the stack launching user
needs admin permissions to create these users.<br>
<blockquote
cite="mid:OF072999A9.8055EEDA-ON85257CB0.0004D243-85257CB0.0005FFAA@us.ibm.com"
type="cite"><font face="Arial" size="2">- If you attempt to set
your resource names
to some human-readable string (like "web_server"), you get one
shot to provision the template, wherein future attempts to
provision it
will result in exceptions due to duplicate user ids. </font></blockquote>
<font size="2"><font face="Arial">This needs a bug raised. This
isn't an issue on KeystoneV3 since the users are created in a
project which is specific to the stack. Also for v3 operations
the username is ignored as the user_id is used exclusively.</font></font><br>
<blockquote
cite="mid:OF072999A9.8055EEDA-ON85257CB0.0004D243-85257CB0.0005FFAA@us.ibm.com"
type="cite">
<br>
<font face="Arial" size="2">- The change prevents compatibility
between
Heat on Icehouse and KeystoneV2. </font>
<br>
</blockquote>
Please continue to test this with KeystoneV2. However any typical
icehouse OpenStack should really have the keystone v3 API enabled.
Can you explain the reasons why yours isn't?<br>
<br>
</body>
</html>