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

Bug #1040210 reported by Mark Mims on 2012-08-22
28
This bug affects 6 people
Affects Status Importance Assigned to Milestone
juju-core
High
Dimiter Naydenov
pyjuju
Wishlist
Unassigned

Bug Description

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

Related branches

Mark Mims (mark-mims) on 2012-08-22
description: updated
Clint Byrum (clint-fewbar) wrote :

This requires a 'switch-charm' command

Changed in juju:
status: New → Confirmed
importance: Undecided → Critical
milestone: none → 0.7
Changed in juju-core:
status: New → Confirmed
importance: Undecided → Critical
William Reade (fwereade) 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?

William Reade (fwereade) wrote :

(see also lp:1050750)

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

Changed in juju-core:
milestone: none → 2.0
Changed in juju-core:
milestone: 2.0 → none
tags: added: upgrade-charm
Changed in juju:
milestone: 0.7 → 0.8
Tim Penhey (thumper) wrote :

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

Changed in juju-core:
status: Confirmed → Triaged
importance: Critical → High
Dimiter Naydenov (dimitern) wrote :

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).

Changed in juju-core:
status: Triaged → In Progress
assignee: nobody → Dimiter Naydenov (dimitern)
milestone: none → 1.10.1
Changed in juju-core:
status: In Progress → Fix Committed
Stuart Bishop (stub) wrote :

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.

Nick Veitch (evilnick) on 2013-06-12
tags: added: doc
Mark Ramm (mark-ramm) on 2013-09-17
Changed in juju-core:
status: Fix Committed → Fix Released
Mark Ramm (mark-ramm) on 2013-09-17
Changed in juju-core:
milestone: 1.10.1 → 1.11.0
Mark Ramm (mark-ramm) on 2013-09-17
Changed in juju:
importance: Critical → Wishlist
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers