Opened in Launchpad: https://bugs.launchpad.net/heat/+bug/1302624
I still have concerns though about the design approach of creating a new project for every stack and new users for every resource. 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? 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? 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? -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 From: Steve Baker <sba...@redhat.com> To: openstack-dev@lists.openstack.org Date: 04/03/2014 10:13 PM Subject: Re: [openstack-dev] [heat] Problems with Heat software configurations and KeystoneV2 On 04/04/14 14:05, Michael Elder wrote: 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. 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. 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. - 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. 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. - The change prevents compatibility between Heat on Icehouse and KeystoneV2. 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? _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev