Cloned from launchpad blueprint https://blueprints.launchpad.net/keystone/+spec/hierarchical-multitenancy. Description: This blueprint encompases migration to "hierarchical ownership" as described by https://wiki.openstack.org/wiki/HierarchicalMultitenancy 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>.<self.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): None
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?
(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.
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.
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? Thanks. --Irina [1] https://blueprints.launchpad.net/keystone/+spec/hierarchical-multitenancy [2] https://access.redhat.com/documentation/en/red-hat-openstack-platform/version-8/users-and-identity-management-guide/#multi-tenenacy [3] https://access.redhat.com/documentation/en/red-hat-enterprise-linux-openstack-platform/version-7/users-and-identity-management-guide/#multi-tenenacy [4] https://access.redhat.com/solutions/2323021
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.