juju should run apt-get update

Bug #1336353 reported by Matt Bruzek on 2014-07-01
This bug affects 4 people
Affects Status Importance Assigned to Milestone

Bug Description

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.

Curtis Hovey (sinzui) on 2014-07-01
tags: added: proxy
Changed in juju-core:
status: New → Triaged
importance: Undecided → High
milestone: none → next-stable
Matt Bruzek (mbruzek) wrote :

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?

Matt Bruzek (mbruzek) on 2014-07-01
summary: - juju should run apt-get update when using proxies
+ juju should run apt-get update
Matt Bruzek (mbruzek) on 2014-07-01
description: updated
Antonio Rosales (arosales) wrote :

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) wrote :

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).


Andrew Wilkins (axwalk) wrote :

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) wrote :

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) wrote :

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.

Curtis Hovey (sinzui) on 2014-10-22
tags: added: charm deploy
Curtis Hovey (sinzui) on 2014-10-28
Changed in juju-core:
importance: High → Medium
milestone: next-stable → none
James Tunnicliffe (dooferlad) wrote :

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.

Changed in juju-core:
status: Triaged → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers