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
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
