Merge lp:~al-maisan/launchpad/delays-by-jobs-ahead-504086 into lp:launchpad/db-devel
| Status: | Merged |
|---|---|
| Approved by: | Gavin Panella on 2010-01-28 |
| Approved revision: | not available |
| Merged at revision: | not available |
| Proposed branch: | lp:~al-maisan/launchpad/delays-by-jobs-ahead-504086 |
| Merge into: | lp:launchpad/db-devel |
| Diff against target: |
765 lines (+405/-118) 7 files modified
lib/lp/buildmaster/interfaces/buildfarmjob.py (+0/-49) lib/lp/buildmaster/model/buildfarmjob.py (+3/-2) lib/lp/soyuz/model/buildpackagejob.py (+1/-33) lib/lp/soyuz/model/buildqueue.py (+169/-2) lib/lp/soyuz/tests/test_buildpackagejob.py (+0/-7) lib/lp/soyuz/tests/test_buildqueue.py (+216/-16) lib/lp/testing/factory.py (+16/-9) |
| To merge this branch: | bzr merge lp:~al-maisan/launchpad/delays-by-jobs-ahead-504086 |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Gavin Panella (community) | 2010-01-27 | Approve on 2010-01-28 | |
|
Review via email:
|
|||
| Muharem Hrnjadovic (al-maisan) wrote : | # |
| Muharem Hrnjadovic (al-maisan) wrote : | # |
Muharem Hrnjadovic wrote:
> Muharem Hrnjadovic has proposed merging lp:~al-maisan/launchpad/delays-by-jobs-ahead-504086 into lp:launchpad.
>
> Requested reviews:
> Canonical Launchpad Engineering (launchpad)
> Related bugs:
> #504086 Job dispatch time estimation: what are the delays caused by the jobs ahead?
> https:/
>
>
> Hello there!
>
> This is the second last branch required to provide a generalized build farm
> job dispatch time estimation (irrespective of job type).
>
> Given a build farm job of interest (JOI) for which the user would like to
> receive a dispatch time estimation we need to calculate the dispatch delay
> caused by other jobs that
>
> - are ahead of JOI in the queue and
> - compete with it for builder resources
>
> Some of the ideas implemented by the algorithm in this branch are:
>
> - a processor-
> virtualization setting.
> - the delays caused by the jobs ahead of the JOI need to be weighted (based
> on the size of the pool of builders that can run these jobs).
> - In addition to the estimated delay value _estimateJobDelay() returns the
> platform of the head job (the first of the competing jobs to be dispatched
> to a builder).
> The head job platform will be fed to _estimateTimeTo
> to estimate how long it takes until the head job gets dispatched to a
> builder.
> - Total delay = "delay caused by jobs ahead" + "time to next builder"
>
> Tests to run:
>
> bin/test -vv -t test_buildqueue
>
> I had various pre-implementation talks with Julian and Michael N.
>
> No (relevant) "make lint" errors or warnings.
>
>
>
> -------
>
> This body part will be downloaded on demand.
Hello Gavin,
just letting you know that I have addressed some of your preliminary
review comments (http://
The SQL query is now more precise and only yields the jobs that are
queued ahead of the job of interest (JOI) making both the 'break'
statement and the 'ORDER BY' clause superfluous.
Please see the attached incremental diff for details.
Best regards
--
Muharem Hrnjadovic <email address hidden>
Public key id : B2BBFCFC
Key fingerprint : A5A3 CC67 2B87 D641 103F 5602 219F 6B60 B2BB FCFC
| Muharem Hrnjadovic (al-maisan) wrote : | # |
Hello Gavin,
your review comments got me thinking :) and I realized that the main
function in the branch (_estimateJobDe
using SQL aggregate functions as opposed to iterating in the python domain.
Also, _estimateJobDelay() now just calculates delays and is not
concerned with the head job platform any more which makes the code quite
a bit clearer.
Anyway, the resulting incremental diff (see attachment) since the review
began is 509 lines long.
Maybe, it's best to resubmit a merge proposal for the enhanced branch
and start the review from scratch?
Please let me know what you think.
Muharem Hrnjadovic wrote:
> Muharem Hrnjadovic has proposed merging lp:~al-maisan/launchpad/delays-by-jobs-ahead-504086 into lp:launchpad.
>
> Requested reviews:
> Canonical Launchpad Engineering (launchpad)
> Related bugs:
> #504086 Job dispatch time estimation: what are the delays caused by the jobs ahead?
> https:/
>
>
> Hello there!
>
> This is the second last branch required to provide a generalized build farm
> job dispatch time estimation (irrespective of job type).
>
> Given a build farm job of interest (JOI) for which the user would like to
> receive a dispatch time estimation we need to calculate the dispatch delay
> caused by other jobs that
>
> - are ahead of JOI in the queue and
> - compete with it for builder resources
>
> Some of the ideas implemented by the algorithm in this branch are:
>
> - a processor-
> virtualization setting.
> - the delays caused by the jobs ahead of the JOI need to be weighted (based
> on the size of the pool of builders that can run these jobs).
> - In addition to the estimated delay value _estimateJobDelay() returns the
> platform of the head job (the first of the competing jobs to be dispatched
> to a builder).
> The head job platform will be fed to _estimateTimeTo
> to estimate how long it takes until the head job gets dispatched to a
> builder.
> - Total delay = "delay caused by jobs ahead" + "time to next builder"
>
> Tests to run:
>
> bin/test -vv -t test_buildqueue
>
> I had various pre-implementation talks with Julian and Michael N.
>
> No (relevant) "make lint" errors or warnings.
>
>
>
> -------
>
> This body part will be downloaded on demand.
Best regards
--
Muharem Hrnjadovic <email address hidden>
Public key id : B2BBFCFC
Key fingerprint : A5A3 CC67 2B87 D641 103F 5602 219F 6B60 B2BB FCFC
| Gavin Panella (allenap) wrote : | # |
Hi Muharem, I'll review the incremental diff. Before moving on, I'll finish off reviewing the original diff quickly so that I'm familiar with where it's coming from.
| Gavin Panella (allenap) wrote : | # |
This is a review of your branch at about revision 8647. I haven't added much since last night's preview review :) I'll look at the incremental diff now.
> === modified file 'lib/lp/
> --- lib/lp/
> +++ lib/lp/
> @@ -10,7 +10,6 @@
> __all__ = [
> 'IBuildFarmJob',
> 'IBuildFarmCand
> - 'IBuildFarmJobD
> 'ISpecificBuild
> 'BuildFarmJobType',
> ]
> @@ -108,54 +107,6 @@
> """
>
>
> -class IBuildFarmJobDi
> - """Operations needed for job dipatch time estimation."""
> -
> - def composePendingJ
> - """String SELECT query yielding pending jobs with given minimum score.
> -
> - This will be used for the purpose of job dispatch time estimation
> - for a build job of interest (JOI).
> - In order to estimate the dispatch time for the JOI we need to
> - calculate the sum of the estimated durations of the *pending* jobs
> - ahead of JOI.
> -
> - Depending on the build farm job type the JOI may or may not be tied
> - to a particular processor type.
> - Binary builds for example are always built for a specific processor
> - whereas "create a source package from recipe" type jobs do not care
> - about processor types or virtualization.
> -
> - When implementing this method for processor independent build farm job
> - types (e.g. recipe build) you may safely ignore the `processor` and
> - `virtualized` parameters.
> -
> - The SELECT query to be returned needs to select the following data
> -
> - 1 - BuildQueue.job
> - 2 - BuildQueue.
> - 3 - BuildQueue.
> - 4 - Processor.id [optional]
> - 5 - virtualized [optional]
> -
> - Please do *not* order the result set since it will be UNIONed and
> - ordered only then.
> -
> - Job types that are processor independent or do not care about
> - virtualization should return NULL for the optional data in the result
> - set.
> -
> - :param min_score: the pending jobs selected by the returned
> - query should have score >= min_score.
> - :param processor: the type of processor that the jobs are expected
> - to run on.
> - :param virtualized: whether the jobs are expected to run on the
> - `processor` natively or inside a virtual machine.
> - :return: a string SELECT clause that can be used to find
> - the pending jobs of the appropriate type.
> - """
> -
> -
> class IBuildFarmCandi
> """Operations for refining candidate job selection (optional).
>
>
> === modified file 'lib/lp/
> --- lib/lp/
> +++ lib/lp/
> @@ -1...
| Gavin Panella (allenap) wrote : | # |
This is a review of the incremental changes. Although I've suggested a lot of changes here and in the previous review, they're all minor tweaks; the branch is good already, so r=me :)
> === modified file 'lib/lp/
> --- lib/lp/
> +++ lib/lp/
> @@ -109,7 +109,7 @@
>
> class IBuildFarmCandi
> """Operations for refining candidate job selection (optional).
> -
> +
> Job type classes that do *not* need to refine candidate job selection may
> be derived from `BuildFarmJob` which provides a base implementation of
> this interface.
> @@ -129,7 +129,7 @@
> SELECT TRUE
> FROM Archive, Build, BuildPackageJob, DistroArchSeries
> WHERE
> - BuildPackageJob.job = Job.id AND
> + BuildPackageJob.job = Job.id AND
> ..
>
> :param processor: the type of processor that the candidate jobs are
> @@ -143,7 +143,7 @@
> def postprocessCand
> """True if the candidate job is fine and should be dispatched
> to a builder, False otherwise.
> -
> +
> :param job: The `BuildQueue` instance to be scrutinized.
> :param logger: The logger to use.
>
>
> === modified file 'lib/lp/
> --- lib/lp/
> +++ lib/lp/
> @@ -181,8 +181,8 @@
> sub_query = """
> SELECT TRUE FROM Archive, Build, BuildPackageJob, DistroArchSeries
> WHERE
> - BuildPackageJob.job = Job.id AND
> - BuildPackageJob
> + BuildPackageJob.job = Job.id AND
> + BuildPackageJob
> Build.distroarc
> Build.archive = Archive.id AND
> ((Archive.private IS TRUE AND
>
> === modified file 'lib/lp/
> --- lib/lp/
> +++ lib/lp/
> @@ -211,7 +211,7 @@
> def _estimateTimeTo
> self, head_job_processor, head_job_
> """Estimate time until next builder becomes available.
> -
> +
> For the purpose of estimating the dispatch time of the job of interest
> (JOI) we need to know how long it will take until the job at the head
> of JOI's queue is dispatched.
> @@ -253,7 +253,7 @@
>
> delay_query = """
> SELECT MIN(
> - CASE WHEN
> + CASE WHEN
> EXTRACT(EPOCH FROM
> (BuildQueue.
> (((now() AT TIME ZONE 'UTC') - Job.date_
> @@ -291,7 +291,7 @@
>
> def _estimateJobDel
> """Sum of estimated durations for *pending* jobs ahead in queue.
> -
> +
> For the purpose of estimating the dispatch...
| Muharem Hrnjadovic (al-maisan) wrote : | # |
Gavin Panella wrote:
> Review: Approve
> This is a review of the incremental changes. Although I've suggested a
> lot of changes here and in the previous review, they're all minor
> tweaks; the branch is good already, so r=me :)
Hello Gavin,
thank you for putting up with a branch that was changing while you were
reviewing it.
I have accommodated all your suggestions. Please see the enclosed diff
as well as the replies below.
>> === modified file 'lib/lp/
>> --- lib/lp/
>> +++ lib/lp/
>> @@ -109,7 +109,7 @@
>>
>> class IBuildFarmCandi
>> """Operations for refining candidate job selection (optional).
>> -
>> +
>> Job type classes that do *not* need to refine candidate job selection may
>> be derived from `BuildFarmJob` which provides a base implementation of
>> this interface.
>> @@ -129,7 +129,7 @@
>> SELECT TRUE
>> FROM Archive, Build, BuildPackageJob, DistroArchSeries
>> WHERE
>> - BuildPackageJob.job = Job.id AND
>> + BuildPackageJob.job = Job.id AND
>> ..
>>
>> :param processor: the type of processor that the candidate jobs are
>> @@ -143,7 +143,7 @@
>> def postprocessCand
>> """True if the candidate job is fine and should be dispatched
>> to a builder, False otherwise.
>> -
>> +
>> :param job: The `BuildQueue` instance to be scrutinized.
>> :param logger: The logger to use.
>>
>>
>> === modified file 'lib/lp/
>> --- lib/lp/
>> +++ lib/lp/
>> @@ -181,8 +181,8 @@
>> sub_query = """
>> SELECT TRUE FROM Archive, Build, BuildPackageJob, DistroArchSeries
>> WHERE
>> - BuildPackageJob.job = Job.id AND
>> - BuildPackageJob
>> + BuildPackageJob.job = Job.id AND
>> + BuildPackageJob
>> Build.distroarc
>> Build.archive = Archive.id AND
>> ((Archive.private IS TRUE AND
>>
>> === modified file 'lib/lp/
>> --- lib/lp/
>> +++ lib/lp/
>> @@ -211,7 +211,7 @@
>> def _estimateTimeTo
>> self, head_job_processor, head_job_
>> """Estimate time until next builder becomes available.
>> -
>> +
>> For the purpose of estimating the dispatch time of the job of interest
>> (JOI) we need to know how long it will take until the job at the head
>> of JOI's queue is dispatched.
>> @@ -253,7 +253,7 @@
>>
>> delay_query = """
>> SELECT MIN(
>> - CASE WHEN
>> + CASE WHEN
>> EXTRACT(EPOCH FROM
>> (BuildQueue...

Hello there!
This is the second last branch required to provide a generalized build farm
job dispatch time estimation (irrespective of job type).
Given a build farm job of interest (JOI) for which the user would like to
receive a dispatch time estimation we need to calculate the dispatch delay
caused by other jobs that
- are ahead of JOI in the queue and
- compete with it for builder resources
Some of the ideas implemented by the algorithm in this branch are:
- a processor- independent job competes with all other jobs with the same NextBuilder( ) in order
virtualization setting.
- the delays caused by the jobs ahead of the JOI need to be weighted (based
on the size of the pool of builders that can run these jobs).
- In addition to the estimated delay value _estimateJobDelay() returns the
platform of the head job (the first of the competing jobs to be dispatched
to a builder).
The head job platform will be fed to _estimateTimeTo
to estimate how long it takes until the head job gets dispatched to a
builder.
- Total delay = "delay caused by jobs ahead" + "time to next builder"
Tests to run:
bin/test -vv -t test_buildqueue
I had various pre-implementation talks with Julian and Michael N.
No (relevant) "make lint" errors or warnings.