In the first version of Hierarchical Multitenancy (kilo-1), a project deletion was allowed only for leaf projects in the hierarchy. With this restriction, it is necessary to delete projects one by one (starting from the leafs) in order to delete a whole hierarchy branch.
For example, considering the following hierarchy:
+------------------------+
| A |
| |
| / \ |
| |
| / \ |
| |
| B C |
| |
| / \ / \ |
| |
| / \ / \ |
| |
| D E F G |
+------------------------+
To delete project B and its subtree, the user would need to first delete projects D and E.
In addition, the subtree deletion/disabling needs to be performed as an atomic operation.
This spec proposes the implementation of an API to perform a whole tree deletion, which will allow the user to specify a project that is not a leaf in the hierarchy for removal. In this way, the project itself along with its whole subtree will be deleted.
In order to delete a project, it must be first disabled. Currently, this follows the same behavior as the project deletion: the user would have to manually disable the project’s children to disable a project that is in a higher level of the hierarchy (the project hierarchy doesn’t follow the same behavior as deleting domains, which has cascade effect by default). Thus, this spec also proposes changes to allow the disabling of a whole hierarchy branch within a single operation:
Both features lead to access privileges concerns: a user could have delete and
update privileges for a project in a higher level of the hierarchy and not to
some projects in its subtree. Although we could insist that the caller of a
recursive operation has the delete_project and update_project permissions on
every project, it is more likely that in practice a cloud provider will want to
reserve such operations to a very restricted set up users/roles. For this
reason, there is the need for new rules in the keystone policy.json
file
and, therefore, new API endpoints to represent these actions.
The new APIs for the delete and update requests can have the following format:
Specifying cascade
indicates that the request should also be applied to all
children in the hierarchy. Note that for the update request, the enabled
field is mandatory and the only accepted attribute. Including other
attributes will raise an error - this results in the need of creating
additional calls in keystone’s controller layer to be protected by the new
rules.
With the Reseller spec, domains are projects, in this way we have the following behavior:
is_domain = false
). If we trigger the recursive actions on a
“pure” project we are certain it will never hit a domain as per consequence
of the point above. This behavior can be changed by updating the rule in
keystone’s policy file.For leaf domains, the cascade
APIs have the same effect as the regular
update and delete domain operations, but they will be enforced by different
rules in the policy file.
Use a different approach for enabling/disabling:
Don’t add a new rule in the policy file:
New rules in the policy.json file to control the access to the recursive deletion and disabling of projects/domains.
A pycadf notification should be triggered for each project that is deleted or effectively disabled/enabled - they will be triggered from child to parent, this way the quota driver in other service can process the notification properly when freeing the quota to its parent project.
New behavior when deleting/disabling a project/domain along with new rules in the policy.json file.
None
None
None
None
API Documentation (Identity API v3)
Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.