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" <j...@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.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" <adam.coll...@canonical.com> >>> wrote: >>> >>> On Fri, 19 May 2017 at 03:14 Tim Penhey <tim.pen...@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@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
