juju destroy-environment does not delete the local charm cache

[John A Meinel]

I just ran:

sudo juju bootstrap -e local
juju deploy -e local ubuntu
sudo juju destroy-environment local
sudo juju bootstrap -e local
juju deploy -e local ubuntu

And the last command fails with:
2013-12-11 12:48:46 INFO juju.provider.local environprovider.go:35 opening environment "local"
2013-12-11 12:48:46 DEBUG juju state.go:75 waiting for DNS name(s) of state server instances [localhost]
2013-12-11 12:48:46 INFO juju.state open.go:67 opening state; mongo addresses: ["10.0.3.1:37017"]; entity ""
2013-12-11 12:48:46 INFO juju.state open.go:105 connection established
2013-12-11 12:48:50 INFO juju conn.go:299 writing charm to storage [1539 bytes]
2013-12-11 12:48:50 INFO juju conn.go:311 adding charm to state
2013-12-11 12:48:50 ERROR juju supercommand.go:282 cannot add service "ubuntu": service already exists

We just had this bug also reported on IRC where someone was testing their local charm, but they kept getting an existing revision and they had to use juju deploy --upgrade.

I'm pretty sure that for providers != local we always destroy the control bucket so we don't run into this problem.

[John A Meinel (jameinel)]

I might be wrong about the cause, but I am completely unable to deploy the 'ubuntu' service, as it keeps saying the service already exists. I've tried destroy-environment, and I've tried nuking /var/lib/juju* (while destroyed), and it still gives me the same error.

I'm trying "juju add-machine" before "juju deploy" this time, to see if that changes anything.

This actually appears to be a compatibility problem with 1.17 vs a 1.16.4 local environment. Because if I do /usr/bin/juju deploy -e local ubuntu it works, if I do $GOBIN/juju deploy -e local ubuntu it fails.
:(

[John A Meinel (jameinel)]

So I can no longer reproduce this bug. Probably because the agent is now responsible for downloading the charm. We can set this to won't fix or Fix Committed as we chose.

We should probably test that it is also fixed in the case of local: charms, as that was the original source of the bug. (I just reproduced it with cs: charms and figured it would be easier to test there.)

[Dimiter Naydenov (dimitern)]

Unable to reproduce on trunk anymore, it seems this was fixed as a side-effect of recent local provider changes, so I'm marking this as Fix Committed and dropping my proposed branch.

[William Reade (fwereade)]

Reported reproed at r2212 by noodles775 in #juju

[Michael Nelson (michael.nelson)]

On Thu, Jan 16, 2014 at 1:03 PM, William Reade
<email address hidden> wrote:
> Reported reproed at r2212 by noodles775 in #juju
>
> ** Changed in: juju-core
> Status: Fix Committed => Triaged

FWIW, I didn't think I was reproducing this issue. I was planning to
try to reproduce it, but wasn't able to get juju status to return
sensible info [1], which seems to be either a separate issue or
something related to my dev instance (still looking).

[1] http://paste.ubuntu.com/6762332/

[Michael Nelson (michael.nelson)]

Specifically, using 1.17.0 I'm not able to reproduce this bug http://paste.ubuntu.com/6762695/