Difference between revisions of "DomainQuotaManagementAndEnforcement"
Yehia-beyh (talk | contribs) (Created page with "== Introduction == In Keystone v3 (Grizzly release), the Domains feature encapsulates users and projects into logical entities that can represent accounts, organizations, etc....") |
Yehia-beyh (talk | contribs) (→Introduction) |
||
| Line 3: | Line 3: | ||
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. | 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 == | ||
| + | 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. | ||
| + | |||
| + | === 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 | ||
| + | |||
| + | === Heading text === | ||
| + | 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 | ||
Revision as of 16:10, 6 March 2013
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.
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
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.
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
Heading text
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
