To reproduce (I've successfully reproduced the issue three
times in a row now, although sometimes one or other of the
unit agents does manage to upgrade successfully)
# deploy a 1.16 environment:
$ pwd
/home/rog/src/go/src/launchpad.net/juju-core/
$ bzr update -r juju-1.16.4
$ go install ./...
$ juju bootstrap
$ juju deploy wordpress
$ juju deploy mysql
$ juju add-relation wordpress mysql
# wait for services to start successfully
$ bzr update
$ bzr revision-info --tree
2509 tarmac-20140328183634-d639ea10wem30lfv
# use 1.18 as version number to avoid development-version
# logic.
$ ed version/version.go
/version = /s/".*"/"1.18.0"/
w
q
$ go install ./...
$ juju upgrade-juju --upload-tools
$
Sample status from the resulting environment is appended at the end of this description;
all-machines.log is attached.
The wordpress/0 unit has failed to come up.
Looking at the logs, it seems that the agent upgrades to 1.18,
but then the DesiredVersion API call returns 1.16 again
(this is weird), so it downgrades, but then the agent
configuration file is not compatible, because 1.18 config
files are not readable by 1.16 agents.
To reproduce (I've successfully reproduced the issue three
times in a row now, although sometimes one or other of the
unit agents does manage to upgrade successfully)
# deploy a 1.16 environment: src/go/ src/launchpad. net/juju- core/ 20140328183634- d639ea10wem30lf v
$ pwd
/home/rog/
$ bzr update -r juju-1.16.4
$ go install ./...
$ juju bootstrap
$ juju deploy wordpress
$ juju deploy mysql
$ juju add-relation wordpress mysql
# wait for services to start successfully
$ bzr update
$ bzr revision-info --tree
2509 tarmac-
# use 1.18 as version number to avoid development-version
# logic.
$ ed version/version.go
/version = /s/".*"/"1.18.0"/
w
q
$ go install ./...
$ juju upgrade-juju --upload-tools
$
Sample status from the resulting environment is appended at the end of this description;
all-machines.log is attached.
The wordpress/0 unit has failed to come up.
Looking at the logs, it seems that the agent upgrades to 1.18,
but then the DesiredVersion API call returns 1.16 again
(this is weird), so it downgrades, but then the agent
configuration file is not compatible, because 1.18 config
files are not readable by 1.16 agents.
$ juju status bucket- region" 82-187- 161.compute- 1.amazonaws. com 82-25-135. compute- 1.amazonaws. com 80-24-48. compute- 1.amazonaws. com
agent- state: started
agent- version: 1.18.0.1
public- address: ec2-54- 80-24-48. compute- 1.amazonaws. com wordpress- 21
agent- state: down
agent- state-info: (started)
agent- version: 1.18.0.1
public- address: ec2-54- 82-25-135. compute- 1.amazonaws. com
WARNING unknown config field "public-bucket"
WARNING unknown config field "public-
environment: sparse
machines:
"0":
agent-state: started
agent-version: 1.18.0.1
dns-name: ec2-54-
instance-id: i-e383d6b2
instance-state: running
series: precise
hardware: arch=amd64 cpu-cores=1 cpu-power=100 mem=1740M root-disk=8192M
"1":
agent-state: started
agent-version: 1.18.0.1
dns-name: ec2-54-
instance-id: i-db88dd8a
instance-state: running
series: precise
hardware: arch=amd64 cpu-cores=1 cpu-power=100 mem=1740M root-disk=8192M
"2":
agent-state: started
agent-version: 1.18.0.1
dns-name: ec2-54-
instance-id: i-348cd965
instance-state: running
series: precise
hardware: arch=amd64 cpu-cores=1 cpu-power=100 mem=1740M root-disk=8192M
services:
mysql:
charm: cs:precise/mysql-38
exposed: false
relations:
cluster:
- mysql
db:
- wordpress
units:
mysql/0:
machine: "2"
wordpress:
charm: cs:precise/
exposed: false
relations:
db:
- mysql
loadbalancer:
- wordpress
units:
wordpress/0:
machine: "1"
open-ports:
- 80/tcp