© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
35a32c5
(Get the code!)
This is only confirmed on xenial Ocata.
When querying the domain, as it loops through users returned from the all user query of LDAP, it tries to create mappings in keystone for any new users.
https:/
This hits the method keystone.
https:/
it then tries to fall back to querying the public_id of the existing local_entity which doesn't exist and hence returns None. However, if it would just return that public_id that just tossed as duplicate from this line, it could work around the issue.
https:/
This is the duplicate being detected, why not just return that duplicate ID rather than having to return a reverse lookup of a potentially non-existent object.
Basically, this customer deletes entries from LDAP, then we delete them from the local_users and users tables, and sometimes forget to remove from id_mappings table as well. This is done manually because there's no way to delete a keystone user w/out the user existing in the ldap backend still. (best practice being to disable the user's accountActive flag and leave them in LDAP)
So, operator error working around one bug is creating what appears to be a new bug when the ldap user is recreated.
When we query the id_mappings table, we found 402 entries in id_mapping table that don't belong to the domain any longer in nonlocal_users table or users table. So, these 402 entries could not be re-created as new ldap users.
To reproduce:
create LDAP domain with user foo and query openstack domain so user foo gets a user entry in keystone.
remove user foo from user and nonlocal_user table in mysql database, leaving entry in id_mappings table.
Try to query domain (openstack user list --domain <ldapdom>), user foo should cause a traceback when it tries to recreate the id_mapping.
Ultimately, I believe we have to cleanup the id_mappings table, however, I believe the invalid assumption at the line below is still worth discussion:
https:/