cannot specify specific chroot for a build

The builders are exposed on the API and you can set "manual" there for any as you see fit. You can also bump the priority of a particular build to force it to be next in the queue using the API.

I don't think there's anything else we need to do for you to be able to do this, is there?

The problem is that when doing a bootstrap build we seem to use a custom chroot that must not be used by any other build.

There is a race when enablement returns a builders, it comes back automatically in automatic and could get a build dispatched using the custom chroot.

(See https://wiki.canonical.com/InformationInfrastructure/OSA/BootstrappingPackages for the process.)

Maybe what is needed is a way to specify per builder the chroot to use. That way, to do bootstrapping we would need a way to specify a custom chroot for a specific builder and a way to dispatch a build to that builder. The rest of the build farm could continue it's normal activity at that time.

Escalated via the ISO/LP call.

Chroots are currently picked on the basis of the build job.

The right way of fixing this is some way of extending this so that we can specify that a particular build needs a particular chroot. Specifying chroots per builder won't help much because you still need all the other hoop-jumping.

Of course, that's even a lot better! LaMont, do you agree?

So this probably needs something like:
 - a X- header in the dsc (to avoid race conditions)
 - -> mirrored into the datamodel (in SPPH ?)
 - which is permitted to refer to a chroot
 - do chroots need to be only provided by archive admins?
   * if so (because they can attack the buildd), then from a preset list
   * if not, then allow them to be attached to e.g. an Archive by anyone with edit

The permissions on anything to do with buildd management should have something to do with the launchpad-buildd-admins celebrity; e.g. the existing AdminByBuilddAdmin helper class in security.py.

Nowadays, we don't generally use a custom chroot for bootstrapping; I don't recall any instance in the last two years when this has been necessary. Rather, the chroots for the current development series have a manually-maintained bootstrap archive in their sources.list, which is normally kept empty but can be populated with a handful of packages if need be (or indeed an entire stage-N archive when bootstrapping a new architecture). For more extreme cases we can use devirtualised PPAs of other series or a different selection of pockets to dig ourselves out of holes; the need for that is even rarer.

This is almost good enough, and it's certainly more auditable since packages fetched from the bootstrap archive show up in build logs as such, but it's still not ideal because in theory the bootstrap archive can affect any devel build that happens to be scheduled. However, the modern approach suggests a simpler solution to this problem. How about we add a column to BinaryPackageBuild that's only writeable by launchpad-buildd-admins and that contains an extra sources.list line? This could then be set over the API, either directly (for already-pending builds) or by way of a keyword argument to the retry method, and BinaryPackageBuildBehaviour would include that in the sources.list lines it sends to the builder when dispatching the build. That seems relatively simple and almost elegant to me, and doesn't open any security problems that aren't already present (since buildd-admins can upload modified chroots anyway).

Indeed, this could look very like Archive.external_dependencies, and just be BinaryPackageBuild.external_dependencies with the same semantics except that it wouldn't need %(series)s substitution.

Actually only archive admins can upload modified chroots, not buildd admins. We can perhaps debate the right security setting for this.

r13311 in db-stable (http://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-stable/revision/13311) is part of this bug's fix.

2016-01-05 21:41:31,594 INFO 2209-72-0 applied just now in 0.0 seconds

Fixed in stable r17881 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/17881>.

This can still build things normally and so is safe to deploy, but I missed the necessary change to get_sources_list_for_building so it doesn't actually take effect. Whoops.

Fixed in stable r17883 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/17883>.