On Tue, Jul 19, 2011 at 4:43 AM, Jeroen Vermeulen <j...@canonical.com> wrote: >> I agree that it makes it more conservative; how does that lead to more >> downtime? > > Through more downtime deployments. My understanding was that we will still > have downtime when we can't deploy a patch within the time budget.
If the patch is slower than 15 seconds, it requires sign off from me / francis. This is an escape valve for things that are too hard to make fast - but we don't expect to use it. > If that is the case, when we over-estimate the deployment time of a patch > such that the estimate is over budget but actual deployment time is under > budget, we will plan downtime that isn't actually needed. This is true; however Francis and I can dig deeper (e.g. by asking you and stub :P) about the likely prod performance of a db patch thats slow. 15 seconds is room - with cold cache - to do quite a lot; its about 2ms to bring back a row cold, and with a write-back cache we shouldn't need to block on writes, so - 2ms * 2 nodes -> about 3500 rows can be updated. -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
