Merge lp://staging/~mattyw/juju-core/add-service-owner-to-status into lp://staging/~go-bot/juju-core/trunk

Reviewers: mp+207859_code.launchpad.net,

Message:
Please take a look.

Description:
Added service owner to the output of juju status

Only really useful to land when the juju id branches land.

The output of the api call to Status() (including the output of the juju
status command) now includes the owner of the service

The output looks like this:
services:
 ubuntu:
  charm: cs:precise/ubuntu-4
  exposed: false
   units:
    ubuntu/0:
    agent-state: pending
    machine: "1"
    owner-tag: user-admin

https://code.launchpad.net/~mattyw/juju-core/add-service-owner-to-status/+merge/207859

(do not edit description out of merge proposal)

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

Affected files (+109, -66 lines):
   A [revision details]
   M cmd/juju/status.go
   M cmd/juju/status_test.go
   M state/api/client.go
   M state/apiserver/client/api_test.go
   M state/statecmd/status.go
   M worker/peergrouper/desired.go

Looks good, but make sure you're familiar with Martin's recent 1.16
compatibility for status changes:
https://codereview.appspot.com/66590043/

You'll need to use the FullStatus API call.

https://codereview.appspot.com/67870043/

Please take a look.

https://codereview.appspot.com/67870043/

On 2014/02/25 10:15:52, dimitern wrote:
> Looks good, but make sure you're familiar with Martin's recent 1.16
> compatibility for status changes:
https://codereview.appspot.com/66590043/

> You'll need to use the FullStatus API call.

Sorry, so your changes are in statecmd, which gets called internally in
apiserver for both FullStatus and Status.
This means you don't need to care about FullStatus in your CL.
Your changes LGTM assuming you've tested them live as well, just in
case.

https://codereview.appspot.com/67870043/

On 2014/02/27 10:40:25, dimitern wrote:
> On 2014/02/25 10:15:52, dimitern wrote:
> > Looks good, but make sure you're familiar with Martin's recent 1.16
> > compatibility for status changes:
https://codereview.appspot.com/66590043/
> >
> > You'll need to use the FullStatus API call.

> Sorry, so your changes are in statecmd, which gets called internally
in
> apiserver for both FullStatus and Status.
> This means you don't need to care about FullStatus in your CL.
> Your changes LGTM assuming you've tested them live as well, just in
case.

I'm fairly strongly -1 on this, because status is bloated enough
already. Can we please start adding flags to status for additional
information?

https://codereview.appspot.com/67870043/

On 2014/02/27 13:45:51, fwereade wrote:
> On 2014/02/27 10:40:25, dimitern wrote:
> > On 2014/02/25 10:15:52, dimitern wrote:
> > > Looks good, but make sure you're familiar with Martin's recent
1.16
> > > compatibility for status changes:
https://codereview.appspot.com/66590043/
> > >
> > > You'll need to use the FullStatus API call.
> >
> > Sorry, so your changes are in statecmd, which gets called internally
in
> > apiserver for both FullStatus and Status.
> > This means you don't need to care about FullStatus in your CL.
> > Your changes LGTM assuming you've tested them live as well, just in
case.

> I'm fairly strongly -1 on this, because status is bloated enough
already. Can we
> please start adding flags to status for additional information?

And especially in status, adding the owner to every unit feels wrong. If
units ever get explicit owners we can add it then; for now, the service
feels like a much better place. So not lgtm without discussion, at
least.

https://codereview.appspot.com/67870043/

On 2014/02/27 13:47:33, fwereade wrote:
> On 2014/02/27 13:45:51, fwereade wrote:
> > On 2014/02/27 10:40:25, dimitern wrote:
> > > On 2014/02/25 10:15:52, dimitern wrote:
> > > > Looks good, but make sure you're familiar with Martin's recent
1.16
> > > > compatibility for status changes:
https://codereview.appspot.com/66590043/
> > > >
> > > > You'll need to use the FullStatus API call.
> > >
> > > Sorry, so your changes are in statecmd, which gets called
internally in
> > > apiserver for both FullStatus and Status.
> > > This means you don't need to care about FullStatus in your CL.
> > > Your changes LGTM assuming you've tested them live as well, just
in case.
> >
> > I'm fairly strongly -1 on this, because status is bloated enough
already. Can
> we
> > please start adding flags to status for additional information?

> And especially in status, adding the owner to every unit feels wrong.
If units
> ever get explicit owners we can add it then; for now, the service
feels like a
> much better place. So not lgtm without discussion, at least.

Fair enough - I was hoping to have discussion with you and roger about
this - the implementation here includes the owner as part of the service
though - not part of the unit

https://codereview.appspot.com/67870043/