Re: PROPOSAL: stop recording 'executing update-status hook'

2017-05-22 Thread 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 
wrote:

> On 22 May 2017 at 14:36, Tim Penhey  wrote:
> > On 20/05/17 19:48, Merlijn Sebrechts wrote:
> >>
> >> On May 20, 2017 09:05, "John Meinel"  >> > 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 
>
> --
> Juju-dev mailing list
> juju-...@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
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: PROPOSAL: stop recording 'executing update-status hook'

2017-05-22 Thread Stuart Bishop 
On 22 May 2017 at 14:36, Tim Penhey  wrote:
> On 20/05/17 19:48, Merlijn Sebrechts wrote:
>>
>> On May 20, 2017 09:05, "John Meinel" > > 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 

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: PROPOSAL: stop recording 'executing update-status hook'

2017-05-22 Thread Tim Penhey 

On 20/05/17 19:48, Merlijn Sebrechts wrote:
On May 20, 2017 09:05, "John Meinel" > 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?

--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: PROPOSAL: stop recording 'executing update-status hook'

2017-05-22 Thread Tim Penhey 

On 19/05/17 19:21, roger peppe wrote:

On 19 May 2017 at 03:13, Tim Penhey  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.


Presumably you mean *not* show in status here?


Yes. Sorry.

--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: PROPOSAL: stop recording 'executing update-status hook'

2017-05-20 Thread Merlijn Sebrechts 
On May 20, 2017 09:05, "John Meinel"  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  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"  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.cozan...@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" 
>>> wrote:
>>>
>>> On Fri, 19 May 2017 at 03:14 Tim Penhey 
>>> 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@lists.ubuntu.com
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>> an/listinfo/juju
>>>
>>>
>>>
>>> --
>>> Juju mailing list
>>> Juju@lists.ubuntu.com
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>> an/listinfo/juju
>>>
>>>
>>
>> --
>> Juju-dev mailing list
>> juju-...@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju-dev
>>
>>

--
Juju-dev mailing list
juju-...@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/
mailman/listinfo/juju-dev
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: PROPOSAL: stop recording 'executing update-status hook'

2017-05-20 Thread Merlijn Sebrechts 
Not showing subsequent runs seems very strange behavior as an end user and
will complicate debugging issues with update-status hooks.

Don't remove logs just because they are too verbose, there are use-cases
where this info is needed.


On May 19, 2017 04:14, "Tim Penhey"  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.

Is anyone opposed to this change?

Tim

-- 
Juju-dev mailing list
juju-...@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
an/listinfo/juju-dev
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: PROPOSAL: stop recording 'executing update-status hook'

2017-05-20 Thread John Meinel 
I would actually prefer if it shows up in 'juju status' but that we
suppress it from 'juju status-log' by default. (*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.lutostan...@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"  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.cozan...@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" 
>>> wrote:
>>>
>>> On Fri, 19 May 2017 at 03:14 Tim Penhey 
>>> 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@lists.ubuntu.com
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>> an/listinfo/juju
>>>
>>>
>>>
>>> --
>>> Juju mailing list
>>> Juju@lists.ubuntu.com
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>> an/listinfo/juju
>>>
>>>
>>
>> --
>> Juju-dev mailing list
>> juju-...@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju-dev
>>
>>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: PROPOSAL: stop recording 'executing update-status hook'

2017-05-19 Thread Gregory Lutostanski 
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"  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.cozan...@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"  wrote:
>>
>> On Fri, 19 May 2017 at 03:14 Tim Penhey  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@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju
>>
>>
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju
>>
>>
>
> --
> Juju-dev mailing list
> juju-...@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju-dev
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: PROPOSAL: stop recording 'executing update-status hook'

2017-05-19 Thread John Meinel 
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.cozan...@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"  wrote:
>
> On Fri, 19 May 2017 at 03:14 Tim Penhey  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@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
> an/listinfo/juju
>
>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: PROPOSAL: stop recording 'executing update-status hook'

2017-05-19 Thread Samuel Cozannet 
+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"  wrote:

On Fri, 19 May 2017 at 03:14 Tim Penhey  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@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/
mailman/listinfo/juju
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: PROPOSAL: stop recording 'executing update-status hook'

2017-05-19 Thread Uros Jovanovic 
+1

On Fri, May 19, 2017 at 4:13 AM, Tim Penhey 
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.
>
> Is anyone opposed to this change?
>
> Tim
>
> --
> Juju-dev mailing list
> juju-...@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
> an/listinfo/juju-dev
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: PROPOSAL: stop recording 'executing update-status hook'

2017-05-19 Thread Adam Collard 
On Fri, 19 May 2017 at 03:14 Tim Penhey  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@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: PROPOSAL: stop recording 'executing update-status hook'

2017-05-19 Thread roger peppe 
On 19 May 2017 at 03:13, Tim Penhey  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.

Presumably you mean *not* show in status here?

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: PROPOSAL: stop recording 'executing update-status hook'

2017-05-19 Thread Ante Karamatić 
+1

On Fri, May 19, 2017 at 6:10 AM David Britton 
wrote:

> +1 from me: https://bugs.launchpad.net/juju/+bug/1530840
>
> :)
>
> On Thu, May 18, 2017 at 8:13 PM, Tim Penhey 
> 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.
>>
>> Is anyone opposed to this change?
>
>
>>
>> Tim
>>
>> --
>> Juju-dev mailing list
>> juju-...@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>
>
>
>
> --
> David Britton 
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Ante Karamatić
ante.karama...@canonical.com
Canonical
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: PROPOSAL: stop recording 'executing update-status hook'

2017-05-18 Thread David Britton 
+1 from me: https://bugs.launchpad.net/juju/+bug/1530840

:)

On Thu, May 18, 2017 at 8:13 PM, Tim Penhey 
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.
>
> Is anyone opposed to this change?
>
> Tim
>
> --
> Juju-dev mailing list
> juju-...@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
> an/listinfo/juju-dev
>



-- 
David Britton 
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju