can't upgrade a store-deployed service from a local repo

[Mark Mims]

Deployed a mysql service directly from the charm store.
{{{
  mysql:
    charm: cs:precise/mysql-5
    relations: {}
    units:
      mysql/0:
        agent-state: started
        machine: 14
        public-address: ec2-50-17-57-35.compute-1.amazonaws.com
}}}

A bug is found and I fix it locally

I try to upgrade that service using the charm from the local repo:

{{{
    hawk:~/projects/canonical/security-fixes $ juju upgrade-charm --repository . mysql
    2012-08-22 11:50:23,806 INFO Connecting to environment...
    2012-08-22 11:50:27,009 INFO Connected to environment.
    2012-08-22 11:50:27,974 ERROR Charm 'cs:precise/mysql-5' is the latest revision known
}}}

possibly related to bug #1040203

[Clint Byrum (clint-fewbar)]

This requires a 'switch-charm' command

[William Reade (fwereade)]

I'm wondering whether this is a whole new command, or just options to upgrade-charm:

$ juju upgrade-charm
$ juju upgrade-charm --revision 123
$ juju upgrade-charm --switch local:mysql

There's been talk of upgrading to specific revisions, which definitely fits well with upgrade-charm; this feels just like a slightly more extreme variant of the same operation. Opinions?

[William Reade (fwereade)]

(see also lp:1050750)

[Kapil Thangavelu (hazmat)]

On Fri, Oct 26, 2012 at 10:36 AM, William Reade
<email address hidden>wrote:

> I'm wondering whether this is a whole new command, or just options to
> upgrade-charm:
>
> $ juju upgrade-charm
> $ juju upgrade-charm --revision 123
> $ juju upgrade-charm --switch local:mysql
>
> There's been talk of upgrading to specific revisions, which definitely
> fits well with upgrade-charm; this feels just like a slightly more
> extreme variant of the same operation. Opinions?
>
>
both options seem pretty reasonable to me, with the caveat that its forward
rev movement for specific rev spec or switch unless forced ( the primary
use case for switch being fixing a store version).

-k

[Tim Penhey (thumper)]

Downgraded from critical to high as we aren't stopping other work to fix this.

[Dimiter Naydenov (dimitern)]

As decided, I'll implement a --switch argument to upgrade-charm, taking a charm URL and upgrading the service's charm to that (if possible).

[Stuart Bishop (stub)]

My use case for this is writing a test to confirm that upgrading a service deployed from the charm store to the version I'm proposing for the charm store actually works and does not eat data.