Jump to: navigation, search

Difference between revisions of "DomainQuotaManagementAndEnforcement"

Line 4: Line 4:
  
 
== Introduction ==
 
== Introduction ==
In Keystone v3 (Grizzly release), the Domains feature encapsulates users and projects into logical entities that can represent accounts, organizations, etc. However, currently there is no capability or mechanism to manage or enforce quotas at the 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 and quota monitoring for Keystone domains, by which domain usage can be managed and enforced.
+
In Keystone v3 (Grizzly release), the 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.
  
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 (tenant) quotas.
 
  
 
== Openstack Quotas ==
 
== Openstack Quotas ==
A quota sets a limit on the value of some property of an OpenStack service, e.g. In Nova the number of instances that can be created. Currently in OpenStack, quotas are applied at the project or tenant level.  There is also a Grizzly blueprint to introduce quotas at the user level.
+
Today OpenStack services make usage of quotas to limit the project resources.
 +
For examplethe “Instances” quota represents the number of instances that can be created in a project. The table below summarizes the existing project quotas.
  
=== Nova ===
 
For projects, quota controls are available to limit the
 
* Number of instances which may be launched
 
* Number of processor cores which may be allocated
 
* Publicly accessible IP addresses
 
* Amount of RAM that can be allocated in MB
 
* Number of files that can be injected
 
* Maximal size of injected files in bytes
 
* Number of security groups that may be created
 
* Number of rules per security group
 
 
=== Cinder ===
 
From Folsom onwards, the following quotas are managed by Cinder not Nova.
 
* Number of volumes which may be created
 
* Total size of all volumes within a project as measured in GB
 
 
===Quantum Quotas ===
 
For projects, quota controls are available to limit the number of
 
* networks allowed per tenant
 
* subnets allowed per tenant,
 
* ports allowed per tenant,
 
* routers allowed per tenant
 
* floating IPs allowed per tenant
 
 
=== Swift Quotas ===
 
Swift Quota is a production-ready project that is mainly used for controlling the usage of account and containers in OpenStack Swift.
 
* Number of containers per account (example: an account cannot have more than 5 containers)
 
* Number of objects per container (example: a container cannot have more than 100 objects)
 
* Storage capacity per container (example: the size of a container cannot be larger than 100 GB)
 
 
== User Stories ==
 
* As cloud administrator Paul, I want to limit resource usage for a given Organization represented as a Domain.
 
* As cloud administrator Paul, I want to manage resource usage for each Organization.
 
* As organization administrator Mary, I want to track resource usage for my Organization
 
 
== Design ==
 
Usage against Quota limits must be tracked, so if there is a Domain Limit on some property then there must be a corresponding and Domain Usage. Thus, for a Domain Quota, if there is Nova Limit there must also be a Nova Usage and similarly for Cinder and Quantum.
 
 
=== Domain Quotas Conceptual Model ===
 
 
[[Image:DomainQuotasConceptualModel.jpg]]
 
 
=== Quota Operations on Domains ===
 
The quota operations for domains will be part of the Keystone api. This is because domains can span services that are installed on different regions, and it is Keystone that maintains the service catalog of endpoints. This is in contrast to the existing project (tenant) quota operations which are tied to a single service because projects do not span services.
 
Quota Setting Operations
 
 
These operations use quota-sets and usage-sets. A quota_set is a set of name-value pairs that define the domain limits for on service properties.  A usage_set is a time-stamped set of name-value pairs that show the actual usage of the quota-limited service properties.
 
 
==== Create Domain Quota ====
 
 
{| class="wikitable"
 
{| class="wikitable"
 
|-
 
|-
! Verb !! URI !! Description
+
! quotas !! type !! default values !! description
 
|-
 
|-
| POST || v3/{domain_id}/os-domain-quotas || Uses the request body quota-set to create a quota_set and a corresponding empty usage_set for the domain. Fails if an attempt is to set some quota lower than the current usage. Can be called by Cloud admin only.
+
| nova.instances || reservable|| 10|| number of instances allowed per project
|}
+
|-
 
+
| nova.cores|| reservable|| 20|| number of instance cores allowed per project
Normal Response Code: 200. Error Response Codes: Unauthorized (401), Forbidden (403), Conflict (409)
+
|-
This operation requires a request body. This operation returns a response.
+
| nova.ram || reservable || 50*1024|| megabytes of instance ram allowed per project
 
+
|-
==== Show Domain Quota ====
+
| nova.floating_ips || reservable || 10 || number of floating ips allowed per project
{| class="wikitable"
+
|-
 +
| 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
 
|-
 
|-
! Verb !! URI !! Description
+
| cinder.gigabytes || reservable || 1000 || number of volume gigabytes (snapshots are also included)  per project
 
|-
 
|-
| GET || v3/{domain_id}/os-domain-quotas || Returns the current quota-set for the domain. Can only be called by cloud admin or an admin for the domain.
+
| quantum.network || countable || 10 || Number of networks allowed per tenant
|}
 
 
 
Normal Response Code: 200. Error Response Codes: Unauthorized (401), Forbidden (403)
 
This operation does not require a request body. This operation returns a response.
 
 
==== Update Domain Quota ====
 
{| class="wikitable"
 
 
|-
 
|-
! Verb !! URI !! Description
+
| quantum.subnet || countable || 10 || Number of subnets allowed per tenant
 
|-
 
|-
| PATCH || v3/{domain_id}/os-domain-quotas || Uses the request body quota-set to update the quota_set for the domain.  Fails if an attempt is to set some quota lower than the current usage. Can be called by Cloud admin only.
+
| quantum.port || countable || 50 || number of ports allowed per tenant
 
|}
 
|}
  
Normal Response Code: 200. Error Response Codes: Unauthorized (401), Forbidden (403), Conflict (409)
+
== User Stories ==
This operation requires a request body. This operation returns a response.
+
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
'''Example 1. quota-set  Response: JSON'''
+
# Across region domain quotas
  
<pre><nowiki>
+
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.
{'quota_set':  {'domain_id': 72415820-8b69-11e0-9b19-734f6acf67565,
+
This blueprint addresses the per–region domain quotas. The user stories are listed below:  
                {'nova_quota_set':
+
:* As a cloud administrator, I want to create a domain with default domain quotas
                  {'volumes': 200,
+
:* As a cloud/domain administrator, I want to see the domain quotas for a domain in a region
                  'floating_ips': 100,
+
:* As a cloud/domain administrator, I want to see the domain quotas usage for a domain in a region
                  'instances': 500,
+
:* As a cloud administrator, I want to update the quotas for a domain in a region
                  'injected_files': 50,
+
:* As a cloud administrator, I want to delete the quotas for a domain in a region
                  'cores': 600}},
 
                {'cinder_quota_set':  
 
                  {'volumes': 100,
 
                  'gigabytes': 120000}},
 
                {'quantum_quota_set':  
 
                  {'networks': 150,
 
                  'subnets': 150,
 
    'routers': 30}},
 
                {'swift_quota_set':
 
                  {'containers': 20,
 
                  'objects': 100
 
    'storage_capacity': 1000}}
 
  }
 
  }
 
</nowiki></pre>
 
  
==== Delete Domain Quota ====
+
Since quotas deals with sensible aspects of resource consumption, we identified the need to log the interactions of users when they manage domain quotas.
  
{| class="wikitable"
+
== Design ==
|-
+
The proposal is to extend Keystone and existing service quota drivers to support the domain quotas management and enforcement. The following figure depicts the high level architecture.
! Verb !! URI !! Description
 
|-
 
| DELETE || v3/{domain_id}/os-domain-quotas || Deletes any existing quota_set and usage_set for the domain. Can be called by Cloud admin only.
 
|}
 
  
Normal Response Code: 200. Error Response Codes: Unauthorized (401), Forbidden (403).
+
Our idea is to concentrate the REST APIs in the Domain Quota Proxy which will be in charge of:  
This operation does not require a request body. This operation does not return a response.
+
• Distributing domain quotas to the services
 +
• Gathering domain quotas usage from the services
 +
Quota modules need to be refactored to add a driver to enforce domain quotas. Also we should extend the services REST API to provide domain quotas usage to Domain Quota Proxy. The Domain Quota Proxy 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.  
  
==== Show Domain Usage ====
+
===REST API===
{| class="wikitable"
+
GET v3/os-domain-quotas
|-
+
This gives an option of getting quota for all domains. Region is optional.
! Verb !! URI !! Description
+
{"quota_set":  [
|-
+
      [
|GET || v3/{domain_id}/os-domain-usage || Returns the usage_set for the domain. Can be called by Cloud admin or an admin for the domain.
+
        {"region": "regionOne"
|}
+
                }
 +
                {"nova_quota_set": ["instances","volumes","floating_ips"]
 +
                },
 +
                {"cinder_quota_set": ["volumes","gigabytes"]
 +
                }
 +
              ]
 +
              ]
 +
  }
  
Normal Response Code: 200. Error Response Codes: Unauthorized (401), Forbidden (403)
+
GET v3/{domain-id}/os-domain-quotas
This operation does not require a request body. This operation returns a response.
+
This gives an option of getting quota for single domain only.
 +
{"quota_set":  [
 +
      [               
 +
                {"region": "regionOne"
 +
                },
 +
                {"nova_quota_set": ["instances","volumes","floating_ips"]
 +
                },
 +
                {"cinder_quota_set": ["volumes","gigabytes"]
 +
                }
 +
              ]
 +
              ]
 +
  }
  
'''Example 2. usage-set  Response: JSON'''
+
SETv3/{domain-id}/os-domain-quotas
 +
This gives an option of setting quota for single domain only.
 +
{"quota_set": [
 +
              [
 +
                {"region":"RegionOne",
 +
                },
 +
                {"nova_quota_set":
 +
                  [
 +
                  {"volumes": 20},
 +
                  {"floating_ips": 10}
 +
                  ]
 +
                }
 +
              ],
 +
              [
 +
                {"region":"RegionTwo",
 +
                },
 +
                {"nova_quota_set":
 +
                  [
 +
                  {"volumes": 40},
 +
                  {"floating_ips": 20}
 +
                  ]
 +
                }
 +
              ]
 +
              ]
 +
}
  
<pre><nowiki>
+
POST v3/{domain-id}os-domain-quotas
 +
This gives an option of updating quota for single domain only.
 +
{"quota_set": [
 +
              [
 +
                {"region":"RegionOne",
 +
                },
 +
                {"nova_quota_set":
 +
                  [
 +
                  {"volumes": 25},
 +
                  {"floating_ips":30}
 +
                  ]
 +
                }
 +
              ],
 +
              [
 +
                {"region":"RegionTwo",
 +
                },
 +
                {"nova_quota_set":
 +
                  [
 +
                  {"volumes": 50},
 +
                  {"floating_ips": 30}
 +
                  ]
 +
                }
 +
              ]
 +
              ]
 +
}
  
{'usage_set':  {'domain_id': 83201710-7d95-71d0-2b23-834f6daf59571,
+
DELETE v3/{domain-id}/os-domain-quotas
                'timestamp': 2013-01-05T10:45:00Z,
+
This gives an option of deleting quota for single domain only.
                {'nova_usage_set':
+
{"quota_set": [
                  {'volumes': 20,
+
      [               
                  'floating_ips': 90,
+
                 {"region": "regionOne"
                  'instances': 234,
+
                },
                  'injected_files': 22,
+
                 {"nova_quota_set": ["instances","volumes","floating_ips"]
                  'cores': 234}},
+
                },
                 {'cinder_usage_set':  
+
                 {"cinder_quota_set": ["volumes","gigabytes"]
                  {'volumes': 70,
+
                }
                  'gigabytes': 95000}},
+
              ]
                 {'quantum_usage_set':  
+
              ]
                  {'networks': 23,
+
  }
                  'subnets': 23,
 
        'routers': 23}},
 
                 {'swift_usage_set':  
 
                  {'containers': 11,
 
                  'objects': 76
 
    'storage_capacity': 145}}
 
  }
 
                    }
 
</nowiki></pre>
 
 
 
=== Usage Tracking and Limit Checking ===
 
Domain quotas require changes to the implementation of operations that can modify a service property that has a quota limit. The list of operations include allocate a new floating IP address, create a server, delete a network etc.
 
 
 
Each operation will require two changes. Firstl, each operation that can modify a service property has to record the change in usage table for the appropriate domain.  Second, before a service property can be increased, the current usage must be checked against the quota limit for the domain.
 
  
  

Revision as of 16:55, 7 June 2013

Introduction

In Keystone v3 (Grizzly release), the 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

  1. Per–Region domain quotas
  2. 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

The proposal is to extend Keystone and existing service quota drivers to support the domain quotas management and enforcement. The following figure depicts the high level architecture.

Our idea is to concentrate the REST APIs in the Domain Quota Proxy which will be in charge of: • Distributing domain quotas to the services • Gathering domain quotas usage from the services Quota modules need to be refactored to add a driver to enforce domain quotas. Also we should extend the services REST API to provide domain quotas usage to Domain Quota Proxy. The Domain Quota Proxy 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

GET v3/os-domain-quotas This gives an option of getting quota for all domains. Region is optional. {"quota_set": [ [ {"region": "regionOne"

               }
               {"nova_quota_set": ["instances","volumes","floating_ips"]
               },
               {"cinder_quota_set": ["volumes","gigabytes"]
               }
              ]
             ]
 }

GET v3/{domain-id}/os-domain-quotas This gives an option of getting quota for single domain only. {"quota_set": [ [

               {"region": "regionOne"
               },
               {"nova_quota_set": ["instances","volumes","floating_ips"]
               },
               {"cinder_quota_set": ["volumes","gigabytes"]
               }
              ]
             ]
 }

SETv3/{domain-id}/os-domain-quotas This gives an option of setting quota for single domain only. {"quota_set": [

              [
               {"region":"RegionOne",
               },
               {"nova_quota_set":
                 [
                  {"volumes": 20},
                  {"floating_ips": 10}
                 ]
               }
              ],
              [
               {"region":"RegionTwo",
               },
               {"nova_quota_set":
                 [
                  {"volumes": 40},
                  {"floating_ips": 20}
                 ]
               }
              ]
             ]

}

POST v3/{domain-id}os-domain-quotas This gives an option of updating quota for single domain only. {"quota_set": [

              [
               {"region":"RegionOne",
               },
               {"nova_quota_set":
                 [
                  {"volumes": 25},
                  {"floating_ips":30}
                 ]
               }
              ],
              [
               {"region":"RegionTwo",
               },
               {"nova_quota_set":
                 [
                  {"volumes": 50},
                  {"floating_ips": 30}
                 ]
               }
              ]
             ]

}

DELETE v3/{domain-id}/os-domain-quotas This gives an option of deleting quota for single domain only. {"quota_set": [ [

               {"region": "regionOne"
               },
               {"nova_quota_set": ["instances","volumes","floating_ips"]
               },
               {"cinder_quota_set": ["volumes","gigabytes"]
               }
              ]
             ]
 }


Open Stack Quota References

This is a list of URLs of work on quotas within OpenStack.

Topic URI Notes
Per-user quotas support https://blueprints.launchpad.net/nova/+spec/per-user-quotas Blocked to be re-introduced in Grizzly
Stores Quotas centrally in Keystone http://wiki.openstack.org/KeystoneStoreQuotaData
Quantum Quotas http://docs.openstack.org/api/openstack-network/2.0/content/List_Quotas.html
Swift Quotas https://blueprints.launchpad.net/swift/+spec/storage-quotas Implementation status unknown
Quota Project: An effective way to manage the usage of your Swift-based storage cloud http://www.zmanda.com/blogs/?cat=22
Update Limits and Quotas to Key On volume_type https://blueprints.launchpad.net/cinder/+spec/quotas-limits-by-voltype Not started, grizzly-3 target
Demystifying OpenStack Folsom Quotas http://ops.anthonygoddard.com/OpenStack/demystifying-openstack-folsom-quotas/ Explains Cinder/Nova quota separation
per-user quotas support https://blueprints.launchpad.net/nova/+spec/per-user-quotas Blocked by bug https://bugs.launchpad.net/nova/+bug/1034384. It will be re-introduced into Grizzly