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.