deploy charm uses cached copy even when all services are removed

[David Britton]

Steps to reproduce:

1) deploy charm from local checkout
2) destroy-service
3) deploy charm from local checkout (with changes)

You will get a cached copy of the charm from 1)

This seems like the wrong thing to do, and I'm nearly certain it's new behavior in juju-core. I understand the need for cached charms for add-unit, etc, but why are we spanning the service boundary with these caches? It leads to a lot of WTH moments when you go to the service and find your new changes are not out there.

Is it a simple one to fix?

[Mark Ramm (mark-ramm)]

 I'm not sure that's even a bug. If we only update the environment cache when explicitly requested by the user -- you remain in control of what charm updates happen . But if we change it you are not in control, which is not awesome.

That said, I think it would be probably be easy enough to fix if that's the right thing to do, and I can see how the current behavior will trip people up because owing the cache invalidation logic for charms themselves, is not something that will ever be natural to new users.

And the logic seems complicated -- for the local charm development case it seems like it might be surprising for the charm not to update when you deploy a new instance of that service. But for non-developers and people using the charm store -- having the version in the environment update without any action on their part is likely to be equally surprising.

And of course the worst case scenario for surprising behavior is likely to be have different behaviors for local and charm store deployments.

[Mark Ramm (mark-ramm)]

After a bit of discussion, we came to the idea that if we just treat the cache as completely service-name based, and destroy-service destroys everything -- including that service name's cached charms -- the whole thing seems reasonable and unsurprising in all the cases we care about.

IMHO, if the unit count goes down to zero that would not have the same result. Only destroy-service would clear out the cache and along with all other info about the old service configuration.

[David Britton (dpb)]

Agreed -- removing all units and destroying service would behave
differently, that makes sense.

On Fri, Jul 26, 2013 at 1:58 PM, Mark Ramm <
<email address hidden>> wrote:

> After a bit of discussion, we came to the idea that if we just treat the
> cache as completely service-name based, and destroy-service destroys
> everything -- including that service name's cached charms -- the whole
> thing seems reasonable and unsurprising in all the cases we care about.
>
> IMHO, if the unit count goes down to zero that would not have the same
> result. Only destroy-service would clear out the cache and along with
> all other info about the old service configuration.
>
> ** Changed in: juju-core
> Importance: Undecided => Medium
>
> ** Changed in: juju-core
> Status: New => Triaged
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1205466
>
> Title:
> deploy charm uses cached copy even when all services are removed
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju-core/+bug/1205466/+subscriptions
>

--
David Britton <email address hidden>

[Gustavo Niemeyer (niemeyer)]

Please don't change that.

The system is acting correctly by caching the charm with the given URL and revision. If I destroy a service and re-create, and suddenly that service is different, although the charm URL and revision did not change, *that's* surprising and a bug.

In other words, do not use a single revision identifier for different content. That's wrong in Bazaar, in deb packaging, and it's wrong in juju as well. If you do it, bad things will happen.

Note that deploy has an --upgrade identifier precisely so you can easily bump the revision number on quick local iterations of a charm.

[Michael Nelson (michael.nelson)]

Marking invalid based on Gustavo's comment above.

As a side-note, another issue that came out was that we couldn't remove the charm from the cache on destroy-service, as you can deploy the same charm for multiple services.