KeystoneStoreQuotaData
- Launchpad Entry: KeystoneSpec:store-quota-data
- Created: 9 May 2012
- Contributors: Everett Toews
Summary
In order to enable the use of quotas across different OpenStack components we need to store them centrally. Keystone can be used as that central datastore.
Release Note
Quota information for a tenant can be stored and accessed in Keystone.
Rationale
Quotas are necessary to prevent overconsumption of resources.
User stories
1. An administrator wants to manipulate the Swift quotas for a single resource, the total storage (in bytes since that's the level of granularity in Swift) allowed, for a tenant/account in Swift. The administrator accesses the quota information via some Admin only subcommands in the keystone client.
See Design for the subcommand details.
keystone quota-create --quota swift.total=1073741824 <tenant-id> keystone quota-get --quota swift.total <tenant-id> keystone quota-list <tenant-id> keystone quota-update --quota swift.total=2147483648 <tenant-id> keystone quota-delete --quota swift.total <tenant-id>
2. An administrator wants to manipulate the Nova quotas for multiple resources like ram and instances for a tenant in Nova and the Swift quotas for the total storage. The administrator accesses the quota information via some Admin only subcommands in the keystone client.
keystone quota-create --quota {"swift":{"total":1073741824},"nova":{"ram":102400,"instances":20}} <tenant-id> keystone quota-update --quota {"swift":{"total":2147483648},"nova":{"ram":102400,"instances":20}} <tenant-id> keystone quota-delete --quota {"swift":["total"],"nova":["ram","instances"]} <tenant-id>
Design
The command line interface for this feature would be
usage: keystone quota-create --quota <quota> <tenant-id> Create quota(s) for a specific tenant Required arguments: --quota <quota> The quota to create for single or multiple resources. For a single resource the format is a dot notation (e.g. swift.total=1000). For multiple resources use JSON (e.g. {"nova":{"ram":102400,"instances":20}}). Positional arguments: <tenant-id> Tenant ID to create the quota(s) for
usage: keystone quota-get --quota <quota> <tenant-id> Get quota for a specific tenant Required arguments: --quota <quota> The quota to get for a single resources. For a single resource the format is a dot notation (e.g. swift.total=1000). Positional arguments: <tenant-id> Tenant ID to get the quota for
usage: keystone quota-list <tenant-id> List quotas for a specific tenant Positional arguments: <tenant-id> Tenant ID to list the quotas for
usage: keystone quota-update --quota <quota> <tenant-id> Update quota(s) for a specific tenant Required arguments: --quota <quota> The quota to update for single or multiple resources. For a single resource the format is a dot notation (e.g. swift.total=1000). For multiple resources use JSON (e.g. {"nova":{"ram":102400,"instances":20}}). Positional arguments: <tenant-id> Tenant ID to update the quota(s) for
usage: keystone quota-delete [--quota <quota>] <tenant-id> Delete quota(s) for a specific tenant Optional arguments: --quota <quota> The quota to delete for single or multiple resources. For a single resource the format is a dot notation (e.g. swift.total=1000). For multiple resources use JSON (e.g. {"nova":{"ram":102400,"instances":20}}). For all resources exclude this argument. Positional arguments: <tenant-id> Tenant ID to delete the quota(s) for
The RESTful API for this feature would be
Verb | URI |
GET | /tenants/{tenant_id}/quotas |
GET | /tenants/{tenant_id}/quotas/{quota} |
POST | /tenants/{tenant_id}/quotas |
PUT | /tenants/{tenant_id}/quotas |
DELETE | /tenants/{tenant_id}/quotas |
Implementation
UI Changes
The Swift CLI will need to be able to CRUD quotas for accounts. You should be able to view quota usage in Horizon.
Code Changes
Code changes should include an overview of what needs to change, and in some cases even the specific details.
Migration
Include:
- data migration, if any
- redirects from old URLs to new ones, if any
- how users will be pointed to the new way of doing things, if necessary.
Test/Demo Plan
This need not be added or completed until the specification is nearing beta.
Unresolved issues
This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.
BoF agenda and discussion
Questions:
1 Should I be using JSON for batch create, update, and delete? 1 Do we have just one DELETE with details of what to delete in the body of the request?
Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.