Version: Folsom on RHEL6.4, openstack-nova-2012.2.2-9.el6ost Scenario: Deletion of the "default" security group while to running instances in the system seems to work (no error/exception, return code 0) but the security group still exists Expected Results: I expected to the deletion to fail with a clear error message/exception, as happens when trying to delete the "default" security group while there are running instances in the system. The api.log shows the following: 2013-02-03 15:27:36 INFO nova.api.openstack.wsgi [req-2426c378-8fa0-4a66-9995-95ad82464c63 ca701680c7af43beb4ccd1a984fc18f3 313731a2ded64cf3baa97b04afd608e6] GET http://10.35.160.29:8774/v2/313731a2ded64cf3baa97b04afd608e6/os-security-groups 2013-02-03 15:27:36 DEBUG nova.api.openstack.wsgi [req-2426c378-8fa0-4a66-9995-95ad82464c63 ca701680c7af43beb4ccd1a984fc18f3 313731a2ded64cf3baa97b04afd608e6] No Content-Type provided in request get_body /usr/lib/python2.6/site-packages/nova/api/openstack/wsgi.py:792 2013-02-03 15:27:36 INFO nova.api.openstack.wsgi [req-2426c378-8fa0-4a66-9995-95ad82464c63 ca701680c7af43beb4ccd1a984fc18f3 313731a2ded64cf3baa97b04afd608e6] http://10.35.160.29:8774/v2/313731a2ded64cf3baa97b04afd608e6/os-security-groups returned with HTTP 200 2013-02-03 15:27:36 INFO nova.osapi_compute.wsgi.server [req-2426c378-8fa0-4a66-9995-95ad82464c63 ca701680c7af43beb4ccd1a984fc18f3 313731a2ded64cf3baa97b04afd608e6] 10.35.160.29 - - [03/Feb/2013 15:27:36] "GET /v2/313731a2ded64cf3baa97b04afd608e6/os-security-groups HTTP/1.1" 200 313 0.101310 2013-02-03 15:27:36 INFO nova.api.openstack.wsgi [req-06ba73b2-a2d1-4e50-be14-674c4d01adb6 ca701680c7af43beb4ccd1a984fc18f3 313731a2ded64cf3baa97b04afd608e6] DELETE http://10.35.160.29:8774/v2/313731a2ded64cf3baa97b04afd608e6/os-security-groups/10 2013-02-03 15:27:36 DEBUG nova.api.openstack.wsgi [req-06ba73b2-a2d1-4e50-be14-674c4d01adb6 ca701680c7af43beb4ccd1a984fc18f3 313731a2ded64cf3baa97b04afd608e6] No Content-Type provided in request get_body /usr/lib/python2.6/site-packages/nova/api/openstack/wsgi.py:792 2013-02-03 15:27:36 WARNING nova.db.sqlalchemy.api [req-06ba73b2-a2d1-4e50-be14-674c4d01adb6 ca701680c7af43beb4ccd1a984fc18f3 313731a2ded64cf3baa97b04afd608e6] Change will make usage less than 0 for the following resources: ['security_groups'] 2013-02-03 15:27:36 DEBUG nova.quota [req-06ba73b2-a2d1-4e50-be14-674c4d01adb6 ca701680c7af43beb4ccd1a984fc18f3 313731a2ded64cf3baa97b04afd608e6] Created reservations ['c6960787-b0e0-49d8-82bb-a6bd794573df'] reserve /usr/lib/python2.6/site-packages/nova/quota.py:697 2013-02-03 15:27:36 AUDIT nova.compute.api [req-06ba73b2-a2d1-4e50-be14-674c4d01adb6 ca701680c7af43beb4ccd1a984fc18f3 313731a2ded64cf3baa97b04afd608e6] Delete security group default 2013-02-03 15:27:36 INFO nova.api.openstack.wsgi [req-06ba73b2-a2d1-4e50-be14-674c4d01adb6 ca701680c7af43beb4ccd1a984fc18f3 313731a2ded64cf3baa97b04afd608e6] http://10.35.160.29:8774/v2/313731a2ded64cf3baa97b04afd608e6/os-security-groups/10 returned with HTTP 202 2013-02-03 15:27:36 INFO nova.osapi_compute.wsgi.server [req-06ba73b2-a2d1-4e50-be14-674c4d01adb6 ca701680c7af43beb4ccd1a984fc18f3 313731a2ded64cf3baa97b04afd608e6] 10.35.160.29 - - [03/Feb/2013 15:27:36] "DELETE /v2/313731a2ded64cf3baa97b04afd608e6/os-security-groups/10 HTTP/1.1" 202 121 0.217429
Can you please clarify the exact command you are using to delete the security group?
I ran the following from the admin user: "nova secgroup-delete default"
After hunting through layers and trying to find out how the segroup-delete implementation avoided deleting the default security group, I discovered it simply does *not* prevent the deletion. The group *does* get 'deleted' (or in this case it is marked as deleted). However, there is code to ensure that the default group is there so it recreates at 'appropriate times' (e.g. when nova secgroup-list) is called. To demonstrate it, simply run nova secgroup-delete, then run 'select deleted, deleted_at, name, user_id from nova.security_groups' from mysql (or whatever is appropriate for the backend database in use). You should see a new record created for each one that is deleted. In short the bug is not simply an expected response problem, but one that causes badness in the database. Fortunately the fix is the same, check the name of the security group before doing anything.
Verified on 2012.2.3-4.el6ost, after the fix deletion of the "default" secgroup ends with error: "ERROR: Unable to delete system group 'default' (HTTP 400) (Request-ID: req-c8bd0c86-bd6f-418f-85ad-1722769f78c5)" In addition, the return code is 127.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHSA-2013-0657.html