Open Stack

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
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



From:   Steve Baker <sbaker at redhat.com>
To:     openstack-dev at 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 <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. 
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 at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140404/ec945898/attachment.html>