<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br><div><br></div></div><div><br>On Apr 3, 2014, at 8:40 PM, Steve Baker <<a href="mailto:sbaker@redhat.com">sbaker@redhat.com</a>> wrote:<br><br></div><blockquote type="cite"><div>
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<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.</div></blockquote><div><br></div><div>I don't believe this statement reflects a grasp of our current reality.</div><div><br></div><div>There is no such thing as a typical Icehouse installation yet -- it is not even released. And when we went to document v3 Keystone API for ops we couldn't find enough info for deployments. </div><div><br></div><div>- client support is not documented with Openstack client examples</div><div>- users and ops find your explanatory concept docs for roles and domains lacking</div><div>- best practices and service catalog explanations are not useful or not yet written to my knowledge </div><div><br></div><div>Joe Topjian can explain more about operators needs here, hopefully he'll have more details to add. </div><br><blockquote type="cite"><div>
Can you explain the reasons why yours isn't?<br>
<br>
</div></blockquote><div><br></div>For all the reasons above and more.<div><br></div><div>Anne <br><div><blockquote type="cite"><div><span>_______________________________________________</span><br><span>OpenStack-dev mailing list</span><br><span><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a></span><br><span><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></span><br></div></blockquote></div></div></body></html>