Open Stack

On Thu, 2015-12-03 at 12:33 -0800, melanie witt wrote:
> On the parallel request bug [2], if you check out alaski's comment #3,
> he mentions the keypairs and security groups apis check quota without
> using the reservation system. We should investigate why they don't and
> whether we can convert them to use the reservation system. I think
> that would provide a lot of improvement.

So, there are three types of resources defined by the quota system:
ReservableResource, which can be used with reservations;
AbsoluteResource, which is used for things like checking quotas on the
number of injected files (not even any sense *trying* to track that in
the DB :); and a subclass of AbsoluteResource, CountableResource.
Keypairs are a CountableResource, and the __init__() docstring says:

        Countable resources are those resources which directly
        correspond to objects in the database, i.e., instances, cores,
        etc., but for which a count by project ID is inappropriate.  A
        CountableResource must be constructed with a counting
        function, which will be called to determine the current counts
        of the resource.

And sure enough, nova.compute.api.KeypairAPI._validate_new_key_pair()
uses the counting interface.

I believe this came about from a basic limitation with the architecture
of the quotas subsystem, which initially assumed that every resource
would be accounted only to a tenant; this is a mismatch for something
like keypairs, which are associated solely with specific users, or
security group rules, which are associated solely with specific security
groups.

There are exactly three currently defined CountableResource quotas:
security_group_rules, key_pairs, and server_group_members.  I would
guess that all three are prone to race conditions that are not a problem
for other quota types.

(For reference, the AbsoluteResource quotas are metadata_items,
injected_files, injected_file_content_bytes, and
injected_file_path_bytes; everything else is a ReservableResource.)
-- 
Kevin L. Mitchell <kevin.mitchell at rackspace.com>
Rackspace