PROPOSAL: stop recording 'executing update-status hook'

[Alex Kavanagh]

>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.

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.

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.

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?

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.)?

Alex.

On Mon, May 22, 2017 at 9:56 AM, Stuart Bishop <stuart.bishop at canonical.com>
wrote:

> On 22 May 2017 at 14:36, Tim Penhey <tim.penhey at canonical.com> wrote:
> > On 20/05/17 19:48, Merlijn Sebrechts wrote:
> >>
> >> On May 20, 2017 09:05, "John Meinel" <john at arbash-meinel.com
> >> <mailto:john at arbash-meinel.com>> wrote:
> >>
> >>     I would actually prefer if it shows up in 'juju status' but that we
> >>     suppress it from 'juju status-log' by default.
> >>
> >>
> >> This is still very strange behavior. Why should this be default? Just
> pipe
> >> the output of juju status through grep and exclude update-status if
> that is
> >> really what you want.
> >>
> >> However, I would even argue that this isn't what you want in most
> >> use-cases.  "update-status" isn't seen as a special hook in
> charms.reactive.
> >> Anything can happen in that hook if the conditions are right. Ignoring
> >> update-status will have unforeseen consequences...
> >
> >
> > Hmm... there are (at least) two problems here.
> >
> > Firstly, update-status *should* be a special case hook, and it shouldn't
> > take long.
> >
> > The purpose of the update-status hook was to provide a regular beat for
> the
> > charm to report on the workload status. Really it shouldn't be doing
> other
> > things.
> >
> > The fact that it is a periodic execution rather than being executed in
> > response to model changes is the reason it isn't fitting so well into the
> > regular status and status history updates.
> >
> > The changes to the workload status would still be shown in the history of
> > the workload status, and the workload status is shown in the status
> output.
> >
> > One way to limit the execution of the update-status hook call would be to
> > put a hard timeout on it enforced by the agent.
> >
> > Thoughts?
>
> Unfortunately update-status got wired into charms.reactive like all
> the other standard hooks, and just means 'do whatever still needs to
> be done'. I think its too late to add timeouts or restrictions. But I
> do think special casing it in the status history is needed. Anything
> important will still end up in there due to workload status changes.
>
> --
> Stuart Bishop <stuart.bishop at canonical.com>
>
> --
> Juju-dev mailing list
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju-dev
>



-- 
Alex Kavanagh - Software Engineer
Cloud Dev Ops - Solutions & Product Engineering - Canonical Ltd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20170522/70f3bc5d/attachment-0001.html>