Doesn't run unattended-upgrades on first boot by default

This bug was originally filed in Launchpad as [LP: #1827204](https://bugs.launchpad.net/cloud-init/+bug/1827204)

Launchpad details

affected_projects = []

assignee = None

assignee_name = None

date_closed = None

date_created = 2019-05-01T12:01:01.780209+00:00

date_fix_committed = None

date_fix_released = None

id = 1827204

importance = medium

is_complete = False

lp_url = https://bugs.launchpad.net/cloud-init/+bug/1827204

milestone = None

owner = racb

owner_name = Robie Basak

private = False

status = triaged

submitter = racb

submitter_name = Robie Basak

tags = []

duplicates = []

_Launchpad user **Robie Basak(racb)** wrote on 2019-05-01T12:01:01.780209+00:00_

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.

Start by reviewing the proposed first-boot behavior, the existing unattended-upgrades scheduling, and the distinction from package_upgrade and bootcmd/run-once described in the issue. Define the intended default behavior and its effects on old images, then identify the project tests needed to verify that security updates run before deployment without applying all package updates.

Written by the indexing model from the issue text.