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

[Ian Booth]

Oh, one more thing.

Hook tools like status-set are usually run inside a hook. If run from the
outside, a little extra work is required. This would be the case where a charm
wants to dynamically update its workload status without waiting to be polled by
Juju.

>From the spec:

Neither polling nor Juju hook execution are the complete answer for status
updates. A piece of software might have reason to think that its service status
has changed at any time. Ideally, such changes would be communicated to other
related software immediately rather than waiting for a hook execution or poll.
Consider the case where a database charm has successfully been installed and is
now running. A periodic database backup may cause a unit to become unable to
accept requests for the duration of the backup. In such cases, the unit needs a
mechanism to report status changes back to the agent, without waiting for a hook
to fire.

juju-run allows external processes to set status:

  juju-run <unitname> ‘status-set maintenance “backing up database”’

In the example above, the process that triggers the backup might set the status
of the unit before taking the database offline.

For juju-run to know what unit status to set, a specific unit name needs to be
provided. The unit name is available within a hook as $JUJU_UNIT_NAME. So the
charm will need remember its unit name from the install hook, and then external
software can be configured to call juju-run as needed to update the unit status
on an ad hoc basis.

On 02/04/15 19:18, Ian Booth wrote:
> 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
> 
> 
> 
> 
>