override mismatch race needs to be fixed
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Launchpad itself |
Fix Released
|
High
|
Colin Watson | ||
Bug Description
I'm spending a large chunk of my day today fixing component override mismatches between architectures (54 in total), and I think it's high time we fixed the race. A rather simple approach is outlined below (forgive me if I get terminology wrong, I know conceptually how it works, but haven't rooted around in the internals):
As I understand it, if an ftpmaster changes a component override while a build is "in the wild", the build in question stands a chance of inheriting the old override, instead of the new one, this can be fixed by doing the following:
1) When change-override.py is run, it needs to act not only on active publishee records, but on pending publisher records and, most importantly, on queue data (as if the user had also run "queue override"), by walking the appropriate suite's queues for binaries/sources matching the request and acting on them as well.
2) When a new upload comes in, we need to check queue data, pending publisher records, and active publisher records (in that priority order) to divine which overrides we need to assign to the incoming upload.
With those two changes, while there may still be a tiny race (perhaps completely removable with table or row locking) during the actual change-override.py run itself, we eliminate the huge window of opportunity for mismatched components that we currently seem to have.
For the record, this isn't just an aesthetic issue, having mismatched overrides completely breaks DAK for our security and autotest buildds.
Related branches
- William Grant: Approve (code)
-
Diff: 721 lines (+252/-164)5 files modifiedlib/lp/archivepublisher/domination.py (+81/-18)
lib/lp/archivepublisher/tests/test_dominator.py (+149/-85)
lib/lp/soyuz/interfaces/publishing.py (+13/-1)
lib/lp/soyuz/model/publishing.py (+3/-18)
lib/lp/soyuz/tests/test_publishing.py (+6/-42)
| Changed in soyuz: | |
| assignee: | nobody → cprov |
| importance: | Undecided → High |
| milestone: | none → 1.2.1 |
| status: | New → Triaged |
| Changed in soyuz: | |
| milestone: | 1.2.1 → 1.2.2 |
| Changed in soyuz: | |
| milestone: | 1.2.2 → 1.2.3 |
| status: | Triaged → Confirmed |
| Adam Conrad (adconrad) wrote | #1 |
| Celso Providelo (cprov) wrote | #2 |
| Changed in soyuz: | |
| status: | Confirmed → In Progress |
| Celso Providelo (cprov) wrote | #3 |
| Changed in soyuz: | |
| milestone: | 1.2.3 → 1.2.4 |
| Celso Providelo (cprov) wrote | #4 |
| Changed in soyuz: | |
| milestone: | 1.2.4 → 1.2.6 |
| status: | In Progress → Triaged |
| Changed in soyuz: | |
| milestone: | 1.2.6 → none |
| status: | Triaged → Confirmed |
| William Grant (wgrant) wrote | #5 |
| Changed in soyuz: | |
| milestone: | none → pending |
| Changed in soyuz: | |
| assignee: | Celso Providelo (cprov) → nobody |
| tags: | added: package-overrides |
| Changed in launchpad: | |
| status: | Triaged → In Progress |
| assignee: | nobody → Colin Watson (cjwatson) |
| Launchpad QA Bot (lpqabot) wrote | #6 |
| tags: | added: qa-needstesting |
| Changed in launchpad: | |
| status: | In Progress → Fix Committed |
| tags: |
added: qa-ok removed: qa-needstesting |
| Changed in launchpad: | |
| status: | Fix Committed → Fix Released |
I noticed another misbehaviour (IMO) of change-override.py today. When you invoke it with -S (source and binaries), it only acts on binaries tied to the most recent published source. For instance, assuming we have this published:
foo/main (1.2.3): source, amd64, powerpc, i386, lpia, sparc
foo/main (1.2.2): ia64
foo/main (1.2.1): hppa
If I invoke "change-override -s hardy -c universe -S foo", I'll get the following:
foo/universe (1.2.3): source, amd64, powerpc, i386, lpia, sparc
foo/main (1.2.2): ia64
foo/main (1.2.1): hppa
This is incorrect, as all "foo" binaries in a given suite (in this case, hardy) should always be in the same component, regardless of version. Asking to move one should move them all.