Debug-Log CLI / API Changes

[Stuart Bishop]

On 19 February 2014 16:36, William Reade <william.reade at canonical.com> wrote:

> * hook stdout/stderr seems definitely useful, no objections there
> * the hook queue is dynamic and unit-local and I currently have no intention
> of exposing it to the state server, let alone the user... what's the  use
> case for it?

Just that it might be interesting to watch the results of juju-set and
if changes are triggering other hooks or not. I guess it isn't
particularly important.

> * hook firing/result pretty much subsumes relation-set info, I don't think
> it's a good idea to make it easy to see relation-sets as they happen; I'm
> fine communicating the aggregate effect of all relation-sets once the hook
> has completed and the changes are sent to the state server, though

Oh, I agree. I'm interested in what is committed when a hook succeeds
rather than watching them as they are set and unset in the hook, and
potentially rollback if the hook fails.

If I want to watch real-time relation-sets, I'd use juju-log in the
charm and also add the annotations I'd need to make sense of the
noise.

> It seems that we can probably cover this with "hook-info" and "hook-output"
> message kinds. But... is there ever a case where you want output but don't
> need to know what hooks are running? It STM that if you ever want
> hook-output you also always want hook-info, and that the effect of the
> relation-sets is a DEBUG-level detail of the hook-info messages.

This seems correct to me.

-- 
Stuart Bishop <stuart.bishop at canonical.com>