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@domain --domain
domain'
Error: Execution of '/usr/bin/openstack user create --format shell
username --enable --password password --email username@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@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@openstack]:
Dependency Keystone_user[openstack-keystone] has failures: true
Warning:
/Stage[main]/Keystone::Roles::Admin/Keystone_user_role[openstack-keystone@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
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
_______________________________________________
OpenStack-operators mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
