Difference between revisions of "KeystoneStoreQuotaData"

Revision as of 16:30, 10 May 2012

• 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 and access 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}}). To delete 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

Implementation

For storing the data in the SQL backend, I propose two options.

1. Store the data in the current metadata table.

I would use a static user_id (say 'metadata_per_tenant') for rows where you want to store metadata per tenant. e.g. user_id='metadata_per_tenant', tenant_id='55b6d515e00e48c38e2c92d27dc5c03e', data='{"quota": ...}'

If you retrieved the quotas via SQL it would look something like,

select data 
from metadata 
where user_id='metadata_per_tenant' and tenant_id='55b6d515e00e48c38e2c92d27dc5c03e';

2. Store the data in a new metadata_per_tenant table.

I would create a new metadata_per_tenant table.

CREATE TABLE `metadata_per_tenant` (
  `tenant_id` varchar(64) NOT NULL,
  `key` varchar(255) DEFAULT NULL,
  `value` text,
  PRIMARY KEY (`tenant_id`),
  CONSTRAINT `metadata_per_tenant_ibfk_1` FOREIGN KEY (`tenant_id`) REFERENCES `tenant` (`id`)
);

The implementation of the SQL backend will drive the implementations of the other backends.

The implementation of the RESTful API and the command line interface would follow the established patterns.

UI Changes

The Design section pretty much covers it.

Migration

May require a database migration, if option 2 from the Implementation is used.

Test/Demo Plan

This need not be added or completed until the specification is nearing beta.

Unresolved issues

We'll eventually need a blueprint/spec for accessing quotas via Horizon.

BoF agenda and discussion

Questions:

1. Should I be using JSON for batch create, update, and delete?
2. Do we have just one DELETE with details of what to delete in the body of the request?
   1. Note htat HTTP 1.1 allows the DELETE method to have a request body.
3. Which Implementation option to use?
4. If you change the word quota to the word metadata in the User Stories and the Design sections, this becomes a generic mechanism for accessing metadata per tenant. Do we want a generic metadata service for keystone or stick with a service specific to quotas, while keeping the underlying implementation generic?