Added service owner to the output of juju status

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)

[mattyw, 2014-02-24 04:51:02]

Please take a look.

[dimitern, 2014-02-25 10:15:52]

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.

[mattyw, 2014-02-27 04:58:01]

Please take a look.

[dimitern, 2014-02-27 10:40:25]

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.

[fwereade, 2014-02-27 13:45:51]

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?

[fwereade, 2014-02-27 13:47:33]

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.

[mattyw, 2014-02-27 14:07:23]

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