<font size=2 face="Arial">Hello,</font>
<br>
<br><font size=2 face="Arial">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 size=2 face="Arial">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 size=2 face="Arial">Here's what I've come across:</font>
<br>
<br><font size=2 face="Arial">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 size=2 face="Arial">commit b776949ae94649b4a1eebd72fabeaac61b404e0f</font>
<br><font size=2 face="Arial">Author: Steve Baker <sbaker@redhat.com></font>
<br><font size=2 face="Arial">Date: Mon Mar 3 16:39:57 2014 +1300</font>
<br><font size=2 face="Arial">Change: </font><a href=https://review.openstack.org/#/c/77798/><font size=2 color=blue face="Arial">https://review.openstack.org/#/c/77798/</font></a>
<br>
<br><font size=2 face="Arial">server.py lines 470-471:</font>
<br>
<br><font size=2 face="Arial"> </font><font size=2 color=blue face="Arial">if</font><font size=2 face="Arial">
<i>self</i>.user_data_software_config():</font>
<br><font size=2 face="Arial">
<i>self</i>._create_transport_credentials()</font>
<br>
<br><font size=2 face="Arial">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 size=2 face="Arial"> </font><font size=2 color=blue face="Arial">def</font><font size=2 face="Arial">
<b>_create_user</b>(<i>self</i>):</font>
<br><font size=2 face="Arial"> </font><font size=2 color=#c0c0c0 face="Arial">#
Check for stack user project, create if not yet set</font>
<br><font size=2 face="Arial"> </font><font size=2 color=blue face="Arial">if</font><font size=2 face="Arial">
</font><font size=2 color=blue face="Arial">not</font><font size=2 face="Arial">
<i>self</i>.stack.stack_user_project_id:</font>
<br><font size=2 face="Arial">
project_id = <i>self</i>.keystone().create_stack_domain_project(</font>
<br><font size=2 face="Arial">
<i>self</i>.stack.id)</font>
<br><font size=2 face="Arial">
<i>self</i>.stack.set_stack_user_project_id(project_id)</font>
<br><font size=2 face="Arial"> </font>
<br><font size=2 face="Arial"> </font><font size=2 color=#c0c0c0 face="Arial">#
Create a <u>keystone</u> user in the stack domain project</font>
<br><font size=2 face="Arial"> user_id = <i>self</i>.keystone().create_stack_domain_user(</font>
<br><font size=2 face="Arial">
username=<i>self</i>.physical_resource_name(), ##
HERE THE USERNAME IS SET TO THE RESOURCE NAME</font>
<br><font size=2 face="Arial">
password=<i>self</i>.password,</font>
<br><font size=2 face="Arial">
project_id=<i>self</i>.stack.stack_user_project_id)</font>
<br>
<br><font size=2 face="Arial"> </font><font size=2 color=#c0c0c0 face="Arial">#
Store the ID in resource data, for compatibility with SignalResponder</font>
<br><font size=2 face="Arial"> db_api.resource_data_set(<i>self</i>,
</font><font size=2 color=#00a000 face="Arial"><i>'user_id'</i></font><font size=2 face="Arial">,
user_id)</font>
<br>
<br><font size=2 face="Arial">My concerns with this approach: </font>
<br>
<br><font size=2 face="Arial">- 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><font size=2 face="Arial">- 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>
<br><font size=2 face="Arial">- The change prevents compatibility between
Heat on Icehouse and KeystoneV2. </font>
<br>
<br><font size=2 face="Arial">The change comments were a bit sparse on
the design reasoning behind this approach, and my search of the mail archives
was unsuccessful. </font><a href="http://openstack.markmail.org/search/?q=heat+on+keystone+v2"><tt><font size=2 color=blue>http://openstack.markmail.org/search/?q=heat+on+keystone+v2</font></tt></a>
<br>
<br><font size=2 face="Arial">-M</font>
<br><font size=2 face="sans-serif"><br>
________________________________<br>
Kind Regards,<br>
<br>
Michael D. Elder<br>
<br>
STSM | Master Inventor<br>
mdelder@us.ibm.com | linkedin.com/in/mdelder<br>
<br>
"Success is not delivering a feature; success is learning how to solve
the customer’s problem.” -Mark Cook</font>