1.20.x local provider not running apt-get update

[Antonio Rosales]

Our recent charm testing on Power has showed failures due to the install hook not running "apt-get update" by default in Juju 1.20.x

This is a regression and breaks backwards compatibility in charms. As discussed on the Juju list[0] we should keep the defaults we have had in past Juju releases (ie apt-get update and apt-get upgrade on for all providers), but provide an environment.yaml option to turn it off (default being on).

For the apt-get update scenario I think it is essential to have the default case be apt-get update on so we can ensure users are getting critical security updates. Now if the user wants to turn that off they have to make a conscious decision.

Aside from getting recent security updates charms that were working on 1.18 are now failing on 1.20. This bug is being filled to change the default behavior in all providers to apt-get update being on, and hopefully landing soon an option in environments.yaml to turn apt-get update off.

[0] https://lists.ubuntu.com/archives/juju-dev/2014-July/002844.html

-thanks,
Antonio

[Ian Booth (wallyworld)]

I have investigated the code and confirmed that apt commands are disabled if lxc-clone = true.
It appears this change was done back in January before 1.18 shipped.

Juju 1.20 ships with lxc-clone true by default, whereas earlier versions had it turned off. The way to restore previous behaviour is to simply to configure locally deployed environments with lxc-clone=false in environments.yaml.

The reason lxc-clone is now true is because of requests from the MAAS guys and customers to make local provider faster.

There's work in progress to allow apt-get upgrade to be optional. As part of that work, I think we should revisit the decision to turn off apt commands when cloning.

I'm taking this bug off 1.20 since there's an easy way to restore the older behaviour, and we have a broader fix coming for 1.21. If there are concerns with that, let me know.

[Stuart Bishop (stub)]

As an example of how this causes charms to fail, the PostgreSQL charm installs the language-pack-en package. If the apt cache has not recently been updated, it may well be referencing an old version that has since been removed from the archive and the install hook fails.

[Stuart Bishop (stub)]

ubuntu@stub-local-machine-5:~$ sudo apt-get install language-pack-en
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer required:
  libfreetype6 os-prober
Use 'apt-get autoremove' to remove them.
The following extra packages will be installed:
  firefox-locale-en language-pack-en-base
The following NEW packages will be installed:
  firefox-locale-en language-pack-en language-pack-en-base
0 upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
Need to get 1,668 kB of archives.
After this operation, 6,619 kB of additional disk space will be used.
Do you want to continue? [Y/n]
Get:1 http://archive.ubuntu.com/ubuntu/ trusty/main language-pack-en-base all 1:14.04+20140410 [850 kB]
Err http://archive.ubuntu.com/ubuntu/ trusty-updates/main language-pack-en all 1:14.04+20140522
  404 Not Found
Err http://archive.ubuntu.com/ubuntu/ trusty-updates/main firefox-locale-en amd64 30.0+build1-0ubuntu0.14.04.3
  404 Not Found
Err http://security.ubuntu.com/ubuntu/ trusty-security/main firefox-locale-en amd64 30.0+build1-0ubuntu0.14.04.3
  404 Not Found
Fetched 850 kB in 0s (3,644 kB/s)
E: Failed to fetch http://archive.ubuntu.com/ubuntu/pool/main/l/language-pack-en/language-pack-en_14.04+20140522_all.deb 404 Not Found

E: Failed to fetch http://security.ubuntu.com/ubuntu/pool/main/f/firefox/firefox-locale-en_30.0+build1-0ubuntu0.14.04.3_amd64.deb 404 Not Found

E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?

[Katherine Cox-Buday (cox-katherine-e)]

I intend on doing a longer write-up on this, but the tldr; is: a fix was just landed in trunk that presents two new configuration variables: enable-os-refresh-update, and enable-os-upgrade. If you want an absolute behavior, set these two and Juju will do exactly as you ask. If they are unspecified, Juju will revert to previously documented behavior.