launchpad-dev team mailing list archive

[Robert Collins <robertc@xxxxxxxxxxxxxxxxx>]

On Thu, Jul 14, 2011 at 4:45 AM, Francis J. Lacoste
<francis.lacoste@xxxxxxxxxxxxx> wrote:
> Hi Robert,
>
> First of all, let me emphasis that I'm thrilled to see this project
> moving forward. Like I explained in my Dublin presentation, I really
> hope this will bring the long-tail of our cycle distribution toward the
> left.

Me too :) We need socialist distributions!

> Now, some things I'd like to get clarifications on...
>
> On 11-07-12 08:39 PM, Robert Collins wrote:
>> This mail is a little long, and there is a very important question in
>> it, so the tl;dr version first:
>>
>>  - if you know of a script we have, which if its database connection
>> is interrupted requires manual fixup afterwards, please let stuart or
>> I know.
>>
>>  - For *all* new DB patches please aim for 10-15 second *total*
>> application time on staging/qastaging. For assistance achieving that
>> you're welcome to tap stuart or I. As of this week slow patches (> 15
>> seconds) will require signoff by me or Francis, as they will cause
>> custom excessive downtime.
>
> Is this the total aggregated time of the pending patches? Or a maximum
> of 10-15 second for one patch?

For a single patch; and we're only going to ever apply a single patch at a time.

> I also guess that this only applies to "apply-cold" patches? Since for
> apply-live it either doesn't matter or disqualify them outright as
> apply-live.

Right.

>>
>>  - *no* more changes to both DB code and Python code at the same time:
>> This applies to both devel and db-devel.
>
> From the detailed portion of your email, I get that from now on,
> "apply-cold" patches should still go onto db-devel.
>
> Does this mean that we are introducing a two-weeks delay for any feature
> that requires an apply-code patch until we can do fastdowntime reliably?
> In other word, if I would be working on a change that requires a DB
> patch, does it mean that:
> - i write the patch
> - land it on db-devel
> - wait for it to be deploy (next full downtime or maybe fastdowntime)?
> - write the python code that depends on the patch.
>
> Or does it simply means that I have to use two landings?
>
> - Write the DB patch
> - Land it on db-devel
> - QA the db patch on staging
> - Write the python code
> - Land it on db-devel
> - QA the code on staging
>
> That would means that to do fast downtime we would merge db-stable onto
> devel up to the revision containing the DB changes, do the downtime and
> deploy the patch. Then merge all revisons from db-stable afterwards that
> don't introduce a patch, and do a nodowntime with them.

The latter for now; 2 landings. As we get more sophisticated I hope we
can delete db-devel entirely.

> We should also stress out that this means that existing python code must
> work with and without new DB patches?

Absolutely.

-Rob