Ubuntu Wiki

• Launchpad Entry: foundations-p-image-build-pipeline

• Created: 2011-11-09

• Contributors: ColinWatson, AdamConrad, LaMontJones, KateStewart, JamesTroup

• Packages affected: germinate, Launchpad, cdimage

Summary

Shorten the time required to get from a developer source upload to a full set of updated image builds on all architectures.

Release Note

This feature has no end-user impact.

Rationale

When preparing milestone releases, we often need to turn around fixes quickly. The pipeline from a developer source upload to a full set of updated image builds on all architectures is currently somewhere in the region of nine hours. We would like to make this much quicker.

Design

Publishing

The publisher currently runs Germinate 40 times to compute Task fields and the like. This is a necessary operation, but it could be much more efficient. We will expose a Python interface to Germinate for Launchpad to use directly, and arrange for it to involve much less repeated work; at the very least, Packages and Sources files are being scanned eight times as often as they need to be, and likewise the core parts of the seed structure are being expanded eight times as often as they need to be.

As a stretch goal, given this work it should be possible to have Germinate operate on the to-be-published state of the archive rather than on the just-published state, thereby eliminating a very long-standing source of hysteresis: certain changes require two publisher runs to settle properly.

We discussed an option to disable Germinate for certain quick runs, but it should not be necessary after this work.

We discussed switching to "no-more-apt-ftparchive", the publisher scheme used for PPAs. This does not currently support all the fine details of the primary archive, and would need more work; it is also not obvious that it would necessarily speed up publishing of the primary archive. We have no objection to further work in this area but it is not a priority.

Live filesystem building

Mirroring

Implementation

This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like:

Code Changes

Code changes should include an overview of what needs to change, and in some cases even the specific details.

Unresolved issues

This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.

BoF agenda and discussion

Live File System building
adconrad - working on this.
livefs benefit from qemu (I/O bound)
- offloading tarball at end

CD image building to new SAN has no blockers, timing of using next week works from release team and IS perspective.

Keep mirroring to be under control of cdimage. Not sure if we can cope with mirror changing in middle of build.

What is state of lmirror? is it worth deploying?
Timeview map - map where time is spent across entire process. Relative timing.

Move Wubi into archive?

Timings during livefs build:
- mirror syncing at start 1 m
- germinate 2-3m
- downloading live filesystem images: 1m
- assemble livefs isos: 4m
- making meta files: 1.5 min

For non livefs builds:
- assemble isos: 10 min

rsync of ftp from cocoplum to antimony 2.5 min; no writing. Controlled testing is probably needed, Was it in the minute of a publishing run?

antimony is already I/O bound - desired unfulfilled potential
elmo has old graphs

CD builder trigger ISO testing.

Want way of saying which builder do this? buildd affinity. Maybe time to revisit

CategorySpec