Tweak the candidate path scoring algorithm
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Ubuntu system image |
Fix Released
|
High
|
Barry Warsaw |
Bug Description
In the course of investigating LP: #1250181 we encountered another issue. When some of the delta images were pulled from the server, it lead to a winning upgrade path through broken deltas (of course s-i doesn't know the deltas were broken).
The reason this path one is because of how sizes and distance-
stgraber and I discussed a tweak to the scoring algorithm which would prevent this bogus winner.
Instead of adding 1 for distance-from-max, we'll first filter out any candidate path that doesn't lead to the highest build number. Then we do the scoring as normal: add 1 for every MiB > smallest + 100 for every reboot flag.
The caveat here is that the server has to guarantee that every upgrade path leads to the maximum build number, even if it's only through a full upgrade. E.g. if there are only deltas offered, but none of the delta paths leave you at the max, you'll filter all of them out and the device will think it's up-to-date (i.e. there are no candidate upgrade paths available). stgraber thinks this is a reasonable assumption. Still, I think that's the worst that can happen, and --filter=full or -b 0 will probably unstick you albeit only through the cli.
Related branches
tags: | added: client |
Changed in ubuntu-system-image: | |
status: | Triaged → In Progress |
Changed in ubuntu-system-image: | |
status: | In Progress → Fix Committed |
Changed in ubuntu-system-image: | |
status: | Fix Committed → Fix Released |
Well, actually --filter=full or -b 0 won't unstick you since the only case you can get stuck in is if you're on a delta-only channel with a broken delta chain :)
If there's any full image available, an upgrade path will also be available and so you'll never be stuck.