Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1062821 - [RFE][keystone]: Hierarchical Multitenancy
Summary: [RFE][keystone]: Hierarchical Multitenancy
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-keystone
Version: unspecified
Hardware: Unspecified
OS: Unspecified
Target Milestone: z5
: 7.0 (Kilo)
Assignee: Nathan Kinder
QA Contact: Rodrigo Duarte
Whiteboard: upstream_milestone_kilo-1 upstream_st...
Depends On:
Blocks: 1271123
TreeView+ depends on / blocked
Reported: 2014-02-08 05:04 UTC by RHOS Integration
Modified: 2018-02-08 10:11 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Last Closed: 2017-02-24 17:58:42 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 2323021 None None None 2016-05-13 12:03:11 UTC

Description RHOS Integration 2014-02-08 05:04:56 UTC
Cloned from launchpad blueprint


This blueprint encompases migration to "hierarchical ownership" as described by

Implementation Impact:

- In SQL, the project.domain_id column is is renamed to 'parent_project_id'
- Contents of the domain table must be migrated to the project table, and the domain table dropped
- /v3/domains is exposed as SELECT * FROM project WHERE parent_project_id IS NULL;
- Manager methods for projects (list_projects, etc) rewrite all project ID's as "openstack.<self.parent_project_id>.<>"
- Role assignments to project='openstack' are persisted with a null target (instead of project_id='openstack')

API Impact:

- Everything about domains is deprecated (?)
- GET /v3/projects might return projects with a "children" attribute, containing a list of children (reflecting the entire tree)

Specification URL (additional information):


Comment 4 Udi 2015-06-25 11:03:43 UTC
None of the points mentioned in the description of the RFE seem to be implemented. There is still a "domain" table, projects are not children of the domains etc... Is there more updated documentation for the feature?

Comment 7 Nathan Kinder 2015-07-01 05:53:36 UTC
(In reply to Udi from comment #4)
> None of the points mentioned in the description of the RFE seem to be
> implemented. There is still a "domain" table, projects are not children of
> the domains etc... Is there more updated documentation for the feature?

Have you consulted the HMT spec and the actual API documents?  The initial description of this bug was simply copied from an old proposed blueprint.  Things often change as the spec goes through review and as the feature is implemented.

Features should be tested from an API perspective, so the API docs are the authoritative place to look for documentation on using a feature.  If you want to look inside of the black-box, you should look at the spec (though I would caution against relying on things like internal database structure, as they might change during a release cycle).  The bottom line is to test the API.

Comment 13 Rodrigo Duarte 2016-02-19 19:41:06 UTC
I can see a manual test plan for this in Polarion, but this still not ON_QA yet. I believe the manual tests can be automated in tempest, just need to confirm what is the next step here.

Comment 15 Irina Petrova 2016-05-31 12:56:29 UTC
Hey there,

Can we do a little summary on this BZ?

So far HMT has been implemented upstream in Kilo. [1]

However, we still consider it a Tech Preview in OSP 8 (Liberty). [2]

What's more, it's been in Tech Preview since OSP 7 (Kilo). [3]

This means that HMT should work by default but we are not done testing it just yet, or that it needs some additional settings/configuration?

Also, Pablo Iranzo Gómez created a Solution Article according to which we're expecting HMT in OSP 10. [4] How about we change the BZ Target Release to 10 if that's the case?




Comment 17 Nathan Kinder 2017-02-24 17:58:42 UTC
Nested projects (which is what is being referred to as "Hierarchical Multitenancy" in this bug) is already implemented and tested in OSP10.  Note that some people may expect more from this feature that what the blueprint covers, such as nested quotas and similar functionality in other services.  Those should be handled as separate RFEs against the appropriate components, not here in this Keystone bug.  Closing this as CURRENTRELEASE.

Note You need to log in before you can comment on or make changes to this bug.