Merge lp://staging/~makyo/juju-core/upgradecharm3-1171548 into lp://staging/~juju/juju-core/trunk

Reviewers: mp+167331_code.launchpad.net,

Message:
Please take a look.

Description:
Add UpgradeCharm to the API

This branch adds upgrade charm functionality to the API (branch 3/3 in
the process).

https://code.launchpad.net/~makyo/juju-core/upgradecharm3-1171548/+merge/167331

(do not edit description out of merge proposal)

Please review this at https://codereview.appspot.com/9975045/

Affected files:
   A [revision details]
   M state/api/client.go
   M state/api/params/params.go
   M state/apiserver/client.go
   M state/apiserver/perm_test.go
   A state/statecmd/upgradecharm.go
   A state/statecmd/upgradecharm_test.go

NOT LGTM until we've spoken -- but I might be convinced to go ahead with
this on the condition of followups we agree on live.

https://codereview.appspot.com/9975045/diff/1/state/apiserver/client.go
File state/apiserver/client.go (right):

https://codereview.appspot.com/9975045/diff/1/state/apiserver/client.go#newcode134
state/apiserver/client.go:134: // Set bumpRevision to false when working
with the CharmStore.
We cannot help but work with the charm store here. Looking back in time
a bit, it seems that we failed in reviewing ServiceDeploy: no blame
attaches for continuing along the "approved" path, ofc, but we can't go
on this way.

The issue is simply that there is no local repo on the API server. The
local repo is in practice a pretty broken concept regardless, but that's
by the by; the fundamental problem is that the client API for deploying
and upgrading charms does need to be able to use charms from local
repos. The only way to do this, AFAICT, is to implement a PutCharm(?)
API that causes a bundled charm on the client to be stored in the
environment and in state, and then to explicitly reference that charm in
subsequent deploy and upgrade ops.

I thought I'd kinda handed the details of this problem over to rogpeppe;
rog, do you have anything to add to this? What's the plan with charm
store charms here? It looks as though we're not getting necessarily
using revisioned charm URLs... not sure how this is sane.

https://codereview.appspot.com/9975045/diff/1/state/statecmd/upgradecharm.go
File state/statecmd/upgradecharm.go (right):

https://codereview.appspot.com/9975045/diff/1/state/statecmd/upgradecharm.go#newcode16
state/statecmd/upgradecharm.go:16: sch, err := conn.PutCharm(curl, repo,
bumpRevision)
I'm not sure this should happen on the server side at all; the CLI and
the GUI are each separately in a position to determine, and upload,
*exactly* the desired charm. The bumpRevision logic only makes sense in
the context of a local repo, and AFAIK nobody has yet implemented the
AddCharm(?) API method that's a prerequisite for use of local charms
over the API.

I can see the use case for something *like* this PutCharm method, that
just copies direct from the charm store into environment storage, but
that's more an AddCharm: PutCharm STM like it implies actually uploading
some bytes from the other end of the connection (and that's what it
actually does... right?).

https://codereview.appspot.com/9975045/

Reviewers: mp+167331_code.launchpad.net,

Message:
Please take a look.

Description:
Add UpgradeCharm to the API

This branch adds upgrade charm functionality to the API (branch 3/3 in
the process).

https://code.launchpad.net/~makyo/juju-core/upgradecharm3-1171548/+merge/167331

(do not edit description out of merge proposal)

Please review this at https://codereview.appspot.com/10237043/

Affected files:
   A [revision details]
   M state/api/client.go
   M state/api/params/params.go
   M state/apiserver/client.go
   M state/apiserver/client_test.go
   M state/apiserver/perm_test.go

Code looks great, but a couple of tests need to be rather more
unforgiving ;)

https://codereview.appspot.com/10237043/diff/1/state/apiserver/client_test.go
File state/apiserver/client_test.go (right):

https://codereview.appspot.com/10237043/diff/1/state/apiserver/client_test.go#newcode417
state/apiserver/client_test.go:417: mem4g :=
constraints.MustParse("mem=4G")
Drop the constraints, they're just a distraction here.

https://codereview.appspot.com/10237043/diff/1/state/apiserver/client_test.go#newcode425
state/apiserver/client_test.go:425: c.Assert(err, IsNil)
AFAICT this is just calling SetCharm with the existing charm in a
slightly obfuscated way. We really ought to actually change the charm,
and check that the change stuck.

https://codereview.appspot.com/10237043/diff/1/state/apiserver/client_test.go#newcode440
state/apiserver/client_test.go:440: c.Assert(err, IsNil)
Here it's fine to use the same charm, but you should still test that the
force flag was written.

https://codereview.appspot.com/10237043/diff/1/state/apiserver/client_test.go#newcode456
state/apiserver/client_test.go:456: s.setUpScenario(c)
do we need setUpScenario here? I can accept it's useful for permTest but
in general it's an awfully big fixture... better, I think, to just add a
wordpress service directly. Can't we just do:

s.State.AddService("wordpress", s.AddTestingCharm(c, "wordpress"))

?

https://codereview.appspot.com/10237043/

https://codereview.appspot.com/10237043/diff/1/state/apiserver/client_test.go
File state/apiserver/client_test.go (right):

https://codereview.appspot.com/10237043/diff/1/state/apiserver/client_test.go#newcode417
state/apiserver/client_test.go:417: mem4g :=
constraints.MustParse("mem=4G")
On 2013/06/13 08:01:08, fwereade wrote:
> Drop the constraints, they're just a distraction here.

Done.

https://codereview.appspot.com/10237043/diff/1/state/apiserver/client_test.go#newcode425
state/apiserver/client_test.go:425: c.Assert(err, IsNil)
On 2013/06/13 08:01:08, fwereade wrote:
> AFAICT this is just calling SetCharm with the existing charm in a
slightly
> obfuscated way. We really ought to actually change the charm, and
check that the
> change stuck.

Done.

https://codereview.appspot.com/10237043/diff/1/state/apiserver/client_test.go#newcode440
state/apiserver/client_test.go:440: c.Assert(err, IsNil)
On 2013/06/13 08:01:08, fwereade wrote:
> Here it's fine to use the same charm, but you should still test that
the force
> flag was written.

Done.

https://codereview.appspot.com/10237043/diff/1/state/apiserver/client_test.go#newcode456
state/apiserver/client_test.go:456: s.setUpScenario(c)
On 2013/06/13 08:01:08, fwereade wrote:
> do we need setUpScenario here? I can accept it's useful for permTest
but in
> general it's an awfully big fixture... better, I think, to just add a
wordpress
> service directly. Can't we just do:

> s.State.AddService("wordpress", s.AddTestingCharm(c, "wordpress"))

> ?

Ah, much cleaner. Done.

https://codereview.appspot.com/10237043/

Please take a look.

https://codereview.appspot.com/10237043/

LGTM, thanks!

https://codereview.appspot.com/10237043/

LGTM

https://codereview.appspot.com/10237043/

*** Submitted:

Add UpgradeCharm to the API

This branch adds upgrade charm functionality to the API (branch 3/3 in
the process).

R=fwereade, mue
CC=
https://codereview.appspot.com/10237043

https://codereview.appspot.com/10237043/