Open Stack

> On Apr 3, 2014, at 8:40 PM, Steve Baker <sbaker at redhat.com> wrote:
> 
>> 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.

I don't believe this statement reflects a grasp of our current reality.

There is no such thing as a typical Icehouse installation yet -- it is not even released. And when we went to document v3 Keystone API for ops we couldn't find enough info for deployments. 

- client support is not documented with Openstack client examples
- users and ops find your explanatory concept docs for roles and domains lacking
- best practices and service catalog explanations are not useful or not yet written to my knowledge 

Joe Topjian can explain more about operators needs here, hopefully he'll have more details to add. 

> Can you explain the reasons why yours isn't?
> 

For all the reasons above and more.

Anne 
> _______________________________________________
> 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/700d4ce5/attachment.html>