Closing based on feedback in comment #2
** Tags removed: keystone specific
** Changed in: keystone
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1442663
Title:
Kilo domain config rest feature does not uniformly reload domain
configurations
Status in OpenStack Identity (Keystone):
Invalid
Bug description:
I have been evaluating the new feature in Identity API 3.4, the
ability to specify ldap domain configuration through Rest.
Though I have no problem adding, deleting, modifying the config, what
is not working consistently is the ability for Keystone
(keystone/keystone/identity/core.py) to pick up the actual changes.
For example:
1. I have no config for a domain: GET /domains/123/config
2. I try to authenticate with an ldap user. Fails, as expected.
3. I add a configuration pointing to my valid ldap: PUT /domains/123/config
4. I try to authenticate, and it works.
5. I try again and it works.
6. After a few try, authentication fails. I can see in the keystone.log that
it did not use the ldap driver, but the regular sql one, which explains the
failure.
7. I try again, works.
8. Try a few times, fails, same as #6.
So essentially, there are a few threads in a pool that get initialized
with their copy of DomainsConfig. Depending which thread handles my
particular request, it succeeds depending if that thread's
DomainConfigs has the correct data.
Similarly, if I modify the config (for example to purposely give a
wrong password to the bind user), with PATCH /domains/123/config/456
I find that all the threads that were succeeding earlier continue to
succeed; which in this case is wrong since I have a bad config loaded
up for that domain.
If I restart Keystone, everything always works consistently as per
what is in the database.
A simplified way to reproduce is this:
1. Delete the config ( DELETE /domains/123/config/345)
2. Restart Keystone
3. Attempt authentication with the LDAP user 5 or 6 times. (fails as expected)
4. PUT the config.
5. None of the attempts with the ldap user will succeed. All the threads
of the pool have been initialized already with a DomainConfigs that does not
have this ldap config information.
Looking at the code, I can see in the domains_configured() wrapper, that
nothing gets reloaded because of the "configured" flag, which will be set to
True once that DomainConfigs object has been initialized.
But, isn't the objective of this feature to be able to dynamically
manage the configuration (instead of static files, but also with
Keystone picking up the changes on the fly)?
I have seen explicit calls to "invalidate()" cache in
keystone/keystone/resource/core.py
like: self.get_config_with_sensitive_info.invalidate(self, domain_id)
But.. still the testing results indicate something is not getting
picked up.
This is a Kilo build from about a week and a half ago or so.
Is this a bug? How is the feature intended to work?
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1442663/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
