<div dir="auto"><div><br><div class="gmail_extra"><br><div class="gmail_quote">On May 20, 2017 09:05, "John Meinel" <<a href="mailto:john@arbash-meinel.com">john@arbash-meinel.com</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I would actually prefer if it shows up in 'juju status' but that we suppress it from 'juju status-log' by default.</div></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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...</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">(*possibly* we could show it with a flag, but I'm not sure that it is worth tracking or not.)<div><br></div><div>John</div><div>=:-></div><div><br></div></div><div class="elided-text"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 19, 2017 at 9:42 PM, Gregory Lutostanski <span dir="ltr"><<a href="mailto:gregory.lutostanski@canonical.com" target="_blank">gregory.lutostanski@<wbr>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 dir="auto">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).<div dir="auto"><br></div><div dir="auto">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?</div><div dir="auto"><br></div><div dir="auto">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.<br><div dir="auto"><br></div><div dir="auto">We would not know that from the status right? Only from the debug-log.</div></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="m_-8050556019638222099h5">On May 19, 2017 3:46 AM, "John Meinel" <<a href="mailto:john@arbash-meinel.com" target="_blank">john@arbash-meinel.com</a>> wrote:<br type="attribution"></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="m_-8050556019638222099h5"><div dir="ltr">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.<div>That said, I think there was a request to cache the last-known value in agent.conf which would let restarts be less noisy.</div><div><br></div><div>John</div><div>=:-></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 19, 2017 at 12:23 PM, Samuel Cozannet <span dir="ltr"><<a href="mailto:samuel.cozannet@canonical.com" target="_blank">samuel.cozannet@canonical.com</a><wbr>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>+1 <div dir="auto"><br></div><div dir="auto">Maybe one good thing would also be removing the default --debug flag from all juju machine startup scripts. </div><div dir="auto">It seems hard coded, and requires edition on most deployment.</div><div dir="auto"><br></div><div dir="auto">++</div><div dir="auto">Sam</div><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="m_-8050556019638222099m_8414204969143520021m_-6249121545217293438h5">On May 19, 2017 10:12, "Adam Collard" <<a href="mailto:adam.collard@canonical.com" target="_blank">adam.collard@canonical.com</a>> wrote:<br type="attribution"></div></div><blockquote class="m_-8050556019638222099m_8414204969143520021m_-6249121545217293438m_5049271595201909273quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="m_-8050556019638222099m_8414204969143520021m_-6249121545217293438h5"><div dir="ltr"><div class="gmail_quote"><div class="m_-8050556019638222099m_8414204969143520021m_-6249121545217293438m_5049271595201909273quoted-text"><div dir="ltr">On Fri, 19 May 2017 at 03:14 Tim Penhey <<a href="mailto:tim.penhey@canonical.com" target="_blank">tim.penhey@canonical.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi folks,<br>
<br>
Currently juju will update the status of any hook execution for any unit<br>
to show that it is busy doing things. This was all well and good until<br>
we do things based on time.<br>
<br>
Every five minutes (or so) each unit will have the update-status hook<br>
executed to allow the unit to set or update the workload status based on<br>
what is currently going on with that unit.<br>
<br>
Since all hook executions are stored, this means that the<br>
show-status-log will show the unit jumping from executing update-status<br>
to ready and back every five minutes.<br>
<br>
The proposal is to special case the update-status hook and show in<br>
status (or the status-log) that the hook is being executed. debug-log<br>
will continue to show the hook executing if you are looking.<br>
<br>
This will reduce noise in the status-log, simplify some of our code<br>
around dealing with status-log, and reduce load on controllers looking<br>
after hundreds or thousands of units.<br></blockquote></div><div><br>+1</div><br></div></div>
<br></div></div><span>--<br>
Juju mailing list<br>
<a href="mailto:Juju@lists.ubuntu.com" target="_blank">Juju@lists.ubuntu.com</a><br></span><span>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailm<wbr>an/listinfo/juju</a><br>
<br></span></blockquote></div><br></div></div></div>
<br>--<br>
Juju mailing list<br>
<a href="mailto:Juju@lists.ubuntu.com" target="_blank">Juju@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailm<wbr>an/listinfo/juju</a><br>
<br></blockquote></div><br></div>
<br></div></div><span>--<br>
Juju-dev mailing list<br>
<a href="mailto:Juju-dev@lists.ubuntu.com" target="_blank">Juju-dev@lists.ubuntu.com</a><br></span>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailm<wbr>an/listinfo/juju-dev</a><br>
<br></blockquote></div></div>
</blockquote></div><br></div>
</div><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>
<br></blockquote></div><br></div></div></div>