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.