Doesn't run unattended-upgrades on first boot by default
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| cloud-init |
Expired
|
Medium
|
Unassigned | ||
Bug Description
Use case: I bake an Ubuntu cloud image for a reproducible deployment, leaving most things as default except the specific bits I need. Since I know that unattended-upgrades deals with security updates automatically by default, I don't worry about this, and expect it to be OK to put an instance based on this baked image in production, even months later.
Expected behaviour: on deployment of the image and completion of cloud-init the instance is ready and my automated deployment system can take over to put the instance into production without any further unusual disruption.
Actual behaviour: the next nightly unattended-upgrades run is a mammoth one and causes significant downtime as a consequence, far more than a regular nightly run, on the instance I only just freshly put into production. See bug 1819033 for an example.
Suggestion: cloud-init could detect if unattended-upgrades is scheduled to run, and if it is, run it on first boot, by default, to catch up before the instance gets put into production. I further suggest that this should be default behaviour.
Note: "package_upgrade: true" isn't quite sufficient because it installs all updates, not just security updates, so isn't exactly equivalent. The user could run unattended-upgrades directly using run-once in a bootcmd or something to get closer. But it seems to me that this entire scenario is a trap. The user shouldn't need to know to do arrange this. We should do the sensible thing by default.
One downside is that when experimenting or developing the instance will take longer to boot. I don't think this should be much of a problem though, since it will only affect old images. It also seems reasonable to me that an old image (assuming it is enabled for unattended-upgrades in the security pocket) is brought up to date for security before being put into production, rather than after a delay, and cloud-init seems to be the right place for that to happen.
I'm filing this bug to provide a place for further discussion: my proposed solution may not be the correct one.
| Ryan Harper (raharper) wrote | #1 |
| Changed in cloud-init: | |
| importance: | Undecided → High |
| status: | New → Triaged |
| Changed in cloud-init: | |
| importance: | High → Medium |
| James Falcon (falcojr) wrote | #2 |
| Changed in cloud-init: | |
| status: | Triaged → Expired |
Thank you for capturing this scenario.