Send database reads to a slave handle for scaling purposes

Registered by Michael H Wilson on 2013-04-20

An option for a slave handle would be beneficial for scaling. We could send all reads that aren't sensitive to replication lag to this handle and gain quite a bit of room to scale on our write masters. Besides just having the handle, we also need a nice way for devs to indicate that a query is safe to execute on a slave. We could probably indicate the "safeness" in context. In the db api we can indicate safeness using a decorator.

Blueprint information

Status:
Complete
Approver:
Russell Bryant
Priority:
High
Drafter:
Michael H Wilson
Direction:
Approved
Assignee:
Michael H Wilson
Definition:
Approved
Series goal:
Accepted for havana
Implementation:
Implemented
Milestone target:
milestone icon 2013.2
Started by
Russell Bryant on 2013-04-22
Completed by
Michael H Wilson on 2013-08-07

Related branches

Sprints

Whiteboard

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

Addressed by: https://review.openstack.org/30363
    Add lag_tolerant flag to Context class.

Addressed by: https://review.openstack.org/30370
    Add _safe_for_slave decorator to sqlalchemy db api.

I think there's enough feedback from people to safely say that the decorator + context approach isn't going to fly. As such, I'm going to move that portion of things into the implementation of "slaveifying" various code paths. Essentially, without these two things this blueprint is done.

(?)

Work Items

Work items:
Slave handle into oslo-incubator and synced to nova: DONE

Dependency tree

* Blueprints in grey have been implemented.

This blueprint contains Public information 
Everyone can see this information.