Open Stack

Hello,

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. 

I've found that when using software configuration, the KeystoneV2 is 
broken because the server.py#_create_transport_credentials() explicitly 
depends on KeystoneV3 methods. 

Here's what I've come across:

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:

commit b776949ae94649b4a1eebd72fabeaac61b404e0f
Author: Steve Baker <sbaker at redhat.com>
Date:   Mon Mar 3 16:39:57 2014 +1300
Change: https://review.openstack.org/#/c/77798/

server.py lines 470-471:

        if self.user_data_software_config():
            self._create_transport_credentials()

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:


    def _create_user(self):
        # Check for stack user project, create if not yet set
        if not self.stack.stack_user_project_id:
            project_id = self.keystone().create_stack_domain_project(
                self.stack.id)
            self.stack.set_stack_user_project_id(project_id)
 
        # Create a keystone user in the stack domain project
        user_id = self.keystone().create_stack_domain_user(
            username=self.physical_resource_name(),     ## HERE THE 
USERNAME IS SET TO THE RESOURCE NAME
            password=self.password,
            project_id=self.stack.stack_user_project_id)

        # Store the ID in resource data, for compatibility with 
SignalResponder
        db_api.resource_data_set(self, 'user_id', user_id)

My concerns with this approach: 

- 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. 
- 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. 
- The change prevents compatibility between Heat on Icehouse and 
KeystoneV2. 

The change comments were a bit sparse on the design reasoning behind this 
approach, and my search of the mail archives was unsuccessful. 
http://openstack.markmail.org/search/?q=heat+on+keystone+v2

-M

________________________________
Kind Regards,

Michael D. Elder

STSM | Master Inventor
mdelder at us.ibm.com  | linkedin.com/in/mdelder

"Success is not delivering a feature; success is learning how to solve the 
customer’s problem.” -Mark Cook
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140403/1ce81e9c/attachment-0001.html>