Open Stack

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

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