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 <sba...@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 mdel...@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
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev