yahoo-eng-team team mailing list archive

[James Falcon <1827204@xxxxxxxxxxxxxxxxxx>]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/3376

** Bug watch added: github.com/canonical/cloud-init/issues #3376
   https://github.com/canonical/cloud-init/issues/3376

** Changed in: cloud-init
       Status: Triaged => Expired

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1827204

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

Status in cloud-init:
  Expired

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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1827204/+subscriptions