Debug-Log CLI / API Changes

[Kapil Thangavelu]

On Tue, Feb 18, 2014 at 1:48 PM, roger peppe <rogpeppe at gmail.com> wrote:

> On 18 February 2014 17:48, William Reade <william.reade at canonical.com>
> wrote:
> > I'd prefer to drop --include entirely, and make positional args automatic
> > includes; and never to mention "environment" at the CLI level; but that
> then
> > makes it hard to distinguish between an entity name and a regex to apply
> to
> > the whole environment... *unless* we add a --filter arg for that specific
> > case. Does that work, or do we still have ambiguity lurking? There might
> be
> > an issue with regexes containing "="...
>
> If we say that a regex is *always* preceded by a "=" (actually I prefer ":"
> but I don't want to bikeshed too much), then there's no ambiguity - we
> can allow an empty entity name to imply "environment". We need to do
> this, because otherwise there's an ambiguity between a service named
> "environment" and the environment tag.
>
> The other thing I'd suggest is that regexes apply to the text
> following the tag (you can't use a regex to filter the tag) - this makes an
> efficient implementation easier, and largely avoids the implementation
> leakage that Kapil refers to, I believe.
>

implementation leakage was a reference to would regexes work at all if we
replaced the backend implementation with something a bit more efficient
(say inverted index on log entry context and date). ie are we tying the
user visible api to something we can't commit to or something that doesn't
scale. we've had scenarios with hundreds of mbs of logs, and a regex there
seems questionable. i say this as someone whose currently experiencing
constant log spam from all machines because of an old ssh key which is
results in a 1.6Gb all-machine.log in a few hrs, but the case also exists
for envs that live months or years. its really not clear we're thinking
through the evaluation of log data at that scale in this proposal.

as a minimum addition for long lived envs/units/machines that we'd also
want temporal filters.


>
> I agree with William that we can leave out the explicit --include
> flags.
>

+1

<snip>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20140218/c83ce929/attachment.html>