Comment 5 for bug 1862050

Neutron does not enforce quotas in such a way that a quota violation like this could never occur. The extent of the issue will vary greatly by deployment architecture, specifically the number of neutron workers that are deployed. If more workers are deployed, this becomes more probable.

This is part of the nature of Neutron as a distributed system. The solution for an issue like this would be to move quota calculations into the database, which would be an intrusive and far-reaching rearchitecture. Neutron does better when it can detect issues rather than having to deal with database-reported issues and retries, so such an architectural change would have a significant negative effect on the reliability and responsiveness of the service at load. I do not believe that the risk of exceeding quota justifies the return on investment for such a change that would prevent minor quota overages.

The quota and consumption are easily available from existing API endpoints. If a deployer was so motivated, a combination of log watching and occasional API polling by a process that conforms to the deployer's business logic would permit these sorts of things to be flagged and alarmed on. I think that would be a sufficient compensating control for the risk of quota overages.