Another optimisation possibility might be to send less status updates. For example, the uniter could wait until the hook has been executing for some period of time (e.g. 100ms) before sending the "executing" status. If the hook finishes within that period, it would send a bulk update with two updates (setting the status to "executing" and back). The API server could see that the second update doesn't affect the current status of the unit and just append the two items to the history without needing to update the current unit status, thus (usually, assuming fast hook execution) saving one transaction per update and halving the number of API calls.
As an aside, I wonder if it's right that the status as set by set-status is the same status that's set when executing a hook - ISTM that it might be better if they were separate items of information so that the status set by the hook code is always available regardless of what hooks are executing. On 22 May 2017 at 14:02, roger peppe <roger.pe...@canonical.com> wrote: > On 22 May 2017 at 09:55, Ian Booth <ian.bo...@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. -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
