PROPOSAL: stop recording 'executing update-status hook'

[Merlijn Sebrechts]

On May 20, 2017 09:05, "John Meinel" <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...

(*possibly* we could show it with a flag, but I'm not sure that it is worth
tracking or not.)

John
=:->


On Fri, May 19, 2017 at 9:42 PM, Gregory Lutostanski <gregory.lutostanski@
canonical.com> wrote:

> What would happen if the update-status hook hangs here? I know it only is
> supposed to be for short-duration status messages (but charm bugs are known
> to happen).
>
> In addition, it will also block other hooks/actions from happening until
> completed and it will remain in a stuck state with the status reporting as
> "all good". Is there some middle ground rather than not exposing that the
> unit is working in this situation?
>
> Not to be a nay-sayer just want it more thoroughly looked at from a user's
> least surprise in not-great situations where the deployment is wedged.
>
> We would not know that from the status right? Only from the debug-log.
>
> On May 19, 2017 3:46 AM, "John Meinel" <john at arbash-meinel.com> wrote:
>
>> All agents start up in DEBUG until they can talk to the controller and
>> read what the current logging config is set to. Otherwise you wouldn't be
>> able to debug startup issues.
>> That said, I think there was a request to cache the last-known value in
>> agent.conf which would let restarts be less noisy.
>>
>> John
>> =:->
>>
>>
>> On Fri, May 19, 2017 at 12:23 PM, Samuel Cozannet <
>> samuel.cozannet at canonical.com> wrote:
>>
>>> +1
>>>
>>> Maybe one good thing would also be removing the default --debug flag
>>> from all juju machine startup scripts.
>>> It seems hard coded, and requires edition on most deployment.
>>>
>>> ++
>>> Sam
>>>
>>>
>>> On May 19, 2017 10:12, "Adam Collard" <adam.collard at canonical.com>
>>> wrote:
>>>
>>> On Fri, 19 May 2017 at 03:14 Tim Penhey <tim.penhey at canonical.com>
>>> wrote:
>>>
>>>> Hi folks,
>>>>
>>>> Currently juju will update the status of any hook execution for any unit
>>>> to show that it is busy doing things. This was all well and good until
>>>> we do things based on time.
>>>>
>>>> Every five minutes (or so) each unit will have the update-status hook
>>>> executed to allow the unit to set or update the workload status based on
>>>> what is currently going on with that unit.
>>>>
>>>> Since all hook executions are stored, this means that the
>>>> show-status-log will show the unit jumping from executing update-status
>>>> to ready and back every five minutes.
>>>>
>>>> The proposal is to special case the update-status hook and show in
>>>> status (or the status-log) that the hook is being executed. debug-log
>>>> will continue to show the hook executing if you are looking.
>>>>
>>>> This will reduce noise in the status-log, simplify some of our code
>>>> around dealing with status-log, and reduce load on controllers looking
>>>> after hundreds or thousands of units.
>>>>
>>>
>>> +1
>>>
>>>
>>> --
>>> Juju mailing list
>>> Juju at lists.ubuntu.com
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>> an/listinfo/juju
>>>
>>>
>>>
>>> --
>>> Juju mailing list
>>> Juju at lists.ubuntu.com
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>> an/listinfo/juju
>>>
>>>
>>
>> --
>> Juju-dev mailing list
>> Juju-dev at lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju-dev
>>
>>

--
Juju-dev mailing list
Juju-dev at lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/
mailman/listinfo/juju-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20170520/63e9aaa2/attachment.html>