<div dir="ltr">From a 'principle of least surprise', I think that this proposal is probably a bad idea.  The main driver is to (I guess) reduce the volume of 'chat' between the controller and 100's or 1000's of charms, and the effect this has on the status log.  However, my 'guess' is also probably wrong as it would continue to live in the debug log, which implies it is still being sent/received.<div><br></div><div>I think it would be 'odd' for a status to be running, but not show up in the status or status log - this would be unexpected.</div><div><br></div><div>My counter proposal is to have a toggle to disable 'update status' on a model and/or application level, and/or have the ability to reduce the frequency of the updates.</div><div><br></div><div>However, the downside of reducing/eliminating update-status is that (I suspect) several charms rely on it to recover from errors (particularly) racy ones.  Perhaps, this can be offset (during install) by usage of 'juju run ...' and the fixing the charms with the bugs?</div><div><br></div><div>Another 'worry' is that if update-status is not reflected in 'juju-status' will the workload status be updated (i.e. showing problems, fixing problems, etc.)?</div><div><br></div><div>Alex.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 22, 2017 at 9:56 AM, Stuart Bishop <span dir="ltr"><<a href="mailto:stuart.bishop@canonical.com" target="_blank">stuart.bishop@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 22 May 2017 at 14:36, Tim Penhey <<a href="mailto:tim.penhey@canonical.com">tim.penhey@canonical.com</a>> wrote:<br>
> On 20/05/17 19:48, Merlijn Sebrechts wrote:<br>
>><br>
>> On May 20, 2017 09:05, "John Meinel" <<a href="mailto:john@arbash-meinel.com">john@arbash-meinel.com</a><br>
>> <mailto:<a href="mailto:john@arbash-meinel.com">john@arbash-meinel.com</a><wbr>>> wrote:<br>
>><br>
>>     I would actually prefer if it shows up in 'juju status' but that we<br>
>>     suppress it from 'juju status-log' by default.<br>
>><br>
>><br>
>> This is still very strange behavior. Why should this be default? Just pipe<br>
>> the output of juju status through grep and exclude update-status if that is<br>
>> really what you want.<br>
>><br>
>> However, I would even argue that this isn't what you want in most<br>
>> use-cases.  "update-status" isn't seen as a special hook in charms.reactive.<br>
>> Anything can happen in that hook if the conditions are right. Ignoring<br>
>> update-status will have unforeseen consequences...<br>
><br>
><br>
> Hmm... there are (at least) two problems here.<br>
><br>
> Firstly, update-status *should* be a special case hook, and it shouldn't<br>
> take long.<br>
><br>
> The purpose of the update-status hook was to provide a regular beat for the<br>
> charm to report on the workload status. Really it shouldn't be doing other<br>
> things.<br>
><br>
> The fact that it is a periodic execution rather than being executed in<br>
> response to model changes is the reason it isn't fitting so well into the<br>
> regular status and status history updates.<br>
><br>
> The changes to the workload status would still be shown in the history of<br>
> the workload status, and the workload status is shown in the status output.<br>
><br>
> One way to limit the execution of the update-status hook call would be to<br>
> put a hard timeout on it enforced by the agent.<br>
><br>
> Thoughts?<br>
<br>
</div></div>Unfortunately update-status got wired into charms.reactive like all<br>
the other standard hooks, and just means 'do whatever still needs to<br>
be done'. I think its too late to add timeouts or restrictions. But I<br>
do think special casing it in the status history is needed. Anything<br>
important will still end up in there due to workload status changes.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Stuart Bishop <<a href="mailto:stuart.bishop@canonical.com">stuart.bishop@canonical.com</a>><br>
</font></span><div class="HOEnZb"><div class="h5"><br>
--<br>
Juju-dev mailing list<br>
<a href="mailto:Juju-dev@lists.ubuntu.com">Juju-dev@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" rel="noreferrer" target="_blank">https://lists.ubuntu.com/<wbr>mailman/listinfo/juju-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Alex Kavanagh - Software Engineer<div>Cloud Dev Ops - Solutions & Product Engineering - Canonical Ltd</div></div></div>
</div>