3 ms·

TL;DR: a decade ago Ubuntu wanted to update a few computers first, then more computers if no issues were detected. Due to missing tooling, this didn't hit mains

TL;DR: a decade ago Ubuntu wanted to update a few computers first, then more computers if no issues were detected. Due to missing tooling, this didn't hit mainstream until now. A practical problem with these phased updates is that you may end up with different versions of some software on your fleet of (until now) identical servers and you have no way of avoiding it.

danw1979 4y ago
> then more computers if no issues were detected. .. a job they should have left to the sysadmins in charge of those machines receiving said updates.
- charcircuit 4y ago
  Why do you think pushing out broken updates to people and causing them to do extra work is a good thing? It's something that should happen as little as possible. If the OS developers have the ability to save thousands of man hours of their users they should do so.
- SahAssar 4y ago
  Ubuntu does a lot of things in both server and desktop that might only make sense on desktop (if even there).
ekianjo 4y ago
You do have a way of avoiding it as mentioned in the link by setting an identical machine id string
- AshamedCaptain 4y ago
  And then after reusing /etc/machine-id everywhere you spend the day after that debugging miscellaneous systemd issues.
  - drothlis 4y ago
    In the article they don't change /etc/machine-id, but APT::Machine-ID in apt.conf.
brnt 4y ago
Who runs a fleet without their own apt cache server?
- Symbiote 4y ago
  I do, since there's an official apt mirror in the same datacentre.
  - brnt 4y ago
    That should isolate you from this issue, shouldn't it?
- soneil 4y ago
  I don't believe mirrors and caches affect this behaviour. How this works is that the package index contains a stanza Phased-Update-Percentage: giving a number between 0 and 100. Then your client picks a number in the same range, and accepts an update if the repository's value is higher than the client's value. Whether the fixed value comes from your mirror or Ubuntu's, makes no odds - You still have a fixed value on the server and a variable value on the client, so the outcome is still variable. Caching the index, or mirroring it without regenerating it, still leaves this decision to the end client. Something else I found interesting looking into this mechanism - the seed for the rng is sourcePackage-version-machineID. So you won't "that one machine that always updates last" or "that one machine that charges head-first into phased updates", it should be randomly distributed for each version of each package.
philjohn 4y ago
There is a way to avoid it, disable phased updates as detailed here: https://news.ycombinator.com/item?id=34388575 https://news.ycombinator.com/item?id=34388575

danw1979 4y ago

> then more computers if no issues were detected. .. a job they should have left to the sysadmins in charge of those machines receiving said updates.

charcircuit 4y ago
Why do you think pushing out broken updates to people and causing them to do extra work is a good thing? It's something that should happen as little as possible. If the OS developers have the ability to save thousands of man hours of their users they should do so.
SahAssar 4y ago
Ubuntu does a lot of things in both server and desktop that might only make sense on desktop (if even there).

ekianjo 4y ago

You do have a way of avoiding it as mentioned in the link by setting an identical machine id string

AshamedCaptain 4y ago
And then after reusing /etc/machine-id everywhere you spend the day after that debugging miscellaneous systemd issues.
- drothlis 4y ago
  In the article they don't change /etc/machine-id, but APT::Machine-ID in apt.conf.

brnt 4y ago

Who runs a fleet without their own apt cache server?

Symbiote 4y ago
I do, since there's an official apt mirror in the same datacentre.
- brnt 4y ago
  That should isolate you from this issue, shouldn't it?
soneil 4y ago
I don't believe mirrors and caches affect this behaviour. How this works is that the package index contains a stanza Phased-Update-Percentage: giving a number between 0 and 100. Then your client picks a number in the same range, and accepts an update if the repository's value is higher than the client's value. Whether the fixed value comes from your mirror or Ubuntu's, makes no odds - You still have a fixed value on the server and a variable value on the client, so the outcome is still variable. Caching the index, or mirroring it without regenerating it, still leaves this decision to the end client. Something else I found interesting looking into this mechanism - the seed for the rng is sourcePackage-version-machineID. So you won't "that one machine that always updates last" or "that one machine that charges head-first into phased updates", it should be randomly distributed for each version of each package.

philjohn 4y ago

There is a way to avoid it, disable phased updates as detailed here: https://news.ycombinator.com/item?id=34388575 https://news.ycombinator.com/item?id=34388575