enable-os-refresh-update and enable-os-upgrade config options are ignored

[Adam Israel]

Juju version: 2.4.4-bionic-amd64 (snap/stable)

Description:

We're bootstrapping a controller to lxd and disabling the os refresh/upgrade because we're pre-caching the lxc image used by juju (apt update/upgrading, installing additional packages, etc). While updating this process, I noticed that the refresh/upgrade is still running, despite being disabled by config.

Expected behavior:

When Juju instantiates a new machine, apt-get update and apt-get upgrade will not be run.

Observed behavior:

apt-get update and apt-get upgrade are being run.

Steps to recreate:

$ juju bootstrap lxd devel --config enable-os-refresh-update=false --config enable-os-upgrade=false

$ juju model-config
[...]
enable-os-refresh-update model false
enable-os-upgrade model false
[...]

$ juju add-machine

As soon as the machine is created by lxc, tail cloud-init, i.e.,

$ lxc exec juju-c4a855-0 -- tail -f /var/log/cloud-init-output.log
Cloud-init v. 18.4-0ubuntu1~18.04.1 running 'modules:config' at Fri, 02 Nov 2018 16:29:52 +0000. Up 7.00 seconds.
Hit:1 http://archive.ubuntu.com/ubuntu bionic InRelease
Get:2 http://security.ubuntu.com/ubuntu bionic-security InRelease [83.2 kB]
Get:3 http://archive.ubuntu.com/ubuntu bionic-updates InRelease [88.7 kB]
Get:4 http://archive.ubuntu.com/ubuntu bionic-backports InRelease [74.6 kB]
Fetched 247 kB in 1s (202 kB/s)
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
tmux is already the newest version (2.6-3).
curl is already the newest version (7.58.0-2ubuntu3.5).
[...]

[Heather Lanigan (hmlanigan)]

Just a few notes on this bug:

1. Unless you have pre-cached images such as this user, "juju bootstrap lxd devel --config enable-os-refresh-update=false --config enable-os-upgrade=false" will fail because juju's attempt to install mongo packages fails with not found.

2. --config enable-os-refresh-update=false sets package_update to false in the user-data.txt for cloud-init. From the cloud init docs:

     #cloud-config
     # Update apt database on first boot (run 'apt-get update').
     # Note, if packages are given, or package_upgrade is true, then
     # update will be done independent of this setting.
     #
     # Default: false
     # Aliases: apt_update
     package_update: false

https://cloudinit.readthedocs.io/en/latest/topics/examples.html?highlight=package_update#update-apt-database-on-first-boot

Juju does include packages to be installed in cloud init, currently a user can add to the list of installed packages, but not remove. A caveat is that for bootstrap, juju does not include any packages to be installed on first boot, only starting non bootstrap instances.

[Adam Israel (aisrael)]

Hi Heather,

re #1, the bootstrap succeeds just fine. To clarify, the two enable-os-* options apply to the model, when new machines are added manually via add-machine or when deploying a charm.

Previous observed behavior is that setting these flags to false will stop `apt-get update` and `apt-get upgrade` from running when juju provisions a machine.

This allows us to customize the image used by juju, with lxd in particular, by publishing an image with the alias 'juju/$series/$arch'.

[Joseph Phillips (manadart)]

Those config items affect cloud-init script behaviour itself, but after reproducing this I see this when dumping APT config:

APT::Periodic::Update-Package-Lists "1";

My guess is that when cloud-init apt-installs the packages that Juju needs, the package list is updated on account of not being previously run.

[John A Meinel (jameinel)]

I should note that plain --config doesn't apply to all models. You need to
use --model-default w bootstrap

Or 'juju model-defaults' after bootstrap or 'juju model-config' after
add-model.

John
=:->

On Nov 6, 2018 18:25, "Joseph Phillips" <email address hidden> wrote:

Those config items affect cloud-init script behaviour itself, but after
reproducing this I see this when dumping APT config:

APT::Periodic::Update-Package-Lists "1";

My guess is that when cloud-init apt-installs the packages that Juju
needs, the package list is updated on account of not being previously
run.

--
You received this bug notification because you are subscribed to juju.
Matching subscriptions: juju bugs
https://bugs.launchpad.net/bugs/1801391

Title:
  enable-os-refresh-update and enable-os-upgrade config options are
  ignored

To manage notifications about this bug go to:
https://bugs.launchpad.net/juju/+bug/1801391/+subscriptions

[Adam Israel (aisrael)]

But apt-get has been previously run, when the custom image was built.

Here's a version of the script I use: https://pastebin.canonical.com/p/Jc8Y2Jk9yG/

I build a custom image for Juju to use, installing several packages common to the reactive charm framework, and dependencies of the project it's being used with. All of this is with a goal of speeding up deployment time of charms on LXD.

If I add the cloud-init packages in my build script (bridge-utils, cloud-utils, cpu-checker, tmux, ubuntu-fan, curl), cloud-init finishes a bit faster but it's still doing an apt-get update.

I tried `juju model-config`, per John's suggestion, to set both 'enable-os-' and verified that apt-get update is still run for new machines added to the model.

[Canonical Juju QA Bot (juju-qa-bot)]

This bug has not been updated in 2 years, so we're marking it Low importance. If you believe this is incorrect, please update the importance.