Bug 1000928

Summary: OpenStack (And Neutron specifically) don't delete resources when a tenant is deleted
Product: Red Hat OpenStack Reporter: yfried
Component: openstack-neutronAssignee: Assaf Muller <amuller>
Status: CLOSED WONTFIX QA Contact: Ofer Blaut <oblaut>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0CC: chrisw, lpeer, mnewby, yeylon
Target Milestone: ---   
Target Release: 6.0 (Juno)   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-01-07 13:36:55 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
keystone and quantum log files none

Description yfried 2013-08-26 07:00:27 UTC
Created attachment 790309 [details]
keystone and quantum log files

Description of problem:
after deleting a tenant, networks and security groups connected to it still remain

Version-Release number of selected component (if applicable):
openstack-quantum-2013.1.3-1.el6ost.noarch
openstack-keystone-2013.1.3-1.el6ost.noarch

How to Reproduce:

1. list networks and security groups

# quantum security-group-list 
+--------------------------------------+---------+-------------+
| id                                   | name    | description |
+--------------------------------------+---------+-------------+
| 5c9a0922-0f92-497f-8d70-8ce7ccf8f3b0 | default | default     |
| 96b4c613-1666-4a4a-84df-cb7ebd86eba4 | default | default     |
+--------------------------------------+---------+-------------+

2. create a tenant

# keystone tenant-create --name test_tenant
+-------------+----------------------------------+
|   Property  |              Value               |
+-------------+----------------------------------+
| description |                                  |
|   enabled   |               True               |
|      id     | 73a8b7ac93f84519b2afddc553191790 |
|     name    |           test_tenant            |
+-------------+----------------------------------+

3. create a network under this tenant

# quantum net-create test_net --tenant-id 73a8b7ac93f84519b2afddc553191790
Created a new network:
+---------------------------+--------------------------------------+
| Field                     | Value                                |
+---------------------------+--------------------------------------+
| admin_state_up            | True                                 |
| id                        | b7a2d9b6-273e-463d-9cd5-79016b25618f |
| name                      | test_net                             |
| provider:network_type     | vlan                                 |
| provider:physical_network | inter-vlan                           |
| provider:segmentation_id  | 204                                  |
| router:external           | False                                |
| shared                    | False                                |
| status                    | ACTIVE                               |
| subnets                   |                                      |
| tenant_id                 | 73a8b7ac93f84519b2afddc553191790     |
+---------------------------+--------------------------------------+

# quantum security-group-list 
+--------------------------------------+---------+-------------+
| id                                   | name    | description |
+--------------------------------------+---------+-------------+
| 5c9a0922-0f92-497f-8d70-8ce7ccf8f3b0 | default | default     |
| 829d97da-0e01-4e2a-bf0b-5669bf522834 | default | default     |
| 96b4c613-1666-4a4a-84df-cb7ebd86eba4 | default | default     |
+--------------------------------------+---------+-------------+

4. delete the tenant

# keystone tenant-delete test_tenant

Actual results:
network and security group remain

# quantum net-list
+--------------------------------------+----------+---------+
| id                                   | name     | subnets |
+--------------------------------------+----------+---------+
| b7a2d9b6-273e-463d-9cd5-79016b25618f | test_net |         |
+--------------------------------------+----------+---------+

# quantum security-group-list 
+--------------------------------------+---------+-------------+
| id                                   | name    | description |
+--------------------------------------+---------+-------------+
| 5c9a0922-0f92-497f-8d70-8ce7ccf8f3b0 | default | default     |
| 829d97da-0e01-4e2a-bf0b-5669bf522834 | default | default     |
| 96b4c613-1666-4a4a-84df-cb7ebd86eba4 | default | default     |
+--------------------------------------+---------+-------------+


Expected results:
network and security group should be deleted as well since they are no longer usable

Comment 2 Maru Newby 2013-12-01 04:49:19 UTC
Keystone is not responsible for triggering resource cleanup in related projects, only for providing identity-related services.  The general pattern for working around this limitation is to have a management application that manages resource removal from other projects as part of the tenant removal process (e.g. Horizon).

The upstream bug that was filed duplicated an existing bug that was deemed 'not a bug' by the Mark McClain, the Neutron PTL.  I recommend this bug be similarly closed since the fault does not lie with Neutron, or at least retargeted towards a deployment/management mechanism that would enable Keystone events to trigger deletion of Neutron resources.

Comment 3 Assaf Muller 2013-12-03 08:36:55 UTC
Keystone can now (Since Havana) send notifications when tenants are deleted:
http://docs.openstack.org/developer/keystone/event_notifications.html

Another approach would be for Horizon to send out those notifications (And correct me if I'm wrong but it currently can't?).

In any case, are we aware of anyone taking responsibility, writing the blueprint and committing to implement this for Icehouse?

Comment 4 lpeer 2013-12-03 10:11:01 UTC
The mechanism is not available u/s yet, postponing to RHOS 5.0

(In reply to Assaf Muller from comment #3)
> In any case, are we aware of anyone taking responsibility, writing the
> blueprint and committing to implement this for Icehouse?

We need to see if keystone is already generating these events and if so submit a blueprint to listen on the event and clean up the Neutron entities.

Comment 5 Assaf Muller 2014-01-01 09:17:35 UTC
Status update:
Opened upstream bug - https://bugs.launchpad.net/neutron/+bug/967832

Keystone emits notifications for project/tenant deletion, already merged in Havana. Currently no project listens to these events. I'll start working on it in Neutron.

Comment 6 Assaf Muller 2015-01-07 13:36:55 UTC
The proposed solution is to use stackforge/OSPurge.

Alternatively, each cloud wraps or integrates tenant management with its own external solution. For example, public clouds integrate billing with tenant management. When a user requests to delete his account, normally his details aren't actually deleted, just frozen, so that his account may be re-enabled in the future. In private clouds, you *may* want to let OpenStack actually delete tenant resources automatically. Since tenant management is such a complicated, per-cloud, and inherently IT/management domain specific, it looks like the upstream consensus is not to solve this issue at this time. In any case, there is nothing downstream specific about this issue, so there's no reason whatsoever to keep this bug open.