launchpad development
Overview
Launchpad entry: https://blueprints.edge.launchpad.net/soyuz/+spec/buildd-manager-upload-decoupling
Created: 2008-16-07 by JulianEdwards
Contributors:
Depends on:
Overall Summary
Summary: When processing completed uploads, the buildd manager puts the binary package in the upload queue. calls process-upload.py (using Popen) and then does post-upload processing that sets on the build: the buildlog, the builder used, its dependencies, date built and build duration. It also post-processes upload failures and sets the upload log.
The processing should take place entirely in the upload processor so that the buildd-manager can throw the binary package in the queue and forget about it, this reducing the latency when scanning the build farm.
Goal/Deliverables: The initial deliverable will allow the buildd-manager to not have to run process-upload itself.
Release Note
Rationale
Use cases
Assumptions
User Interface
High-level implementation points
lib/lp/buildmaster/buildergroup.py has a method buildStatus_OK() that's called when the build finishes OK. It is responsible for calling Popen() on process-upload.py and then calls storeBuildInfo() to update the build record. It also deals with upload failures by inspecting what process-upload did. 
We can refactor storeBuildInfo() into the build class itself. Other types of failures in the buildd-manager still need to use it so it can't be completely ripped out and put in process-upload.
Finally, process-upload should deal with the binary upload failures itself so the buildd-manager doesn't have to inspect what p-u did.
Implementation Plan
Code Changes
Schema Changes
None
Estimations
Migration
Include:
- data migration, if any
- redirects from old URLs to new ones, if any
how users will be pointed to the new way of doing things, if necessary. (If your change is big enough, consider using the rollout template.)
