Updating a project's domain_id can create an illegal project hierarchy
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Identity (keystone) |
Fix Released
|
Medium
|
Henrique Truta |
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.
Changed in keystone: | |
status: | New → Confirmed |
Changed in keystone: | |
status: | Confirmed → Fix Committed |
importance: | Undecided → Medium |
milestone: | none → mitaka-3 |
assignee: | nobody → Henrique Truta (henriquetruta) |
Changed in keystone: | |
status: | Fix Committed → Fix Released |
Another option, instead of 2) above is that we would spot the error on migrate and fail the migration, and ask them to run keystone-manage with a special command that could give them an interactive option in terms of what to do about assignments and splitting etc. I kind of think this is not worth it, since I'm not sure what really options they have except a straightly split.