Quota Support

Registered by Michael Basnight

Reddwarf should support the ability to set Quotas for resources such as Instances, Databases, Users, at the Tenant level.

Ideally, we should integrate with an already existing solution in Openstack. The following look to be a good place to start:



Blueprint information

Nikhil Manchanda
Vipul Sabhaya
Steve Leon
Series goal:
Accepted for grizzly
Milestone target:
Started by
Michael Basnight
Completed by
Michael Basnight

Related branches



The requirement for quota is to have a engine that will manage reddwarf resources (instance, volume) by controlling, reserving and recording resources used and reserved by tenants.

For every provisioning action, the quota engine will be invoke to check the current available resources for that tenant and reserve the resources requested if available. Once the resources are reserved, the provisioning action is performed. The result of the action will determine whether the reserved resources are committed or rolled back. If the action succeeds, the resources are committed. If it doesn't, they are rolled back.

During the reservation, the quota-engine will check the current used and reserved resources and compare them to the hard-limit for that tenant. If the sum of the used + reserved resources is greater than the hard-limit, an overlimit error will be raised.

Currently there are only two type of resources defined: instances and volumes. The quota-engine will only run for create/delete instances and resize volume for now.

All tenants will have a default hard limit for every resource. This default value is configured in the config file. When a new hard-limit value is given for a tenant, this value is recorded in the DB.

The API to obtain the quota limits for a tenant is GET /mgmt/quotas/{tenant-id}.
The API to update the quota limits for a tenant is PUT /mgmt/quotas/{tenant-id} with a body of:
    "quotas": {
        "instances": "new_instance_limit",
        "volumes": "new_volume_limit"
Note that his API calls are management-only. So you will need admin privileges to access them.

The quota-engine will be designed to be run via a decorator. This keeps the actual provisioning logic to be separate and untouched by the quota feature and therefore be much cleaner and less prone to new bugs. In addition, this will also make the quota feature easily bypassed or disabled.

So any request that create/delete instances or resize volume will be intercepted at the model layer by the decorator and the quota-engine is invoked. Once the reservation is made, the provision of resources will execute in the model layer as it normally did. When it finishes, the quota-engine in the decorator will finalize the resources, either by committing them or rolling them back.

Some changes have been made to the management client. This will allow to query quotas and update them for different tenants.


Planning and Brain storming
The executive summary is that we need to add a per Tenant Quota feature to the Reddwarf API

As an Admin, we need an API that which allows them to set a specific Quota for a Resource (db instances, security group, etc) in the Reddwarf Context

As a Tenant of Reddwarf, we need to check the Quota during a request to create a new Resource

Current implementations include

Quota.py in Nova invoked at specific times within Nova API

Quota.py in Cinder invoked at specific time within Cinder API

Repose a Java-based proxy style service that guards Resource APIs with a Quota management system

Inputs to Reddwarf implementation

1. Is there any effort underway to come up with a framework or common (oslo) component to manage this?

1.1 If not, should Reddwarf consider taking on proposing a common solution?

2. If we implement an external service akin to Repose, we will need a shared locking mechanism as the further upstream the quota check is from the actual allocation of the resource, the more likelihood we will run into threading issues which will allow Quotas to be violated

3. If we embed it akin to Quota.py in Cinder and Nova, we will be continuing the reinvention of the wheel, however, it will likely be easier to implement a solution that guards against threading issues as it can be invoked just before the allocation of the Resource

3.1. A flavor of this approach would be to use a Decorator and apply this Decorator to functions which allocate resources. Perhaps this can be done in a way which allows other Resource Allocation APIs and share the same Decorator

4. Another option is a middle-ground approach where we use a Service Request Filter (not sure what these are called in Python but they are Servlet Filters). This seems like an option a way to apply a top level filter across all APIs in within the same context.

Your thoughts would be very much appreciated.

PLZ note that the resources used should also be a part of this call. Its seen in the v2 api for /limits in the api ref

Gerrit topic: https://review.openstack.org/#q,topic:bp/quotas,n,z

Addressed by: https://review.openstack.org/21036
    Add quota feature to reddwraf


Work Items

Dependency tree

* Blueprints in grey have been implemented.

This blueprint contains Public information 
Everyone can see this information.


No subscribers.