In the new reservation based quota handling code, the logic for deleting an instance creates a negative reservation at the start of the api call and commits it once the request has been cast to the compute manager:
...
self.compute_rpcapi.terminate_instance(context, instance)
QUOTAS.commit(context, reservations) ...
...
The code does include checks for instance['host'] beign null and InstanceNotFound to catch race conditions if the instance has been deleted
But in the case where a second delete request were processed in the API server before the first request has been processed in the compute manager (for example consider that the compute manager is down and the user makes multiple requests because the first didn’t seem to finish) these checks won’t fail, which will lead to the quota being released each time the commit is processed in the API server.
The fix would seem to be to pass the negative reservations down into the compute manager so that they only get committed when the delete is processed.
In the compute manager the delete requests for an instance are synchronised on the uuid, so a second request won’t run until the first has finished, hence a check at the start to see if the instance still exists and do the rollback there should work OK.
Interestingly, in the special case where the double accounting for the repeated delete causes the in_use count to go negative, then a subsequent attempt to reserve further instance quota will cause the inappropriate in_use value to be healed via the sync logic.