launchpad-dev team mailing list archive

[Robert Collins <robertc@xxxxxxxxxxxxxxxxx>]

As prep for https://dev.launchpad.net/LEP/FastDowntime the db schema
change process[1] has been updated. The new process is effective
*now*. Once the deployment side is tested, sorted, worked out with
losas etc, then we will start working through any backlogged patches.

If we are not ready to do fastdowntime by early August, we'll probably
do another 90m downtime and roll all the incremental patches into
that.

I appreciate that between now and the deployment side of this going
live we're going to be doing a little more work around each schema
patch with no immediate payoff - but it means we'll be able to go
straight into the fastdowntime process once its ready.

This is a fairly small change but a huge evolution in the way we
approach DB changes: I expect some friction and learning for us all.
Lets help each other across this learning curve... Stuart and I in
particular will be delighted to help solve the problem of making a
given schema change fast.

tl;dr:
 * The most recent 90 minute downtime was the last ever.
 * all db changes land on db-devel.
 * no db change can be commingled with python [lib/*] changes - land
them separately.
 * All db changes must be <15 seconds on staging/qastaging - cold.

[1] https://dev.launchpad.net/PolicyAndProcess/DatabaseSchemaChangesProcess

-Rob