buildds need to survive the buildd master being upgraded
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Launchpad itself |
Invalid
|
High
|
Unassigned | ||
Bug Description
I'm told that the buildds currently reset themselves or something, when the buildd master is shutdown and started up again.
This means that rollouts of code to the buildd master cause all builds to be interrupted, which has a significant impact on our users - as builds can be multi hour things, a single deployment causes hours of work to be wasted.
As part of the new stable-qa-deploy workflow we want to achieve a single revision of launchpad on all deployed services, which will mean rollouts to the buildd manager.
we're not *blocked* on this yet, because we can just not rollout the buildd manager initially. However as we ratchet up the pace, we'll start to run into friction unless the buildd manager is brought up to the same flexability we have with other services.
| Julian Edwards (julian-edwards) wrote | #1 |
| Changed in soyuz: | |
| status: | New → Incomplete |
| Robert Collins (lifeless) wrote | #2 |
| Changed in soyuz: | |
| status: | Incomplete → Invalid |
The build-manager most certainly does cope gracefully with this situation and I've never heard of slaves "resetting" themselves. We quite often restart the manager in production with no ill effect.
Can you please supply some more evidence for the problem?