yahoo-eng-team team mailing list archive

[Henry Nash <henryn@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

We introduced hierarchical projects in Kilo. The design (both then and
now) was that a project hierarchy existed in a single domain (i.e. all
the projects in the hierarchy were owned by the same domain).

We also still support (although disabled by default) the ability to
change the domain_id of a user, group or project. This is being marked
as deprecated in Mitaka.

The problem arrises if a cloud deployer changes the config to allow
mutable domain_ids, creates a hierarchy of projects and then changes the
domain of a project in the middle of the hierarchy. The hierarchy is now
not all owned by the same domain.  This ability to change a project that
has children or is not a top level project is being removed in Mitaka
(we should never have allowed it) - but the fact remains that (however
unlikely) someone might have done this in Kilo or Liberty.

The question is what to do about it? About the least bad solution I can
think of would be to do both:

1) Backport the restriction to stop projects having their domain_id
change unless they are a top level project with no children to Liberty
(and maybe Kilo).  We can't back port the deprecation, or course.

2) Add migration code in Mitaka that spotted a "split hierarchy" and
really split the hierarchy (i.e. the two part of the project tree would
hang off their respective domains). To really do that right, we'd have
to duplicate any inherited role assignments.

** Affects: keystone
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1502157

Title:
  Updating a project's domain_id can create an illegal project hierarchy

Status in Keystone:
  New

Bug description:
  We introduced hierarchical projects in Kilo. The design (both then and
  now) was that a project hierarchy existed in a single domain (i.e. all
  the projects in the hierarchy were owned by the same domain).

  We also still support (although disabled by default) the ability to
  change the domain_id of a user, group or project. This is being marked
  as deprecated in Mitaka.

  The problem arrises if a cloud deployer changes the config to allow
  mutable domain_ids, creates a hierarchy of projects and then changes
  the domain of a project in the middle of the hierarchy. The hierarchy
  is now not all owned by the same domain.  This ability to change a
  project that has children or is not a top level project is being
  removed in Mitaka (we should never have allowed it) - but the fact
  remains that (however unlikely) someone might have done this in Kilo
  or Liberty.

  The question is what to do about it? About the least bad solution I
  can think of would be to do both:

  1) Backport the restriction to stop projects having their domain_id
  change unless they are a top level project with no children to Liberty
  (and maybe Kilo).  We can't back port the deprecation, or course.

  2) Add migration code in Mitaka that spotted a "split hierarchy" and
  really split the hierarchy (i.e. the two part of the project tree
  would hang off their respective domains). To really do that right,
  we'd have to duplicate any inherited role assignments.

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