Tenant Deletion Workflow
Deleting a tenant has numerous repercussions (removing all users from it, revoking roles, cleaning up instances/
[vkmc] STATUS ON 2014-03-26 - Still blocked. Looking for different approaches to address this while keeping an eye on the realtime communication and trusts and impersonation features.
[lblanchard 2014-03-06] Just curious about the status on this. After chatting with an operator, it sounds like this is an important feature to him and I'm wondering if it will be targeted in Juno based on the status of the blockers in the two different discussed approaches.
[vkmc] STATUS ON 2013-07-04 - This blueprint is currently blocked. Several different approachs has been discussed to implement this feature. Those are,
- Using realtime communication to broadcast the deletion messages (Depends on https:/
- Using trusts and impersonation (Depends on this feature development and on the upgrade to Keystone v3)
[vkmc]  STATUS ON 2013-03-12 - Most services doesn't allow listing resources per tenant, so we're unable to implement this feature yet. Currently there are bugs filed for Nova and Glance to fix this issue, but others services are pending.
[jogo] -- This sounds like something that should be done in Keystone, so the same workflow would happen via the CLI as well. -- 2013-3-1
[gabriel] -- Bumping this out of Grizzly since it's not time-critical and there isn't code yet. If a finished review is ready in the next week I'll happily reconsider but for release management purposes it's not a blocker. No pressure. -- Feb. 12
[chmouel] For swift it would be nice on tenant deletion to do a swift delete --al (or equivalent on API from horizon) before deleting the tenant or things would be kept around forever.
Tenant deletion workflow is expected to be accomplished in two stages in order to simplify initial work, achieve the expected behavior and, with some luck, stick to G3 release date.
Stage one (v1) involves only the deletion of the tenant, making sure that after deletion everything remains as the tenant haven't been created. Note that every resource associated with the tenant is deleted.
Stage two (v2) is intended to add functionality and allow the user to reassign resources to an existing tenant.
Ask the user action involves the following options
- Moving to another tenant
# Services affected by tenant deletion #
Instances - https:/
 Nova list ignores --tenant argument - https:/
 Reseller role can be used for this but a curl call is needed. Still looking alternatives for this.
 Filtering by owner is implemented in v2, but not yet in v1 - https:/
- Keystone (! Needs update)
Users - No need to remove the user. Users can live in the system without having an associated tenant. e.g. on user creation
Roles - Roles depends on the existence of the tenant. That is, a user has a specific role within a tenant. So that mapping must to be removed both in v1 and v2.
keystone user-role-remove --user-id <user-id> --role-id <role-id>
- Quantum (! Needs update)
Security groups rules *
Health monitor *
As suggested by jpich, tenants for specific networks can be defined. In that case, should a network be deleted when deleting the tenant?
- Cinder (! Needs update)
# RFC #
Swift: Should we consider letting the user to reassign folders and files separately?
That may be prone to errors!
Nova: Agents, Aggregates, x509 Certs, Cloudpipes
Keystone: EC2 Credentials/Other Credentials, Endpoints
This resources are available from the clients but not yet from Horizon. Should they be taken into account when deleting a tenant?
As suggested by gabrielhurley, start deleting anything from the dashboard that you can't *see* from the dashboard is not the best idea.
I agree with that, so those items will not be considered for this release.
# Actions people might want to take on remaining resources #
As mentioned before, we considered two cases.
One of them is the simplest approach and consist on complete removing everything associated with the tenant, the other is more sophisticated and would ask the user if he wants to reuse some of the resources with other tenant, or simply delete them.
Another option could be letting the user to create a new tenant and assign resources to it, or store it to a temporary place in order to allow he to reorganize his projects with ease.
# Now working on... #
It's not possible to access to resources per tenants with the APIs; most of them use cURL calls to do so.
We would need a "super-admin" user able to get all the resources associated to a tenant and that way be able to remove them.
Currently the user needs to have the admin role in the tenant he wants to delete to be able to delete attached resources.
# UI Mockups #
This mockups has been done with the help of an interaction designer.
Suggestion, ideas and comments are more than appreciated.
Addressed by: https:/
Tenant Deletion Workflow
Making a plan for what needs to be cleaned up when deleting a project: DONE
Discuss actions people might want to take on remaining resources: DONE
Lay out how the interface would look: DONE