juju should run apt-get update

[Matt Bruzek]

I am attempting to deploy charms on the local provider on IBM Power systems. The charms are failing to install because the apt-get metadata is stale.

The problem does not appear to be related to the use of proxies.

All the charms on the IBM Power system that call "apt-get install" have failed with this error message:
2014-06-30 21:20:06 INFO install E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?
2014-06-30 21:20:06 ERROR juju.worker.uniter uniter.go:482 hook failed: exit status 100

The unit log can be found here: http://pastebin.ubuntu.com/7728552/

I believe this problem is due to apt-get update not getting called in cloud-init. The cloud image on the system has the date of 05/28/2014 (current date is 07/01/2014).

A colleague was getting this same error message on x86 and the local provider presumably because his cloud image was out of date and no apt-get update was run.

Juju should either run apt-get update or download a new cloud image more frequently.

Please let me know if you need any more information.

[Matt Bruzek (mbruzek)]

This problem might be more related to the age of the cloud image and not the proxies as I originally thought. In both cases the age of the cloud image was old. Does Juju maintain the freshness of the image?

[Antonio Rosales (arosales)]

Also can we get clarification on if "apt-get update" is going to be a environment.yaml config option to have it on or off be default? It would be advantageous to have this be a environment.yaml key value.

[Antonio Rosales (arosales)]

mbruzek and lazypower have both confirmed this is breaking existing charms. Thus we should endeavor to keep the same functionality in upgrading from 1.18, and make the value a config option to the user (default being to run apt-get update).

-thanks,
Antonio

[Andrew Wilkins (axwalk)]

I believe this is a local-provider only thing. The local provider was changed to clone a template container, and only the original template does the "apt-get update".

While this is a regression, I would argue that the charms should do "apt-get update" themselves. Users may deploy charms to existing machines, which may have been provisioned a long time before and so have an out of date APT index.

[Curtis Hovey (sinzui)]

Thank you Andrew. I have deployed charms to manually provisioned machines and gotten old packages. I had not considered that my lxc templates were stale. The fix is to manually start the container, apt-get update, then stop the container.

[José Antonio Rey (jose)]

I believe this should be something done automatically. You do not want to tell a user 'go open your LXC template and do everything manually'. Otherwise, where would the magic be?

Yes, this breaks existing charms unless they have a line doing an apt-get update. I believe this should be taken with a high priority as it *breaks* things for users working with the local provider.

[James Tunnicliffe (dooferlad)]

Spotted this same problem on nodes that had been up for several days and then I wanted a KVM. I think we need to detect when apt-get tells us that we should update or --fix-missing and actually do that.