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.)

Unresolved issues

CategoryProposal CategoryTemplate