Difference between revisions of "DomainQuotaManagementAndEnforcement"

Revision as of 21:57, 7 June 2013

Launchpad Entry: Domain Quota Management
Created: 03 March 2013
Contributors: Yehia Beyh, Glaucimar Aguiar , Tiago Martins, Akshat Kakkar,

Introduction

In Keystone v3 (Grizzly release), Domains encapsulates users and projects into logical entities that can represent accounts, organizations, etc. Currently there is no capability or mechanism to manage or enforce quotas at domain level. Assigning or updating quota values or limits to a domain will allow the cloud administrator to evaluate domain lists and consumption. In order to achieve these capabilities it will be required to implement quota management for Keystone domains. The goal of this blueprint is to support quotas at the OpenStack Domain level. The design of the feature models, as far as possible, the style of project quotas.

Openstack Quotas

Today OpenStack services make usage of quotas to limit the project resources. For example, the “Instances” quota represents the number of instances that can be created in a project. The table below summarizes the existing project quotas.

quotas	type	default values	description
nova.instances	reservable	10	number of instances allowed per project
nova.cores	reservable	20	number of instance cores allowed per project
nova.ram	reservable	50*1024	megabytes of instance ram allowed per project
nova.floating_ips	reservable	10	number of floating ips allowed per project
nova.fixed_ips	reservable	-1	number of fixed ips allowed per project
nova.metadata_items	absolute	128	number of metadata items allowed per instance
nova.injected_files	absolute	5	number of injected files allowed
nova.injected_files_content_bytes	absolute	10*1024	number of bytes allowed per injected file
nova.injected_file_path_bytes	absolute	255	number of bytes allowed per injected file path
nova.security_groups	reservable	10	number of security groups per project
nova.security_groups_rules	countable	20	number of security rules per security group
nova.key_pairs	countable	100	number of key pairs per user
cinder.volumes	reservable	10	number of volumes allowed per project
cinder.snapshots	reservable	10	number of volume snapshots allowed per project
cinder.gigabytes	reservable	1000	number of volume gigabytes (snapshots are also included) per project
quantum.network	countable	10	Number of networks allowed per tenant
quantum.subnet	countable	10	Number of subnets allowed per tenant
quantum.port	countable	50	number of ports allowed per tenant

User Stories

Domain Quotas might impact partitioned OpenStack deployments (regions, cells, etc). Here we consider only the impact on regions. These can be

Per–Region domain quotas
Across region domain quotas

The 1st approach works similar to the current implementation of quotas per project; in a multi-region scenario, the domain quotas are enforced by each service in a non-centralized fashion. The 2nd approach, a domain quota is shared dynamically among regions, e.g. if a service from a given region needs more quota than the others, it requests more quotas. This blueprint addresses the per–region domain quotas. The user stories are listed below:

As a cloud administrator, I want to create a domain with default domain quotas
As a cloud/domain administrator, I want to see the domain quotas for a domain in a region
As a cloud/domain administrator, I want to see the domain quotas usage for a domain in a region
As a cloud administrator, I want to update the quotas for a domain in a region
As a cloud administrator, I want to delete the quotas for a domain in a region

Since quotas deals with sensible aspects of resource consumption, we identified the need to log the interactions of users when they manage domain quotas.

Design

Our proposal have 2 main blocks: one in keystone we are calling the Domain Quota Proxy (DQP), the other we are calling Domain Quota Driver (DQD). The DQP is responsible to give to user one point of domain quota management, so it acts as a proxy. The DQP is a set of extensions that can be improved to serve as a single point of management for other quotas. The DQD is a piece of code located in the quota module of Nova, Cinder and Quantum projects, and it's designed in the same fashion as the other drivers present in such module.

Quota modules need to be refactored to add DQD. Also we should extend the services REST API to provide domain quotas usage to Domain Quota Proxy. The DQP is designed to be implemented as a discrete extension and not included in the default pipeline of Keystone. The Domain Quota Driver design is similar to the current quota driver from quota.py module, given the possibility to the user to option to use it or not; they will be responsible to enforce all quotas listed in the table above in the context of domains.

REST API

This gives an option of getting quota for all domains. Region is optional, if not informed, it returns for all regions. When parameter "?usage=yes" is informed, the usage is returned.

GET v3/os-domain-quotas
Content-Type application/json
Accept application/json

Request:

 
{
    "quota_set":{  
	      "region": "regionOne"
              "nova": [
                      "instances",  "floating_ips"
               ]
              "cinder": [
                       "volumes","gigabytes"
               ]               
    }         
 }