Bleeding edge testers - do you want to try some new Juju Health/Status functionality?

[Ian Booth]

Hi rocket scientists,

If you don't mind living on the bleeding edge, and are comfortable pulling Juju
source from Github and compiling, we'd love to get some feedback on a very early
version of the new Juju Unit and Service Status work.

What's landed in master are the tools needed to start testing and playing with
the new functionality slated for inclusion in Juju 1.24. More will be landing
over the coming weeks (even as early as next week); what's there is hopefully
enough to get started.

We're still looking at the best way to present and display some aspects of the
data so feedback welcome. And bugs also if you find issues.

Included
--------

Hook tools
----------

juju-set, used to inform Juju or a charm's workload status
eg
  juju-set <maintenance | waiting | blocked | active> [message]

juju-get, used to return the current workload status

juju status
-----------

If you set the feature flag "new-status", the tabular format is the default and
the legacy status information is not shown.

Status data (yaml and json formats) now includes separate status information for
the agent and the workload. For each, the "last updated" time is included to
show when the status was last set.

status behaviour
----------------

The charm is expected to set its own workload status, however Juju will do the
following:

- when the unit's machine is being allocated, the workload status will be
"unknown" with a message "Waiting for agent initialization to finish"

- when the install hook starts, the workload status will change to "maintenance"
with a message "installing charm software"

- when the start hook finishes, if the charm has not set its own status by then,
Juju will set the workload status to "unknown"

- the agent status is more informative eg when a hook runs, or an action, the
agent status is set to "executing" with a message like "running start hook".

- if the agent has been idle for 2 seconds, without new events queued etc, its
status is set to "idle"

So, with the above, you can deploy a unit and "watch juju status" to see a nicer
indication of what's happening as a charm is installed, watch the hooks run etc.


Excluded
--------

- status history
- service status
- status-set hook
- status log
- watcher used by GUI still shows legacy status


Known Issues
------------

- status-get hook tool doesn't show error state for workload


Example Output
--------------
(tabular gets messed up in email, so just including yaml)

environment: local
machines:
  "0":
    agent-state: started
    agent-version: 1.24-alpha1.1
    dns-name: localhost
    instance-id: localhost
    series: utopic
    state-server-member-status: has-vote
  "1":
    agent-state: started
    agent-version: 1.24-alpha1.1
    dns-name: 10.0.1.194
    instance-id: ian-local-machine-1
    series: trusty
    hardware: arch=amd64
services:
  mysql:
    charm: cs:trusty/mysql-24
    exposed: false
    relations:
      cluster:
      - mysql
    units:
      mysql/0:
        workload-status:
          current: error
          message: 'hook failed: "start"'
          since: 01 Apr 15 22:51 AEST
        agent-status:
          current: idle
          since: 01 Apr 15 22:55 AEST
          version: 1.24-alpha1.1
        machine: "1"
        public-address: 10.0.1.194