Nova/QuotaKeyValueSpec

Launchpad Entry: NovaSpec:QuotaKeyValue
Created: May 8 2011
Contributors: Mark Washenberger

Summary

Currently the quota table in the nova db has a column for every type of quota we manage. Each time we add a new type of quota to the system, we have to make a schema change. A key-value approach to the schema for quotas would allow new types of quotas to be added without requiring subsequent schema changes.

Release Note

Adds the concept of unlimited quotas.

Assumptions

It is acceptable to drop history in the quota table on a downgrade of this schema change. See migration notes below for more details.
In the design prior to this change, it is invalid to have multiple non-deleted quota rows for a single project id, despite the fact that the schema supports multiple such rows. Again, see migration details below.

Design

The current table schema for quotas looks like:

Unique Int id
Datetime created_at
Datetime updated_at
Datetime deleted_at
Boolean deleted
String project_id
Int instances
Int cores
Int gigabytes
Int floating_ips
Int metadata_items

A given project has only one quota row. The entries in the row are only overrides--if an entry is NULL that means to use the default as specified in a flag.

There are a few proposals to add more items to the schema, in particular RAM limits. (Link?) Changes such as this would not require database migrations if we switched to a schema like

Unique Int id
Datetime created_at
Datetime updated_at
Datetime deleted_at
Boolean deleted
String project_id
String resource
Int limit

In this design, a given project would have a multiple rows--one for each non-default quota setting it has. If a project has the default limit for a given resource, it would not have a row for that resource. Furthermore, the design introduces the concept of unlimited quotas. When the limit associated with a given resource is NULL, then that resource is unlimited.

Implementation

Code Changes

Schema change in nova/db/sqlalchemy/
Database interface change in nova/db/api.py
Slight changes to bin/nova-manage
Make nova/quota.py work with the new database interface
Slight changes to tests
Database migration code, see below

Database Migration

Upgrade preconditions Upgrade actions Downgrade preconditions Downgrade actions and consequences

Test/Demo Plan

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

Unresolved issues

Deleted column::

The boolean deleted column on each row in the database allows deployers to track change history. However, it also prevents enforcing uniqueness on other columns. Perhaps it would be better to move history tracking to another project or at least another table in the same database.

BoF agenda and discussion

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.