cloud-archive on precise not pinned when juju calls apt-get upgrade
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
juju-core |
Fix Released
|
Critical
|
Andrew Wilkins | ||
1.20 |
Fix Released
|
Critical
|
Andrew Wilkins |
Bug Description
TL;DR
juju-core, when deploying a new precise unit, calls apt-get upgrade with the cloud-archive repository in place and not pinned, meaning existing precise packages can be upgraded to newer versions in the cloud-archive. This is happening right now with twisted, where the 11.1 version in precise is being upgraded to 13.2 that comes from the cloud-archive.
This does not happen with the bootstrap node, where apt-get upgrade is called with the cloud-archive already pinned.
Details follow.
Since https:/
When bringing up a new unit, this is the order of events, regarding that repository, its pinning and apt-get calls:
1. cloud-archive sources list file created:
2. apt-get upgrade called
3. pinning file for the cloud archive created
Here are timings taken from a cs:precise/ubuntu deployment using juju-core 1.20.7: http://
The problem is that the apt-get upgrade call is made when the pinning is not yet in place. Currently, this means that, for example, twisted is upgraded from 11.1 to 13.2 (!) in precise. That's quite a leap for LTS customers.
I think the apt-get upgrade call should be made after the pinning is in place, or else you risk upgrading important packages by mistake.
In the bootstrap node I end up with twisted 11.1 installed as I should:
root@juju-
ii python-twisted-bin 11.1.0-1ubuntu2 Event-based framework for internet applications
ii python-twisted-core 11.1.0-1ubuntu2 Event-based framework for internet applications
ii python-
ii python-twisted-web 11.1.0-1 HTTP protocol implementation together with clients and servers
And the cloud-archive is there, pinned. Notice the candidate for python-
root@juju-
python-
Installed: 11.1.0-1ubuntu2
Candidate: 11.1.0-1ubuntu2
Version table:
13.
400 http://
*** 11.1.0-1ubuntu2 0
500 http://
100 /var/lib/
From the bootstrap --debug output, the order seems to be as I suggested above for the new unit case: add repository, pin, apt-get update, apt-get upgrade.
Found one one wrinkle, though: it creates the pinning file twice for some reason.
andreas@nsn7:~$ juju bootstrap --debug -v
2014-09-18 00:10:36 INFO juju.cmd supercommand.go:37 running juju [1.20.7-
...
2014-09-18 00:11:56 DEBUG juju.cloudinit.
code=$?
...
echo 'Adding apt repository: deb http://
add-apt-repository -y 'deb http://
printf '%s\n' 'Explanation: Pin with lower priority, not to interfere with charms
Package: *
Pin: release n=precise-
Pin-Priority: 400
' > '/etc/apt/
echo 'Running apt-get update' >&9
apt-get --option Dpkg::Options:
echo 'Running apt-get upgrade' >&9
...
install -D -m 644 /dev/null '/etc/apt/
printf '%s\n' 'Explanation: Pin with lower priority, not to interfere with charms
Package: *
Pin: release n=precise-
Pin-Priority: 400
' > '/etc/apt/
And when it's time to install mongo from the cloud archive, bootstrap is very specific in its command line:
Start-Date: 2014-09-18 00:12:57
Commandline: apt-get --option=
It selects the cloud archive to overcome the pinning.
tags: | added: cloud-installer landscape |
Changed in juju-core: | |
status: | New → Triaged |
importance: | Undecided → High |
Changed in juju-core: | |
importance: | High → Critical |
milestone: | none → 1.20.8 |
Changed in juju-core: | |
assignee: | nobody → Andrew Wilkins (axwalk) |
status: | Triaged → In Progress |
Changed in juju-core: | |
status: | In Progress → Fix Committed |
Changed in juju-core: | |
status: | Fix Committed → Fix Released |
This might be a trivial bug to fix. We need to ensure "apt-get upgrade" is called after, not *before* the cloud tools pocket is pinned.