Difference between revisions of "KeystoneStoreQuotaData"
m (Text replace - "__NOTOC__" to "") |
|||
(7 intermediate revisions by one other user not shown) | |||
Line 1: | Line 1: | ||
− | + | ||
* '''Launchpad Entry''': [[KeystoneSpec]]:store-quota-data | * '''Launchpad Entry''': [[KeystoneSpec]]:store-quota-data | ||
* '''Created''': 9 May 2012 | * '''Created''': 9 May 2012 | ||
Line 6: | Line 6: | ||
== Summary == | == 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. | + | 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 == | == Release Note == | ||
Line 24: | Line 24: | ||
<pre><nowiki> | <pre><nowiki> | ||
− | keystone quota- | + | keystone quota-set <tenant-id> swift.total=1073741824 |
− | + | keystone quota-get <tenant-id> swift.total | |
− | keystone quota- | + | keystone quota-delete <tenant-id> swift.total |
− | |||
− | keystone quota-delete | ||
</nowiki></pre> | </nowiki></pre> | ||
− | 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 | + | 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. |
<pre><nowiki> | <pre><nowiki> | ||
− | keystone quota- | + | keystone quota-set <tenant-id> swift.total=1073741824 nova.cores=100 nova.instances=20 |
− | keystone quota- | + | keystone quota-get <tenant-id> swift |
− | keystone quota-delete | + | keystone quota-delete <tenant-id> swift |
</nowiki></pre> | </nowiki></pre> | ||
Line 48: | Line 46: | ||
<pre><nowiki> | <pre><nowiki> | ||
− | usage: keystone quota- | + | usage: keystone quota-set <tenant-id> <quota> [<quota> ...] |
− | |||
− | |||
− | + | Set quota(s) for a specific tenant | |
− | |||
Positional arguments: | Positional arguments: | ||
<tenant-id> Tenant ID to create the quota(s) for | <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). | ||
</nowiki></pre> | </nowiki></pre> | ||
Line 62: | Line 58: | ||
<pre><nowiki> | <pre><nowiki> | ||
− | usage: keystone quota-get | + | usage: keystone quota-get <tenant-id> [<quota> ...] |
− | Get quota for a specific tenant | + | 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: | Positional arguments: | ||
Line 76: | Line 72: | ||
<pre><nowiki> | <pre><nowiki> | ||
− | usage: keystone quota- | + | usage: keystone quota-delete <tenant-id> [<quota> ...] |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
Delete quota(s) for a specific tenant | Delete quota(s) for a specific tenant | ||
Optional arguments: | 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: | Positional arguments: | ||
Line 125: | Line 96: | ||
| /tenants/{tenant_id}/quotas/{quota} | | /tenants/{tenant_id}/quotas/{quota} | ||
|- | |- | ||
− | | | + | | PUT |
| /tenants/{tenant_id}/quotas | | /tenants/{tenant_id}/quotas | ||
|- | |- | ||
− | | | + | | DELETE |
| /tenants/{tenant_id}/quotas | | /tenants/{tenant_id}/quotas | ||
|- | |- | ||
| DELETE | | DELETE | ||
− | | /tenants/{tenant_id}/quotas | + | | /tenants/{tenant_id}/quotas/{quota} |
|} | |} | ||
Line 192: | Line 163: | ||
Questions: | 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? |
+ | ## 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? | # Do we have just one DELETE with details of what to delete in the body of the request? | ||
## Note htat [http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-19#page-23 HTTP 1.1] allows the DELETE method to have a request body. | ## Note htat [http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-19#page-23 HTTP 1.1] allows the DELETE method to have a request body. | ||
+ | ## No comments on this on the ML. I will just go with one delete. | ||
# Which Implementation option to use? | # Which Implementation option to use? | ||
+ | ## 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? | # 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? | ||
+ | ## No comments on this on the ML. I will just go with a service specific to quotas. | ||
---- | ---- | ||
[[Category:Spec]] | [[Category:Spec]] |
Latest revision as of 23:30, 17 February 2013
- Launchpad Entry: KeystoneSpec:store-quota-data
- Created: 9 May 2012
- Contributors: Everett Toews
Contents
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?
- 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?
- Note htat HTTP 1.1 allows the DELETE method to have a request body.
- No comments on this on the ML. I will just go with one delete.
- Which Implementation option to use?
- 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?
- No comments on this on the ML. I will just go with a service specific to quotas.