apiserver: UniterAPI initial implementation

apiserver: UniterAPI initial implementation

This introduces the first step towards a full
uniter API implementation. For now it's almost
exactly the same as the MachinerAPI, reusing the
common .Watch(), .EnsureDead(), .Life(), and
.SetStatus() calls.

Next, the client-side API using this will be
introduced.

https://code.launchpad.net/~dimitern/juju-core/091-api-uniter-first-step/+merge/179148

(do not edit description out of merge proposal)

[dimitern, 2013-08-08 10:19:46]

Please take a look.

[dimitern, 2013-08-08 10:23:30]

Please take a look.

[rog, 2013-08-08 10:33:13]

LGTM apart from the DRY thing which is perhaps a necessary corollary of our
current approach.

https://codereview.appspot.com/12658043/diff/4001/state/apiserver/uniter/unit...
File state/apiserver/uniter/uniter.go (right):

https://codereview.appspot.com/12658043/diff/4001/state/apiserver/uniter/unit...
state/apiserver/uniter/uniter.go:30: return func(tag string) bool {
return authorizer.AuthOwner, nil

https://codereview.appspot.com/12658043/diff/4001/state/apiserver/uniter/unit...
File state/apiserver/uniter/uniter_test.go (right):

https://codereview.appspot.com/12658043/diff/4001/state/apiserver/uniter/unit...
state/apiserver/uniter/uniter_test.go:97: func (s *uniterSuite) TestSetStatus(c
*gc.C) {
Seeing all these tests testing essentially the same
logic duplicated so many times (once
in StatusSetter, once here, and once, presumably,
in the client-side code) makes me sad.

[thumper, 2013-08-08 10:52:57]

LGTM although I'd like y'all to consider the interfaces idea, and I'd really
like to see the test member names to be meaningful.

https://codereview.appspot.com/12658043/diff/4001/state/apiserver/uniter/unit...
File state/apiserver/uniter/uniter.go (right):

https://codereview.appspot.com/12658043/diff/4001/state/apiserver/uniter/unit...
state/apiserver/uniter/uniter.go:25: func NewUniterAPI(st *state.State,
resources *common.Resources, authorizer common.Authorizer) (*UniterAPI, error) {
I really don't like that we return pointers to structures.

I think that we should be returning interfaces.

https://codereview.appspot.com/12658043/diff/4001/state/apiserver/uniter/unit...
File state/apiserver/uniter/uniter_test.go (right):

https://codereview.appspot.com/12658043/diff/4001/state/apiserver/uniter/unit...
state/apiserver/uniter/uniter_test.go:52: s.service0, err =
s.State.AddService("wordpress", s.AddTestingCharm(c, "wordpress"))
can we please name this wordpressService, etc.

unit0 -> wordpressUnit
unit1 -> mysqlUnit

Reading the tests down below had me wondering, which one is this?
Using reasonable names makes it obvious.

[dimitern, 2013-08-08 10:59:28]

Please take a look.

https://codereview.appspot.com/12658043/diff/4001/state/apiserver/uniter/unit...
File state/apiserver/uniter/uniter.go (right):

https://codereview.appspot.com/12658043/diff/4001/state/apiserver/uniter/unit...
state/apiserver/uniter/uniter.go:25: func NewUniterAPI(st *state.State,
resources *common.Resources, authorizer common.Authorizer) (*UniterAPI, error) {
On 2013/08/08 10:52:57, thumper wrote:
> I really don't like that we return pointers to structures.
> 
> I think that we should be returning interfaces.

Noted, we should discuss this at some point perhaps.

https://codereview.appspot.com/12658043/diff/4001/state/apiserver/uniter/unit...
state/apiserver/uniter/uniter.go:30: return func(tag string) bool {
On 2013/08/08 10:33:13, rog wrote:
> return authorizer.AuthOwner, nil

Done. Also fixed the one in MachinerAPI.

https://codereview.appspot.com/12658043/diff/4001/state/apiserver/uniter/unit...
File state/apiserver/uniter/uniter_test.go (right):

https://codereview.appspot.com/12658043/diff/4001/state/apiserver/uniter/unit...
state/apiserver/uniter/uniter_test.go:52: s.service0, err =
s.State.AddService("wordpress", s.AddTestingCharm(c, "wordpress"))
On 2013/08/08 10:52:57, thumper wrote:
> can we please name this wordpressService, etc.
> 
> unit0 -> wordpressUnit
> unit1 -> mysqlUnit
> 
> Reading the tests down below had me wondering, which one is this?
> Using reasonable names makes it obvious.

Done.

https://codereview.appspot.com/12658043/diff/4001/state/apiserver/uniter/unit...
state/apiserver/uniter/uniter_test.go:97: func (s *uniterSuite) TestSetStatus(c
*gc.C) {
On 2013/08/08 10:33:13, rog wrote:
> Seeing all these tests testing essentially the same
> logic duplicated so many times (once
> in StatusSetter, once here, and once, presumably,
> in the client-side code) makes me sad.

Some of the logic is duplicated (setup/teardown/asserts), but the tests are
different, strictly speaking - they're testing different aspects of the code.