Bug 1000928 - OpenStack (And Neutron specifically) don't delete resources when a tenant is deleted
OpenStack (And Neutron specifically) don't delete resources when a tenant is ...
Status: CLOSED WONTFIX
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-neutron (Show other bugs)
3.0
x86_64 Linux
medium Severity medium
: ---
: 6.0 (Juno)
Assigned To: Assaf Muller
Ofer Blaut
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-26 03:00 EDT by yfried
Modified: 2016-04-26 14:23 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-01-07 08:36:55 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
keystone and quantum log files (12.75 KB, application/gzip)
2013-08-26 03:00 EDT, yfried
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Launchpad 967832 None None None Never

  None (edit)
Description yfried 2013-08-26 03:00:27 EDT
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-11-30 23:49:19 EST
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 03:36:55 EST
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 05:11:01 EST
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 04:17:35 EST
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 08:36:55 EST
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.

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