PROPOSAL: stop recording 'executing update-status hook'

[roger peppe]

On 22 May 2017 at 09:55, Ian Booth <ian.booth at canonical.com> wrote:
> On 22/05/17 18:23, roger peppe wrote:
>> I think it's slightly unfortunate that update-status exists at all -
>> it doesn't really need to,
>> AFAICS, as a charm can always do the polling itself if needed; for example:
>>
>>     while :; do
>>          sleep 30
>>          juju-run $UNIT 'status-set current-status "this is what is happening"'
>>     done &
>>
>> Or (better) use juju-run to set the status when the workload
>> executable starts and exits, avoiding the need for polling at all.
>
> It's not sufficient to just set the status when the workload starts and exits.
> One example is a database which periodically goes offline for a short time for
> maintenance. The workload executable itself should not have to know how to
> communicate this to Juju. By the agent running update-status hook periodically,
> it allows the charm itself to establish whether the database status should be
> marked as "maintetance" for example.

Of course there are many ways that a workload can become unavailable,
and sometimes polling may be the only decent answer. My thought is simply
that rather than baking in polling fundamentally, the charm can be the
thing with that knowledge. Even without update-status, a charm could
poll and update its status appropriately if it wants.

> Using a hook provides a standard way all
> charms can rely on to communicate workload status in a consistent way.

Isn't that the "status-set" command? :)

More generally, on the original proposal, I think I tend to agree with
Alex Kavanagh - it would be unexpected for a hook to run but
not to show in the status history.  Given that the motivation behind
the proposal is to reduce load on the database and on controllers, I
wonder if it might be possible to make the status recording mechanism
more efficient.  For example, the document used to store status updates
currently takes about 178 bytes. This could be reduced to about 75 bytes
with some simple changes. It should be possible to reduce the number of
database operations involved in each of the status update calls too - it
might be possible to reduce a status update RPC call to a single insert
operation.

Making the mechanism more efficient would also help other cases too -
for example where an application is continually running some hook other
than update-status.

  rog.

PS I suspect that almost no-one knows that "juju-run" can be used to run
non-hook-initiated charm actions - it's hard to search for, its documentation
isn't available on the client, and it's easily confused with the
client-side "juju run"
command. So my reply was also about raising awareness of this.