Quota Support
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
- Status:
- Complete
- Approver:
- Nikhil Manchanda
- Priority:
- High
- Drafter:
- Vipul Sabhaya
- Direction:
- Approved
- Assignee:
- Steve Leon
- Definition:
- New
- Series goal:
- Accepted for grizzly
- Implementation:
-
Implemented
- Milestone target:
- None
- Started by
- Michael Basnight
- Completed by
- Michael Basnight
Related branches
Related bugs
Sprints
Whiteboard
Desc
--------
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.
Details
----------
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/
The API to update the quota limits for a tenant is PUT /mgmt/quotas/
{
"quotas": {
"volumes": "new_volume_limit"
}
Note that his API calls are management-only. So you will need admin privileges to access them.
Design
----------
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.
Client
---------
Some changes have been made to the management client. This will allow to query quotas and update them for different tenants.
Wiki
---------
http://
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:/
Addressed by: https:/
Add quota feature to reddwraf
Work Items
Dependency tree
* Blueprints in grey have been implemented.
