status output changes

[Gustavo Niemeyer]

> lp:871743 and lp:769120 imply changes to status output, and we should
> make sure we've considered them properly before we actually make the
> changes. So, I propose that:

Thanks for publishing this to the list William.

> 1) Unit state dicts' "state"s will contain the following possible
> values:
>
>  * If no unit workflow state has been set: "pending"
>  * Elif unit agent is not connected: "down"
>  * Else: the current value of the unit workflow state

Sounds good.

> 2) Machine state dicts' "state"s will contain the following possible
> values:
>
>  * If a machine agent is connected: "running"
>  * Elif every assigned unit is "pending": "pending (instance: %s)"
>  * Else: "down (instance: %s)"

The underlying idea looks sensible, but there's no reason to conflate
the instance state onto the same field and have people parsing that
out by hand. We can easily have that information in a different field
in the yaml.

Also, "pending" feels strange here, since it's providing data about
the units rather than the machine itself (it's the unit that is
pending, not the machine).

> When a machine agent is not running, the "(instance: %s)"s are intended
> to give users visibility into the underlying state of the provider
> machine; it's useful to know, for example, the difference between an
> orchestra machine that was never successfully provisioned as opposed to
> one that "should" now be running.

Agreed, the field looks nice, it'd just be nice to split it out.

-- 
Gustavo Niemeyer
http://niemeyer.net
http://niemeyer.net/plus
http://niemeyer.net/twitter
http://niemeyer.net/blog

-- I'm not absolutely sure of anything.