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 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-set  swift.total=1073741824 keystone quota-get  swift.total keystone quota-delete  swift.total

2. An administrator wants to manipulate the Nova quotas for multiple resources like ram and instances for a tenant in Nova and the get or delete all Swift quotas. The administrator accesses the quota information via some Admin only subcommands in the keystone client.

keystone quota-set  swift.total=1073741824 nova.cores=100 nova.instances=20 keystone quota-get  swift keystone quota-delete  swift

Design
The command line interface for this feature would be

usage: keystone quota-set  [ ...]

Set quota(s) for a specific tenant

Positional arguments:  Tenant ID to create the quota(s) for 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 multiple quotas (e.g. nova.ram nova.cores).

usage: keystone quota-get  [ ...]

Get quota(s) for a specific tenant

Optional arguments: The quota to get for single or multiple resources. For a single resource the format is a dot notation (e.g. swift.total). For all resources for an OpenStack component use the name prefix (e.g. nova). To get all resources exclude this argument.

Positional arguments:  Tenant ID to get the quota for

usage: keystone quota-delete  [ ...]

Delete quota(s) for a specific tenant

Optional arguments: 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 all resources for an OpenStack component use the name prefix (e.g. nova). To delete all resources exclude this argument.

Positional arguments:  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) For the keystone CLI I'm proposing using JSON for batch create, update, and delete of quotas. I don't believe this is done anywhere else in OpenStack. Good idea? Bad idea?
 * 2) No one was particularly for or against this on the ML. I've decided against this for the initial implementation.
 * 3) Do we have just one DELETE with details of what to delete in the body of the request?
 * 4) Note htat HTTP 1.1 allows the DELETE method to have a request body.
 * 5) No comments on this on the ML. I will just go with one delete.
 * 6) Which Implementation option to use?
 * 7) No comments on this on the ML. I will try option 1 to see how it works in practice but will switch to option 2 if necessary.
 * 8) 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?
 * 9) No comments on this on the ML. I will just go with a service specific to quotas.