<div dir="ltr"><div>Hi All,<br><br>We just encountered a really nasty problem: a "juju upgrade-charm" was appearing to cause the config-changed hook to run, and we were seeing what looked like a correct deploy, but in fact the changes in the local charms repository were not being reflected on the remote server.<br>

<br></div>We eventually ran --debug and saw the following:<br><div><div><div><br><div style="margin-left:40px">$ juju upgrade-charm --debug --repository ~/sw/charms custard-dev<br>2013-09-06 10:31:18 INFO juju.provider.ec2 ec2.go:187 opening environment "ec2"<br>

2013-09-06 10:31:19 DEBUG juju state.go:158 waiting for DNS name(s) of state server instances [i-...]<br>2013-09-06 10:31:25 INFO juju.state open.go:68 opening state; mongo addresses: ["..."]; entity ""<br>

2013-09-06 10:31:26 INFO juju.state open.go:106 connection established<br>2013-09-06 10:31:28 WARNING juju repo.go:341 charm: failed to load charm at "/home/pwaller/sw/charms/raring/munin-server": open /home/pwaller/sw/charms/raring/munin-server/metadata.yaml: no such file or directory<br>

2013-09-06 10:31:35 INFO juju supercommand.go:284 command finished<br></div><br></div><div>As it happens, munin-server is unrelated to what I was trying to deploy and has been untouched for months, yet we have been happily deploying all of this time.<br>

<br>I suspect that there has been a recent behaviour change, I'm on 1.13.2-precise-amd64.<br><br></div><div>This "WARNING" should surely actually be a fatal, because when I fix the problem, I get this:<br><br>

<br><div style="margin-left:40px">$ jj upgrade-charm --debug --repository ~/sw/charms custard-dev<br>2013-09-06 10:31:49 INFO juju.provider.ec2 ec2.go:187 opening environment "ec2"<br>2013-09-06 10:31:50 DEBUG juju state.go:158 waiting for DNS name(s) of state server instances [i-...]<br>

2013-09-06 10:31:56 INFO juju.state open.go:68 opening state; mongo addresses: ["..."]; entity ""<br>2013-09-06 10:31:57 INFO juju.state open.go:106 connection established<br>2013-09-06 10:31:58 WARNING juju dir.go:192 charm: making "/home/pwaller/sw/charms/raring/custard/hooks/queue-relation-changed" executable in charm<br>

2013-09-06 10:31:58 INFO juju conn.go:292 writing charm to storage [17698 bytes]<br>2013-09-06 10:32:00 INFO juju conn.go:304 adding charm to state<br>2013-09-06 10:32:02 INFO juju supercommand.go:284 command finished<br>

</div><br></div><div>In other words, my local charm repository was not being written to the remote storage, but the debug log gave the impression of a successful upgrade.<br><br></div><div>We've fixed our immediate problem by introducing a valid metadata.yaml, but it is distressing to think that juju has been giving the team an impression of successful deploys when it is actually broken.<br>

<br>All the best,<br><br>- Peter<br></div></div></div></div>