<font size=2 face="sans-serif">Opened in Launchpad: </font><a href="https://bugs.launchpad.net/heat/+bug/1302624"><font size=2 color=blue face="sans-serif">https://bugs.launchpad.net/heat/+bug/1302624</font></a>
<br>
<br><font size=2 face="sans-serif">I still have concerns though about the
design approach of creating a new project for every stack and new users
for every resource. </font>
<br>
<br><font size=2 face="sans-serif">If I provision 1000 patterns a day with
an average of 10 resources per pattern, you're looking at 10,000 users
per day. How can that scale? </font>
<br>
<br><font size=2 face="sans-serif">How can we ensure that all stale projects
and users are cleaned up as instances are destroy? When users choose to
go through horizon or nova to tear down instances, what cleans up the project
& users associated with that heat stack? </font>
<br>
<br><font size=2 face="sans-serif">Keystone defines the notion of tokens
to support authentication, why doesn't the design provision and store a
token for the stack and its equivalent management? </font>
<br>
<br><font size=2 face="sans-serif">-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>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">Steve Baker <sbaker@redhat.com></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">openstack-dev@lists.openstack.org</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">04/03/2014 10:13 PM</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">Re: [openstack-dev]
[heat] Problems with Heat software configurations and KeystoneV2</font>
<br>
<hr noshade>
<br>
<br>
<br><font size=3>On 04/04/14 14:05, Michael Elder wrote:</font>
<br><font size=2 face="Arial">Hello,</font><font size=3> <br>
</font><font size=2 face="Arial"><br>
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><font size=3><br>
</font><font size=2 face="Arial"><br>
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><font size=3><br>
</font><font size=2 face="Arial"><br>
Here's what I've come across:</font><font size=3> <br>
</font><font size=2 face="Arial"><br>
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><font size=3> <br>
</font><font size=2 face="Arial"><br>
commit b776949ae94649b4a1eebd72fabeaac61b404e0f</font><font size=3> </font><font size=2 face="Arial"><br>
Author: Steve Baker </font><a href=mailto:sbaker@redhat.com><font size=2 color=blue face="Arial"><u><sbaker@redhat.com></u></font></a><font size=3>
</font><font size=2 face="Arial"><br>
Date: Mon Mar 3 16:39:57 2014 +1300</font><font size=3> </font><font size=2 face="Arial"><br>
Change: </font><a href=https://review.openstack.org/#/c/77798/><font size=2 color=blue face="Arial"><u>https://review.openstack.org/#/c/77798/</u></font></a><font size=3>
<br>
</font><font size=2 face="Arial"><br>
server.py lines 470-471:</font><font size=3> <br>
</font><font size=2 face="Arial"><br>
</font><font size=2 color=blue face="Arial">if</font><font size=2 face="Arial">
<i>self</i>.user_data_software_config():</font><font size=3> </font><font size=2 face="Arial"><br>
<i>self</i>._create_transport_credentials()</font><font size=3>
<br>
</font><font size=2 face="Arial"><br>
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><font size=3> <br>
<br>
</font><font size=2 face="Arial"><br>
</font><font size=2 color=blue face="Arial">def</font><font size=2 face="Arial">
<b>_create_user</b>(<i>self</i>):</font><font size=3> </font><font size=2 face="Arial"><br>
</font><font size=2 color=#c0c0c0 face="Arial">#
Check for stack user project, create if not yet set</font><font size=3>
</font><font size=2 face="Arial"><br>
</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><font size=3> </font><font size=2 face="Arial"><br>
project_id = <i>self</i>.keystone().create_stack_domain_project(</font><font size=3>
</font><font size=2 face="Arial"><br>
<i>self</i>.stack.id)</font><font size=3>
</font><font size=2 face="Arial"><br>
<i>self</i>.stack.set_stack_user_project_id(project_id)</font><font size=3>
</font><font size=2 face="Arial"><br>
<br>
</font><font size=2 color=#c0c0c0 face="Arial">#
Create a <u>keystone</u> user in the stack domain project</font><font size=3>
</font><font size=2 face="Arial"><br>
user_id = <i>self</i>.keystone().create_stack_domain_user(</font><font size=3>
</font><font size=2 face="Arial"><br>
username=<i>self</i>.physical_resource_name(),
## HERE THE USERNAME IS SET TO THE RESOURCE
NAME</font><font size=3> </font><font size=2 face="Arial"><br>
password=<i>self</i>.password,</font><font size=3>
</font><font size=2 face="Arial"><br>
project_id=<i>self</i>.stack.stack_user_project_id)</font><font size=3>
<br>
</font><font size=2 face="Arial"><br>
</font><font size=2 color=#c0c0c0 face="Arial">#
Store the ID in resource data, for compatibility with SignalResponder</font><font size=3>
</font><font size=2 face="Arial"><br>
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><font size=3> <br>
</font><font size=2 face="Arial"><br>
My concerns with this approach: </font><font size=3><br>
</font><font size=2 face="Arial"><br>
- 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=3>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.</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">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>
<br><font size=2 face="Arial"><br>
- The change prevents compatibility between Heat on Icehouse and KeystoneV2.
</font>
<br><font size=3>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>
</font><tt><font size=2>_______________________________________________<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>
</font></tt>
<br>