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