2010-11-04 22:27:09 |
LaMont Jones |
bug |
|
|
added bug |
2010-11-04 22:27:27 |
LaMont Jones |
tags |
|
canonical-losa-lp |
|
2010-11-05 11:02:33 |
Tom Haddon |
bug |
|
|
added subscriber Canonical LOSAs |
2010-11-05 13:44:16 |
Jelmer Vernooij |
soyuz: status |
New |
Confirmed |
|
2010-11-08 12:17:40 |
Julian Edwards |
soyuz: status |
Confirmed |
Incomplete |
|
2011-01-06 21:25:52 |
Francis J. Lacoste |
launchpad: importance |
Undecided |
High |
|
2011-01-07 12:30:19 |
Julian Edwards |
launchpad: status |
Incomplete |
Triaged |
|
2011-01-07 12:30:33 |
Julian Edwards |
tags |
canonical-losa-lp lp-soyuz |
buildfarm canonical-losa-lp lp-soyuz soyuz-build |
|
2011-04-27 19:27:10 |
Robert Collins |
summary |
Need a better single-threading control options for buildds |
cannot prevent all builds on a given arch (e.g. while bootstrapping a circular dependency) |
|
2012-01-05 18:33:57 |
Robert Collins |
summary |
cannot prevent all builds on a given arch (e.g. while bootstrapping a circular dependency) |
cannot specify specific chroot for a build |
|
2012-01-05 18:35:13 |
Robert Collins |
description |
When we bootstrap a package (due to circular dependencies), we eventually wind up putting all of the affected architecture's buildds on manual while we upload a polluted chroot with the build-deps preinstalled and launch the build of the package we're bootstrapping, then restoring the pristine chroot. This leaves us with an exposure to other buildd admins "helping" by putting buildds back on manual, or PPA builders showing up (coming back from their other uses) and being on auto.
The switching of many builders to manual and back is currently done using SQL directly, which is a badness. The exposure to buildds magically arriving on auto is treated as ignorable, since we have no current solution to the issue.
There should be a button (or api entry point) that allows me to put all buildds of an architecture on manual. And having done so, there should be a way for a launchpad-buildd-admin to tell the system "yes, I know the builders are all on manual. Start $THIS build on $THAT builder as though it were on auto and next in the queue". |
When we bootstrap a package (due to circular dependencies), we eventually wind up putting all of the affected architecture's buildds on manual while we upload a polluted chroot with the build-deps preinstalled and launch the build of the package we're bootstrapping, then restoring the pristine chroot. This leaves us with an exposure to other buildd admins "helping" by putting buildds back on manual, or PPA builders showing up (coming back from their other uses) and being on auto.
The switching of many builders to manual and back is currently done using SQL directly, which is a badness. The exposure to buildds magically arriving on auto is treated as ignorable, since we have no current solution to the issue.
There should be a button (or api entry point) that allows me to put all buildds of an architecture on manual. And having done so, there should be a way for a launchpad-buildd-admin to tell the system "yes, I know the builders are all on manual. Start $THIS build on $THAT builder as though it were on auto and next in the queue".
Diagnosis
=========
* Allowing a specific chroot to be used for a build would short-circuit all the shenanigans and allow any builder to be used. OTOH it would also allow weaker auditability so probably needs to be a admin (that is ducky) function. |
|
2015-12-15 14:31:16 |
Launchpad Janitor |
branch linked |
|
lp:~cjwatson/launchpad/db-bpb-external-dependencies |
|
2016-01-05 21:52:34 |
Launchpad QA Bot |
launchpad: assignee |
|
Colin Watson (cjwatson) |
|
2016-01-05 21:52:35 |
Launchpad QA Bot |
tags |
buildfarm canonical-losa-lp lp-soyuz soyuz-build |
buildfarm canonical-losa-lp lp-soyuz qa-needstesting soyuz-build |
|
2016-01-05 21:52:36 |
Launchpad QA Bot |
launchpad: status |
Triaged |
In Progress |
|
2016-01-05 22:18:03 |
Colin Watson |
tags |
buildfarm canonical-losa-lp lp-soyuz qa-needstesting soyuz-build |
buildfarm canonical-losa-lp lp-soyuz qa-ok soyuz-build |
|
2016-01-06 12:25:29 |
Launchpad Janitor |
branch linked |
|
lp:~cjwatson/launchpad/bpb-external-dependencies |
|
2016-01-07 14:20:42 |
Launchpad QA Bot |
tags |
buildfarm canonical-losa-lp lp-soyuz qa-ok soyuz-build |
buildfarm canonical-losa-lp lp-soyuz qa-needstesting soyuz-build |
|
2016-01-07 14:20:43 |
Launchpad QA Bot |
launchpad: status |
In Progress |
Fix Committed |
|
2016-01-07 18:12:37 |
Colin Watson |
tags |
buildfarm canonical-losa-lp lp-soyuz qa-needstesting soyuz-build |
buildfarm canonical-losa-lp lp-soyuz qa-ok soyuz-build |
|
2016-01-07 18:34:47 |
Launchpad Janitor |
branch linked |
|
lp:~cjwatson/launchpad/bpb-external-dependencies-2 |
|
2016-01-07 18:38:45 |
Colin Watson |
launchpad: status |
Fix Committed |
In Progress |
|
2016-01-08 14:45:34 |
Launchpad QA Bot |
tags |
buildfarm canonical-losa-lp lp-soyuz qa-ok soyuz-build |
buildfarm canonical-losa-lp lp-soyuz qa-needstesting soyuz-build |
|
2016-01-08 14:45:34 |
Launchpad QA Bot |
launchpad: status |
In Progress |
Fix Committed |
|
2016-01-08 17:30:52 |
Colin Watson |
tags |
buildfarm canonical-losa-lp lp-soyuz qa-needstesting soyuz-build |
buildfarm canonical-losa-lp lp-soyuz qa-ok soyuz-build |
|
2016-01-12 12:19:25 |
Colin Watson |
launchpad: status |
Fix Committed |
Fix Released |
|