Race failure to delete security group
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
grenade |
Fix Released
|
Undecided
|
Matt Riedemann | ||
python-openstackclient |
Fix Released
|
Medium
|
Matt Riedemann |
Bug Description
Grenade tries to delete a server and the security group used for that server in succession and there is a race where the security group is still associated with the instance when the DELETE request comes in to nova-api:
The server delete request comes in here:
2015-05-28 20:14:56.024 INFO nova.osapi_
And a second later the security group request comes in and fails:
2015-05-28 20:14:57.351 DEBUG nova.api.
2015-05-28 20:14:57.390 INFO nova.api.
--
Checking the n-net logs on the instance uuid, we see network deallocation happening here:
2015-05-28 20:14:57.376 DEBUG nova.network.
2015-05-28 20:14:57.423 DEBUG nova.network.
And finishes up here:
2015-05-28 20:14:57.795 INFO nova.network.
In the compute API, it's doing local delete by calling instance.destroy() which calls the instance_destroy() DB API method, and that goes through the related associations, like security groups, and deletes them:
http://
The odd thing is, if this is a local delete the grenade run shouldn't have come back to the caller until the server delete request is complete and gets a 204 back, and then when it goes to issue the security group delete, that should already be gone. This isn't an RPC cast from what I can tell.
description: | updated |
Changed in python-openstackclient: | |
status: | New → Confirmed |
assignee: | nobody → Matt Riedemann (mriedem) |
Changed in grenade: | |
status: | New → Confirmed |
Changed in python-openstackclient: | |
milestone: | none → m12 |
Changed in python-openstackclient: | |
importance: | Undecided → Medium |
status: | Fix Committed → Fix Released |
Changed in grenade: | |
assignee: | nobody → Matt Riedemann (mriedem) |
status: | Confirmed → In Progress |
Changed in grenade: | |
status: | Fix Committed → Fix Released |
Apparently this is also not a big deal since it happens in nearly every grenade run:
http:// logstash. openstack. org/#eyJzZWFyY2 giOiJtZXNzYWdlO lwibm92YV9ncmVu YWRlIG5vdmFfZ3J lbmFkZV0gSFRUUC BleGNlcHRpb24gd Ghyb3duOiBTZWN1 cml0eSBncm91cCB pcyBzdGlsbCBpbi B1c2VcIiBBTkQgd GFnczpcInNjcmVl bi1uLWFwaS50eHR cIiIsImZpZWxkcy I6W10sIm9mZnNld CI6MCwidGltZWZy YW1lIjoiNjA0ODA wIiwiZ3JhcGhtb2 RlIjoiY291bnQiL CJ0aW1lIjp7InVz ZXJfaW50ZXJ2YWw iOjB9LCJzdGFtcC I6MTQzMjkxMDkwO TE5OX0=