yahoo-eng-team team mailing list archive

[Christophe Balczunas <pentatonic@xxxxxxxxx>]

Public bug reported:

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.

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?

** Affects: keystone
     Importance: Undecided
         Status: New


** Tags: 3.4 domain drivers keystone specific

-- 
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):
  New

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.

  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