Merge lp://staging/~dimitern/juju-core/038-upgrade-charm-switch into lp://staging/~juju/juju-core/trunk
- 038-upgrade-charm-switch
- Merge into trunk
Status: | Merged | ||||||||
---|---|---|---|---|---|---|---|---|---|
Merged at revision: | 1201 | ||||||||
Proposed branch: | lp://staging/~dimitern/juju-core/038-upgrade-charm-switch | ||||||||
Merge into: | lp://staging/~juju/juju-core/trunk | ||||||||
Diff against target: |
332 lines (+180/-37) 3 files modified
cmd/juju/upgradecharm.go (+88/-29) cmd/juju/upgradecharm_test.go (+83/-8) testing/charm.go (+9/-0) |
||||||||
To merge this branch: | bzr merge lp://staging/~dimitern/juju-core/038-upgrade-charm-switch | ||||||||
Related bugs: |
|
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Juju Engineering | Pending | ||
Review via email: mp+160910@code.staging.launchpad.net |
Commit message
Description of the change
cmd/juju: upgrade-charm --switch support
This implements a new argument to upgrade-charm:
--switch <charm-url>. The passed URL is inferred
to get the complete URL and used instead of the
service's newest charm url revision.
Also --revision is now supported, to give an
explicit revision to upgrade to, rather than the
latest.
There are a few related sanity checks that need
to be implemented as well (in follow-ups), so we
can better check charm compatibility before upgrading.
Fixes bugs #1040210 and #1050750.
Dimiter Naydenov (dimitern) wrote : | # |
Roger Peppe (rogpeppe) wrote : | # |
good direction, but does not LGTM quite yet - some logic i don't think
is quite right, as outlined below.
https:/
File cmd/juju/
https:/
cmd/juju/
compatible with the current one.
Perhaps say what "compatible" means in this context in a concise and
easy to understand way (no need to go into all the details, but an
overview would be good so the user knows what they're up against)
https:/
cmd/juju/
i think this is wrong in the context of SwitchURL.
i think the Latest and bump-revision logic should only be triggered when
the charm url does not have a revision number specified.
https:/
File cmd/juju/
https:/
cmd/juju/
myriakPath)
also test switching from one cs: charm to another?
and with a revision number explicitly specified.
https:/
File testing/charm.go (right):
https:/
testing/
os.Rename(newDst, renamedDst) ?
William Reade (fwereade) wrote : | # |
a few thoughts
https:/
File cmd/juju/
https:/
cmd/juju/
--switch and --revision.
I don't see an implementation of --revision, and I think it'd be quite
easy to sneak it into this CL ;)
(consider that --switch and --revision could in theory conflict, so it
might be good to barf here if they're both set)
https:/
File cmd/juju/
https:/
cmd/juju/
compatible with the current one.
On 2013/04/25 14:43:52, rog wrote:
> Perhaps say what "compatible" means in this context in a concise and
easy to
> understand way (no need to go into all the details, but an overview
would be
> good so the user knows what they're up against)
and underscore that it's dangerous -- we can only check so much
compatibility :)
https:/
cmd/juju/
wrt rog's comment below, curl = curl.WithRevisi
https:/
cmd/juju/
On 2013/04/25 14:43:52, rog wrote:
> i think this is wrong in the context of SwitchURL.
> i think the Latest and bump-revision logic should only be triggered
when the
> charm url does not have a revision number specified.
+1
https:/
File cmd/juju/
https:/
cmd/juju/
assertUpgraded(c *C, revision int, forced bool, curl *charm.URL) {
I'd rather return the charm url and assert it in the places it's needed,
I think
https:/
cmd/juju/
myriakPath)
On 2013/04/25 14:43:52, rog wrote:
> also test switching from one cs: charm to another?
> and with a revision number explicitly specified.
We have thus far gone with the shared agreement that if it works with
one repo (local), we can expect it to work with the other. Hmm, can we
now fake out the charm store? I think we can. If so, definite +1 on
testing this in a wider range of scenarios.
https:/
File testing/charm.go (right):
https:/
testing/
On 2013/04/25 14:43:52, rog wrote:
> os.Rename(newDst, renamedDst) ?
+1
Dimiter Naydenov (dimitern) wrote : | # |
Nothing changed yet, I just need to make sure I get the suggestions
first.
https:/
File cmd/juju/
https:/
cmd/juju/
--switch and --revision.
On 2013/04/25 15:09:06, fwereade wrote:
> I don't see an implementation of --revision, and I think it'd be quite
easy to
> sneak it into this CL ;)
> (consider that --switch and --revision could in theory conflict, so it
might be
> good to barf here if they're both set)
So --revision is an int and forces the revision as specified, but only
when --switch is not present, otherwise - barf?
https:/
File cmd/juju/
https:/
cmd/juju/
compatible with the current one.
On 2013/04/25 15:09:06, fwereade wrote:
> On 2013/04/25 14:43:52, rog wrote:
> > Perhaps say what "compatible" means in this context in a concise and
easy to
> > understand way (no need to go into all the details, but an overview
would be
> > good so the user knows what they're up against)
> and underscore that it's dangerous -- we can only check so much
compatibility :)
I'd appreciate suggestions with actual text, since probably both of you
can devise a better sentence than me :)
https:/
cmd/juju/
On 2013/04/25 15:09:06, fwereade wrote:
> wrt rog's comment below, curl = curl.WithRevisi
When --switch is given, the revision shouldn't be bumped, and the code
below does not apply, right?
https:/
cmd/juju/
On 2013/04/25 15:09:06, fwereade wrote:
> On 2013/04/25 14:43:52, rog wrote:
> > i think this is wrong in the context of SwitchURL.
> >
> > i think the Latest and bump-revision logic should only be triggered
when the
> > charm url does not have a revision number specified.
> +1
See the question above.
https:/
File cmd/juju/
https:/
cmd/juju/
assertUpgraded(c *C, revision int, forced bool, curl *charm.URL) {
On 2013/04/25 15:09:06, fwereade wrote:
> I'd rather return the charm url and assert it in the places it's
needed, I think
Good point, will do.
https:/
cmd/juju/
assertLocalRevi
On 2013/04/25 14:40:06, TheMue wrote:
> Maybe I'm only blind or it is planned for later, but where are you
using this
> method with a different path than s.path?
Only in the last t...
William Reade (fwereade) wrote : | # |
https:/
File cmd/juju/
https:/
cmd/juju/
--switch and --revision.
On 2013/04/25 15:29:01, dimitern wrote:
> On 2013/04/25 15:09:06, fwereade wrote:
> > I don't see an implementation of --revision, and I think it'd be
quite easy to
> > sneak it into this CL ;)
> >
> > (consider that --switch and --revision could in theory conflict, so
it might
> be
> > good to barf here if they're both set)
> So --revision is an int and forces the revision as specified, but only
when
> --switch is not present, otherwise - barf?
Yeah, I think that's sane.
https:/
File cmd/juju/
https:/
cmd/juju/
On 2013/04/25 15:29:01, dimitern wrote:
> On 2013/04/25 15:09:06, fwereade wrote:
> > wrt rog's comment below, curl = curl.WithRevisi
> When --switch is given, the revision shouldn't be bumped, and the code
below
> does not apply, right?
Hmm.I suspect that bump-revision logic *should* apply when --switch is
given with a *local* charm url *without* an explicit revision. Sane?
https:/
cmd/juju/
On 2013/04/25 15:29:01, dimitern wrote:
> See the question above.
So I think it's:
rev := curl.Revision
if rev == -1 {
latest, err := repo.Latest(curl)
if err != nil {
return err
}
rev = latest
}
https:/
File cmd/juju/
https:/
cmd/juju/
myriakPath)
On 2013/04/25 15:29:01, dimitern wrote:
> On 2013/04/25 15:09:06, fwereade wrote:
> > On 2013/04/25 14:43:52, rog wrote:
> > > also test switching from one cs: charm to another?
> > > and with a revision number explicitly specified.
> >
> > We have thus far gone with the shared agreement that if it works
with one repo
> > (local), we can expect it to work with the other. Hmm, can we now
fake out the
> > charm store? I think we can. If so, definite +1 on testing this in a
wider
> range
> > of scenarios.
> Sorry, I have no clue how to test this - ideas?
I'd be fine with setting charm.Store to some other repo and checking
that it talks properly to what it *thinks* is the store
Dimiter Naydenov (dimitern) wrote : | # |
Please take a look.
https:/
File cmd/juju/
https:/
cmd/juju/
compatible with the current one.
On 2013/04/25 15:29:01, dimitern wrote:
> On 2013/04/25 15:09:06, fwereade wrote:
> > On 2013/04/25 14:43:52, rog wrote:
> > > Perhaps say what "compatible" means in this context in a concise
and easy to
> > > understand way (no need to go into all the details, but an
overview would be
> > > good so the user knows what they're up against)
> >
> > and underscore that it's dangerous -- we can only check so much
compatibility
> :)
> I'd appreciate suggestions with actual text, since probably both of
you can
> devise a better sentence than me :)
Please check the new wording.
https:/
cmd/juju/
On 2013/04/25 15:43:30, fwereade wrote:
> On 2013/04/25 15:29:01, dimitern wrote:
> > On 2013/04/25 15:09:06, fwereade wrote:
> > > wrt rog's comment below, curl = curl.WithRevisi
> >
> > When --switch is given, the revision shouldn't be bumped, and the
code below
> > does not apply, right?
> Hmm.I suspect that bump-revision logic *should* apply when --switch is
given
> with a *local* charm url *without* an explicit revision. Sane?
Done.
https:/
cmd/juju/
On 2013/04/25 15:43:30, fwereade wrote:
> On 2013/04/25 15:29:01, dimitern wrote:
> > See the question above.
> So I think it's:
> rev := curl.Revision
> if rev == -1 {
> latest, err := repo.Latest(curl)
> if err != nil {
> return err
> }
> rev = latest
> }
Done.
https:/
File cmd/juju/
https:/
cmd/juju/
myriakPath)
On 2013/04/25 15:43:30, fwereade wrote:
> On 2013/04/25 15:29:01, dimitern wrote:
> > On 2013/04/25 15:09:06, fwereade wrote:
> > > On 2013/04/25 14:43:52, rog wrote:
> > > > also test switching from one cs: charm to another?
> > > > and with a revision number explicitly specified.
> > >
> > > We have thus far gone with the shared agreement that if it works
with one
> repo
> > > (local), we can expect it to work with the other. Hmm, can we now
fake out
> the
> > > charm store? I think we can. If so, definite +1 on testing this in
a wider
> > range
> > > of scenarios.
> >
> > Sorry, I have no clue how to test this - ideas?
> I'd be fine with setting charm.Store to some other repo and checking
that it
> talks properly to what it *thinks* is the store
Not sure how to do that either - it seems I have to spin up a whole http
server for that. If that's what it takes, ok, but it seems an overkill.
Roger Peppe (rogpeppe) wrote : | # |
still not quite there i'm afraid.
https:/
File cmd/juju/
https:/
cmd/juju/
probably worth reflowing all this text.
https:/
cmd/juju/
This cannot be combined with --switch.
perhaps add:
To specify a given revision number with --switch, give
it in the charm URL, for instance cs:wordpress-5
would specify revision number 5 of the wordpress charm.
?
https:/
cmd/juju/
i think this still isn't quite right.
if someone specifies a revision number in the charm url, this means we
then discard it and use the latest revision anyway.
i think fwereade's earlier suggestion is sound ("bump-revision logic
should apply when --switch is given
with a local charm url without an explicit revision")
AFAICS this code doesn't implement that logic.
https:/
cmd/juju/
i think that's self evident from the condition on the if statement.
Dimiter Naydenov (dimitern) wrote : | # |
Please take a look.
https:/
File cmd/juju/
https:/
cmd/juju/
On 2013/04/26 15:06:33, rog wrote:
> probably worth reflowing all this text.
Done.
https:/
cmd/juju/
This cannot be combined with --switch.
On 2013/04/26 15:06:33, rog wrote:
> perhaps add:
> To specify a given revision number with --switch, give
> it in the charm URL, for instance cs:wordpress-5
> would specify revision number 5 of the wordpress charm.
> ?
Done.
https:/
cmd/juju/
On 2013/04/26 15:06:33, rog wrote:
> i think that's self evident from the condition on the if statement.
Removed.
Dimiter Naydenov (dimitern) wrote : | # |
Sorry, forgot to reply to these - all done.
https:/
File cmd/juju/
https:/
cmd/juju/
On 2013/04/26 15:06:33, rog wrote:
> i think this still isn't quite right.
> if someone specifies a revision number in the charm url, this means we
then
> discard it and use the latest revision anyway.
> i think fwereade's earlier suggestion is sound ("bump-revision logic
should
> apply when --switch is given
> with a local charm url without an explicit revision")
> AFAICS this code doesn't implement that logic.
Done.
Dimiter Naydenov (dimitern) wrote : | # |
Please take a look.
Dimiter Naydenov (dimitern) wrote : | # |
Please take a look.
William Reade (fwereade) wrote : | # |
https:/
File cmd/juju/
https:/
cmd/juju/
if c.SwitchURL != "" && c.Revision != -1 {
return fmt.Errorf(
}
...or something
https:/
cmd/juju/
charm %q", curl)
Hmm. If the --force flag is set to something different to before, we
might actually want to allow this case (and other error below)?.
Pre-existing bug, doesn't have to be addressed in this CL, but if it
isn't it should be recorded.
https:/
File cmd/juju/
https:/
cmd/juju/
and --revision together")
This can and should be detected at Init() time.
https:/
cmd/juju/
Not needed (but read the next comment before addressing it).
https:/
cmd/juju/
I think this can all be simpler.
oldURL, _ := service.CharmURL()
var newURL *charm.URL
if c.SwitchURL != "" {
// A new charm URL was explicitly specified.
conf, err := conn.State.
if err != nil {
return err
}
newURL, err = charm.InferURL(
if err != nil {
return err
}
} else {
// No new URL was specified, but a revision might have been.
newURL = oldURL.
}
repo, err := charm.InferRepo
if err != nil {
return err
}
// If no revision was explicitly specified by either Revision or
// SwitchURL, discover the latest from the repo.
if newURL.Revision == -1 {
latest, err := repo.Latest(newURL)
if err != nil {
return err
}
newURL = newURL.
}
if *newURL == *oldURL {
if _, isLocal := repo.(*
// etc
Dimiter Naydenov (dimitern) wrote : | # |
Please take a look.
https:/
File cmd/juju/
https:/
cmd/juju/
On 2013/04/28 10:41:25, fwereade wrote:
> if c.SwitchURL != "" && c.Revision != -1 {
> return fmt.Errorf(
exclusive")
> }
> ...or something
Done.
https:/
cmd/juju/
charm %q", curl)
On 2013/04/28 10:41:25, fwereade wrote:
> Hmm. If the --force flag is set to something different to before, we
might
> actually want to allow this case (and other error below)?.
Pre-existing bug,
> doesn't have to be addressed in this CL, but if it isn't it should be
recorded.
I added a TODO
https:/
File cmd/juju/
https:/
cmd/juju/
and --revision together")
On 2013/04/28 10:41:25, fwereade wrote:
> This can and should be detected at Init() time.
Done.
https:/
cmd/juju/
On 2013/04/28 10:41:25, fwereade wrote:
> Not needed (but read the next comment before addressing it).
See the answer below.
https:/
cmd/juju/
On 2013/04/28 10:41:25, fwereade wrote:
> I think this can all be simpler.
> oldURL, _ := service.CharmURL()
> var newURL *charm.URL
> if c.SwitchURL != "" {
> // A new charm URL was explicitly specified.
> conf, err := conn.State.
> if err != nil {
> return err
> }
> newURL, err = charm.InferURL(
> if err != nil {
> return err
> }
> } else {
> // No new URL was specified, but a revision might have been.
> newURL = oldURL.
> }
> repo, err := charm.InferRepo
> if err != nil {
> return err
> }
> // If no revision was explicitly specified by either Revision or
> // SwitchURL, discover the latest from the repo.
> if newURL.Revision == -1 {
> latest, err := repo.Latest(newURL)
> if err != nil {
> return err
> }
> newURL = newURL.
> }
> if *newURL == *oldURL {
> if _, isLocal := repo.(*
> // etc
I prefer to keep it as is, if you don't mind, and I don't think it's any
more clear the suggested way.
Does it fulfill the required set of cases? I think so.
William Reade (fwereade) wrote : | # |
I'm on the fence a little; let's have a chat about how bad the
revision-bumping situation is, it might be that the benefits of your
implementation will win out.
https:/
File cmd/juju/
https:/
cmd/juju/
charm %q", curl)
On 2013/04/29 09:53:21, dimitern wrote:
> On 2013/04/28 10:41:25, fwereade wrote:
> > Hmm. If the --force flag is set to something different to before, we
might
> > actually want to allow this case (and other error below)?.
Pre-existing bug,
> > doesn't have to be addressed in this CL, but if it isn't it should
be
> recorded.
> I added a TODO
A bug would be great too please.
https:/
File cmd/juju/
https:/
cmd/juju/
An explicit revision can be chosen with the --revision flag.
https:/
cmd/juju/
configuration settings.
How about:
The --switch flag allows you to replace the charm with an entirely
different one. The new charm's URL and revision are inferred as they
would be when running a deploy command.
Please note that --switch is dangerous, because juju only has limited
information with which to determine compatibility; the operation will
succeed, regardless of potential havoc, so long as the following
conditions hold:
- The new charm must declare all relations that the service is currently
participating in.
- All config settings shared by the old and new charms must have the
same types.
--switch and --revision are mutually exclusive.
https:/
cmd/juju/
charm.
Drop this para, --revision is best described at the top, I think; we
just need to mention it won't work with switch.
https:/
cmd/juju/
"charm URL to upgrade to")
"crossgrade to a different charm" ?
https:/
cmd/juju/
"revision number to upgrade to")
"explicit revision of current charm" ?
https:/
cmd/juju/
On 2013/04/29 09:53:21, dimitern wrote:
> On 2013/04/28 10:41:25, fwereade wrote:
> > I think this can all be simpler.
> >
> > oldURL, _ := service.CharmURL()
> > var newURL *charm.URL
> > if c.SwitchURL != "" {
> > // A new charm URL was explicitly specified.
> > conf, err := conn.State.
> > if err != nil {
> > return err
> > }
> > ...
Dimiter Naydenov (dimitern) wrote : | # |
Please take a look.
https:/
File cmd/juju/
https:/
cmd/juju/
charm %q", curl)
On 2013/04/29 10:45:26, fwereade wrote:
> On 2013/04/29 09:53:21, dimitern wrote:
> > On 2013/04/28 10:41:25, fwereade wrote:
> > > Hmm. If the --force flag is set to something different to before,
we might
> > > actually want to allow this case (and other error below)?.
Pre-existing bug,
> > > doesn't have to be addressed in this CL, but if it isn't it should
be
> > recorded.
> >
> > I added a TODO
> A bug would be great too please.
Done.
https:/
File cmd/juju/
https:/
cmd/juju/
On 2013/04/29 10:45:26, fwereade wrote:
> An explicit revision can be chosen with the --revision flag.
Done.
https:/
cmd/juju/
configuration settings.
On 2013/04/29 10:45:26, fwereade wrote:
> How about:
> The --switch flag allows you to replace the charm with an entirely
different
> one. The new charm's URL and revision are inferred as they would be
when running
> a deploy command.
> Please note that --switch is dangerous, because juju only has limited
> information with which to determine compatibility; the operation will
succeed,
> regardless of potential havoc, so long as the following conditions
hold:
> - The new charm must declare all relations that the service is
currently
> participating in.
> - All config settings shared by the old and new charms must have the
same types.
> --switch and --revision are mutually exclusive.
Done.
https:/
cmd/juju/
charm.
On 2013/04/29 10:45:26, fwereade wrote:
> Drop this para, --revision is best described at the top, I think; we
just need
> to mention it won't work with switch.
I changed the wording to better describe both.
https:/
cmd/juju/
"charm URL to upgrade to")
On 2013/04/29 10:45:26, fwereade wrote:
> "crossgrade to a different charm" ?
ewww.. ok :)
https:/
cmd/juju/
"revision number to upgrade to")
On 2013/04/29 10:45:26, fwereade wrote:
> "explicit revision of current charm" ?
Done.
https:/
cmd/juju/
On 2013/04/29 10:45:26, fwereade wrote:
> On 2013/04/29 09:53:21, dimitern wrote:
> > On 2013/04/28 10:41:25, fwereade wrote:
> > > I th...
William Reade (fwereade) wrote : | # |
nearly there, last round I think
https:/
File cmd/juju/
https:/
cmd/juju/
ch.(*charm.Dir); !bumpRevision {
...here -- in which case we should only set bumpRevision if
explicitRevision is false.
https:/
File cmd/juju/
https:/
cmd/juju/
configuration settings.
I think we can drop this line.
https:/
cmd/juju/
{
If newURL matches oldURL, we have to take this branch. We don't need to
worry about explicitRevision until...
https:/
cmd/juju/
bumpRevision)
It's somewhat crazy that we can specify a URL with an additional param
that means "lol not really". But that's way out of scope.
Roger Peppe (rogpeppe) wrote : | # |
really close. just one final piece of logic to get right, i think.
https:/
File cmd/juju/
https:/
cmd/juju/
"charm URL to upgrade to")
On 2013/04/29 12:05:56, dimitern wrote:
> On 2013/04/29 10:45:26, fwereade wrote:
> > "crossgrade to a different charm" ?
> ewww.. ok :)
crossgrade??
how about just "change" ?
https:/
File cmd/juju/
https:/
cmd/juju/
new charms must have the
that's not quite right, is it? i believe the new charm must declare all
the settings declared by the old, whereas this seems to imply that only
the intersection of old and new matters.
but maybe we the error message will be suitably self-explanatory if this
happens.
https:/
cmd/juju/
{
as discussed online, i'm not sure this is quite right yet.
[16:53:37] <rogpeppe> fwereade: but the case i'm thinking of is
something like this:
[16:54:14] <rogpeppe> fwereade: we have a local copy of a charm, deploy
it, push it to the charm store, switch to that, then make some changes
to the local copy and switch back to that
[16:54:48] <rogpeppe> fwereade: in that case, we want the version to be
bumped, but the urls are different
Dimiter Naydenov (dimitern) wrote : | # |
Please take a look.
William Reade (fwereade) wrote : | # |
LGTM with suggestions
https:/
File cmd/juju/
https:/
cmd/juju/
ch.(*charm.Dir); !bumpRevision {
We could just not bother checking this, and always setting bumpRevision
in local repos -- I don't think many people are putting bundles in local
repos anyway, and the error message from PutCharm should be clear enough
to anyone who is.
https:/
File cmd/juju/
https:/
cmd/juju/
bug #1174287
Move this comment up to the top case.
Dimiter Naydenov (dimitern) wrote : | # |
*** Submitted:
cmd/juju: upgrade-charm --switch support
This implements a new argument to upgrade-charm:
--switch <charm-url>. The passed URL is inferred
to get the complete URL and used instead of the
service's newest charm url revision.
Also --revision is now supported, to give an
explicit revision to upgrade to, rather than the
latest.
There are a few related sanity checks that need
to be implemented as well (in follow-ups), so we
can better check charm compatibility before upgrading.
Fixes bugs #1040210 and #1050750.
R=TheMue, rog, fwereade
CC=
https:/
Reviewers: mp+160910_ code.launchpad. net,
Message:
Please take a look.
Description:
cmd/juju: upgrade-charm --switch support
This implements a new argument to upgrade-charm:
--switch <charm-url>. The passed URL is inferred
to get the complete URL and used instead of the
service's newest charm url revision.
There are a few related sanity checks that need
to be implemented as well (in follow-ups), so we
can better check charm compatibility before upgrading.
Fixes bug #1040203.
https:/ /code.launchpad .net/~dimitern/ juju-core/ 038-upgrade- charm-switch/ +merge/ 160910
(do not edit description out of merge proposal)
Please review this at https:/ /codereview. appspot. com/8540050/
Affected files: upgradecharm. go upgradecharm_ test.go
A [revision details]
M cmd/juju/
M cmd/juju/
M testing/charm.go
Index: [revision details]
=== added file '[revision details]'
--- [revision details] 2012-01-01 00:00:00 +0000
+++ [revision details] 2012-01-01 00:00:00 +0000
@@ -0,0 +1,2 @@
+Old revision:
<email address hidden>
+New revision:
<email address hidden>
Index: testing/charm.go
=== modified file 'testing/charm.go'
--- testing/charm.go 2013-02-11 05:54:45 +0000
+++ testing/charm.go 2013-04-25 14:27:20 +0000
@@ -54,6 +54,15 @@
return clone(dst, r.DirPath(name))
}
+// RenamedClonedDi rPath returns the path to a new copy of the default rPath(dst, name, newName string) string { Join(filepath. Dir(newDst) , newName) Command( "mv", newDst, renamedDst).Run())
+// charm directory named name, but renames it to newName.
+func (r *Repo) RenamedClonedDi
+ newDst := clone(dst, r.DirPath(name))
+ renamedDst := filepath.
+ check(exec.
+ return renamedDst
+}
+
// ClonedDir returns an actual charm.Dir based on a new copy of the charm
directory
// named name, in the directory dst.
func (r *Repo) ClonedDir(dst, name string) *charm.Dir {
Index: cmd/juju/ upgradecharm. go upgradecharm. go' upgradecharm. go 2013-04-25 10:46:51 +0000 upgradecharm. go 2013-04-25 14:27:20 +0000
=== modified file 'cmd/juju/
--- cmd/juju/
+++ cmd/juju/
@@ -17,6 +17,7 @@
ServiceName string
Force bool
RepoPath string // defaults to JUJU_REPOSITORY
+ SwitchURL string
}
const upgradeCharmDoc = `
@@ -32,6 +33,10 @@
author working on a single client machine; use of local repositories from
multiple clients is not supported and may lead to confusing behaviour.
+To manually specify the charm URL to upgrade to, use the --switch argument. Base.SetFlags( f) &c.Force, "force", false, "upgrade all units immediately, even &c.RepoPath, "repository", "JUJU_REPOSITOR Y"), "local charm repository path") &c.SwitchURL, "switch", "", "charm URL to upgrade to")
+It will be used instead of the service's current charm newest revision.
+Note that the given charm must be compatible with the current one.
+
Use of the --force flag is not generally recommended; units upgraded while
in
an error state will not have upgrade-charm hooks executed, and may cause
unexpected behavior.
@@ -50,6 +55,7 @@
c.EnvCommand
f.BoolVar(
if in error state")
f.StringVar(
os.Getenv(
+ f.StringVar(
}
func (c *Up...