yahoo-eng-team team mailing list archive

[Dolph Mathews <1442663@xxxxxxxxxxxxxxxxxx>]

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