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 <tenant-id> swift.total=1073741824 
keystone quota-get <tenant-id> swift.total 
keystone quota-delete <tenant-id> 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 <tenant-id> swift.total=1073741824 nova.cores=100 nova.instances=20
keystone quota-get <tenant-id> swift
keystone quota-delete <tenant-id> swift

Design

The command line interface for this feature would be

usage: keystone quota-set <tenant-id> <quota> [<quota> ...]

Set quota(s) for a specific tenant

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

usage: keystone quota-get <tenant-id> [<quota> ...]

Get quota(s) for a specific tenant

Optional arguments:
  <quota>  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> Tenant ID to get the quota for

usage: keystone quota-delete <tenant-id> [<quota> ...]

Delete quota(s) for a specific tenant

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

Verb	URI
GET	/tenants/{tenant_id}/quotas
GET	/tenants/{tenant_id}/quotas/{quota}
PUT	/tenants/{tenant_id}/quotas
DELETE	/tenants/{tenant_id}/quotas
DELETE	/tenants/{tenant_id}/quotas/{quota}

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:

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?
1. No one was particularly for or against this on the ML. I've decided against this for the initial implementation.
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.
2. No comments on this on the ML. I will just go with one delete.
Which Implementation option to use?
1. 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.
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?
1. No comments on this on the ML. I will just go with a service specific to quotas.