Open Stack

On 07/17/2015 02:49 PM, Ken Johnson wrote:
> Hey all, hoping that someone else might be running into this too... 
> Right now I'm in the process of trying to get Keystone deployed, set 
> up for v3 API usage, with multiple identity backends (specifically, a 
> SQL backed default domain for service accounts, and another backed by 
> LDAP for users). I've had luck so far using the Keystone module to get 
> as far as I can and then doing the not yet supported multi-domain bits 
> with lower level resources... But I'm running into one snag that I've 
> not yet been able to find a workaround for yet.
>
> During runs, after the multi-domain config has been laid down, I'm 
> seeing output like this where an attempt is made to see if the admin 
> user exists, then create the user if not. Polling of existing users 
> fails due to an authentication failure for the user list command, 
> which causes an attempt to create the already extant admin user, which 
> results in the resource failing and following actions being abandoned.
>
> --
>
> Debug: Executing '/usr/bin/openstack user list --quiet --format csv 
> --long'
> Error: Could not prefetch keystone_user provider 'openstack': Could 
> not authenticate.
> Debug: Executing '/usr/bin/openstack user create --format shell 
> username --enable --password password --email username at domain --domain 
> domain'
> Error: Execution of '/usr/bin/openstack user create --format shell 
> username --enable --password password --email username at domain --domain 
> domain' returned 1: ERROR: openstack Conflict occurred attempting to 
> store user - Duplicate Entry (HTTP 409) (Request-ID: 
> req-1ae18aaf-8a2c-42bd-a456-83303ec668b1)
> Error: 
> /Stage[main]/Keystone::Roles::Admin/Keystone_user[openstack-keystone]/ensure: 
> change from absent to present failed: Execution of '/usr/bin/openstack 
> user create --format shell username --enable --password password 
> --email username at domain --domain domain' returned 1: ERROR: openstack 
> Conflict occurred attempting to store user - Duplicate Entry (HTTP 
> 409) (Request-ID: req-1ae18aaf-8a2c-42bd-a456-83303ec668b1)
> Notice: 
> /Stage[main]/Keystone::Roles::Admin/Keystone_user_role[openstack-keystone at openstack]: 
> Dependency Keystone_user[openstack-keystone] has failures: true
> Warning: 
> /Stage[main]/Keystone::Roles::Admin/Keystone_user_role[openstack-keystone at openstack]: 
> Skipping because of failed dependencies
>
> --
>
> If I look in the Keystone logs I can see the authorization failure.
>
> --
>
> 2015-07-17 10:40:52.922 5155 INFO keystone.common.wsgi [-] GET /users?
> 2015-07-17 10:40:52.922 5155 WARNING keystone.common.controller [-] 
> RBAC: Bypassing authorization
> 2015-07-17 10:40:52.924 5155 WARNING keystone.common.controller [-] 
> Invalid token found while getting domain ID for list request
> 2015-07-17 10:40:52.925 5155 WARNING keystone.common.wsgi [-] 
> Authorization failed. The request you have made requires 
> authentication. from 127.0.0.1

This is not definitive, but I'll take you word on what you are doing.


It would be good to confirm that this is in fact due to the ADMIN_TOKEN 
not having sufficient priviledges to execute the command.  PLease file 
it as a bug, and we';ll look in to it.

>
> --
>
> This only happens with multi-domain configuration in place. Checking 
> out the internals of Keystone, it looks like this happens because when 
> a list request is made in a multi-domain context the token used must 
> have a domain associated with it. Because the provider is using the 
> built in admin token, this domain association doesn't exist. At least, 
> I think that's what's going on, based on what I've read and explored 
> so far.
>
> Was wondering if anyone else had encountered this and come up with a 
> way around it. So far I'm not seeing any satisfying way of dealing 
> with this, but still poking around...
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150722/9c26a4a2/attachment.html>