yahoo-eng-team team mailing list archive

[Lance Bragstad <lbragstad@xxxxxxxxx>]

The change referenced in the description [0] includes tests for
duplicate projects via direct and indirect assignments [1]. This should
be testing the code in question.

I ran the tests locally and ensured there were't duplicate projects or
domains as a result of the API. Are you able to recreate this with a
test of some kind?

[0] https://review.openstack.org/#/c/284943/63
[1] https://github.com/openstack/keystone/blob/bebd7056ad33d294871013067cb7367bc6db1a13/keystone/tests/unit/test_v3_federation.py#L3069-L3132

** Changed in: keystone
       Status: New => Invalid

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1701324

Title:
  Removing duplicated items doesn't work in case of federations

Status in OpenStack Identity (keystone):
  Invalid

Bug description:
  In commit eed233cac8f34ce74a2f6fa989c484773c491df3 "Concrete role assignments for federated users" there was added handling of federation-related objects. In that implementation objects like roles, projects and domains were aggregated from 2 sources - from appropriate tables directly and from federation-related hooks.
  This mechanism can lead to situation when there's duplication of objects, so for such cases code for filtering out duplicates was added.

  It was impemented in the following way:

  domains = [dict(t) for t in set([tuple(d.items()) for d in domains])]

  where domains is a list of dicts, each of which contains information
  about appropriate domain. This code can work fine in some situations
  but in general can work in a wrong way because dict "items" method
  returns key-value pairs in arbitrary order according to
  https://docs.python.org/2/library/stdtypes.html#dict.items. So, this
  code may remain unchanged list of 2 similar dicts where items listed
  out in a different order.

  This code was introduced in upstream Thu Feb 25 21:39:15 2016, so it
  seems that this code remains in newton and ocata and master branch.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1701324/+subscriptions