Nova DB Cleanup

Registered by Joe Gordon on 2012-11-01

Catch-all for cleaning up Nova DB. Sub-topics are getting broken out into separate BPs.
* db-api-cleanup
* db-session-cleanup
* db-archiving
* db-unique-keys

This work is preparing the way for the following items:
* db-reconnect

Blueprint information

Status:
Complete
Approver:
Vish Ishaya
Priority:
Medium
Drafter:
aeva black
Direction:
Approved
Assignee:
aeva black
Definition:
Approved
Series goal:
None
Implementation:
Implemented
Milestone target:
None
Started by
Thierry Carrez on 2012-11-13
Completed by
John Garbutt on 2013-11-19

Whiteboard

johnthetubaguy: seems to be complete, or at least stuck in the past, so marking as complete.

Gerrit topic: https://review.openstack.org/#q,topic:bp/db-cleanup,n,z

Addressed by: https://review.openstack.org/14928
    remove session parameter from fixed_ip_get

Addressed by: https://review.openstack.org/14936
    improve sessions around compute_node_*

Addressed by: https://review.openstack.org/14929
    improve sessions around floating_ip_get_by_address

Addressed by: https://review.openstack.org/14966
    add doc to standardize session usage

You know, one thing that bothers me about this one is the fact that we really need to be able to do transactions outside of the dbapi. As an example, consider quota_reserve(); all that work needs to be done in a transaction, so all that code ends up being buried deep in the dbapi, whereas arguably the dbapi should be as simple as possible.
    -- Vek, 2012-11-01T21:51Z

I disagree. Besides making it harder to read / debug the code, allowing transactions outside of dbapi also encourages very long running transactions, or XA transactions across databases/projects, both of which are very bad IMO. Taking quota_reserve() as an example, the "rollback" logic that currently exists should allow for another process to clean up after a failed allocation, eg. if the process which started the reservation dies ungracefully mid-way through. (I could be mistaken, but I think quotas already does this?) Holding open a database transaction while waiting for API callbacks from, eg. quantum for floating-ip allocation, would be terrible... and is the opposite of eventual-consistency.
   -- Devananda, 2012-11-02 11:10-07:00

See wiki page http://wiki.openstack.org/ReadDeletedYesOrOnly for a list of places where we check for read_deleted being "yes" or "only". (Checking for "no" is not a problem.)

Addressed by: https://review.openstack.org/16189
    blueprint db-cleanup add index to fixed_ips(deleted, allocated) columns

Gerrit topic: https://review.openstack.org/#q,topic:tests_for_inst_extra_specs,n,z

Addressed by: https://review.openstack.org/27409
    Move db.instance_type_extra_specs_* to db.instance_type_* methods

Addressed by: https://review.openstack.org/55864
    Removed unused methods from db.api

Gerrit topic: https://review.opendev.org/#/q/topic:db-cleanup

Addressed by: https://review.opendev.org/698703
    trivial: Remove dead code

Addressed by: https://review.opendev.org/698704
    db: Drop cells v1 tables

Addressed by: https://review.opendev.org/698705
    db: Drop snapshots table

Addressed by: https://review.opendev.org/698706
    db: Drop tables that were moved to API DB

Addressed by: https://review.opendev.org/698707
    db: Remove placement tables

Addressed by: https://review.opendev.org/698880
    db: Remove unused ec2 DB APIs

Addressed by: https://review.opendev.org/698881
    db: Remove unused models

(?)

Work Items

Dependency tree

* Blueprints in grey have been implemented.

This blueprint contains Public information 
Everyone can see this information.