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 _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
