cmd/juju; state/api: Networks in service status

cmd/juju; state/api: Networks in service status

Status command updated to show enabled/disabled
networks for each service (if set). These are
networks that we expect to be enabled or disabled
on each new machine that hosts units of that service.

What actual networks were set up on a machine is
a different matter (as constraints vs. hardware
characteristics - i.e. declaration of intent vs.
actual reality). They will be also listed in status,
but at a later stage.

https://code.launchpad.net/~dimitern/juju-core/361-machine-networks-in-status/+merge/212465

Requires: https://code.launchpad.net/~dimitern/juju-core/360-state-machine-networks/+merge/212418

(do not edit description out of merge proposal)

[dimitern, 2014-03-24 15:41:52]

Please take a look.

[gz, 2014-03-24 16:30:31]

LGTM with a naming quibble, if this is what we want.

I'm a bit concerned that this is not really the network information we want at
the machine level. What the use likely cares about is *really* what networks a
machine is on, not which the provisioner was told to include and exclude it
from, even though include should == reality.

At the service level, this seems like more useful status output, and less
spammy.

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

https://codereview.appspot.com/76400049/diff/1/state/api/client.go#newcode32
state/api/client.go:32: Disabled []string
Is this enabled/disabled rather than included/excluded for a reason?

[fwereade, 2014-03-26 10:16:10]

On 2014/03/24 16:30:31, gz wrote:
> LGTM with a naming quibble, if this is what we want.

NOT LGTM, this is not what we want. I chatted live with dimitern yesterday but
didn't record it here.

> I'm a bit concerned that this is not really the network information we want at
> the machine level. What the use likely cares about is *really* what networks a
> machine is on, not which the provisioner was told to include and exclude it
> from, even though include should == reality.

Exactly so. The relationship is the same as constraints->hardware -- for
machines, we report what we have; for services, we report what we'll be asking
for.

[dimitern, 2014-03-26 13:15:42]

Please take a look.

[fwereade, 2014-03-26 15:41:20]

LGTM with a naming quibble

https://codereview.appspot.com/76400049/diff/20001/state/api/client.go
File state/api/client.go (right):

https://codereview.appspot.com/76400049/diff/20001/state/api/client.go#newcode30
state/api/client.go:30: type NetworksStatus struct {
"Status" doesn't feel quite right. NetworksSpecification perhaps?

[dimitern, 2014-03-26 16:08:55]

Please take a look.

https://codereview.appspot.com/76400049/diff/20001/state/api/client.go
File state/api/client.go (right):

https://codereview.appspot.com/76400049/diff/20001/state/api/client.go#newcode30
state/api/client.go:30: type NetworksStatus struct {
On 2014/03/26 15:41:20, fwereade wrote:
> "Status" doesn't feel quite right. NetworksSpecification perhaps?

Done.