yahoo-eng-team team mailing list archive

[Robie Basak <1827204@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

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.

** Affects: cloud-init
     Importance: Undecided
         Status: New

-- 
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:
  New

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