[lttng-dev] Proposal: Make lttng-analyses part of lttng-tools

[Jonathan Rajotte-Julien]

On Wed, Jul 18, 2018 at 12:11:03PM -0400, Philippe Proulx wrote:
> On Wed, Jul 18, 2018 at 11:37 AM Geneviève Bastien
> <gbastien at versatic.net> wrote:
> >
> > > I'm eager to get some feedback from Mathieu and Jérémie on all this.
> > So am I!
> 
> Adding mine even if you're not eager to get it ;-).

Well, you will understand that some opinions have more weight than others and
that at the end of the day someone will have to decide something. :)

> 
> As someone who knows a few parts of the LTTng analyses project, it is
> still considered experimental, prototypal, in other words not ready at

It was deemed good enough to be in our Latest Stable PPA.

> all to be integrated within any stable project. It is with good reason
> that its version is still 0.x.
> 
> LTTng analyses helps us prove that such a tool can be useful (we
> received good feedback in general), and it's a great project to quickly

But does people use it? Were they "exposed" to it? Sure the doc mention it but
never uses it. That is normal since the doc is geared toward how to use lttng to
perform tracing. It is not geared toward "what can we get from a (kernel)
trace?". TBH, I'm quite good with that.

> develop a tracing analysis, but it's lacking thorough documentation

> (outside its README file),

It already have more doc than 98% of the utilities I use everyday.

> tests, and by the nature of Python is very
> slow and will probably remain like this forever. LTTng analyses also
> does not handle exceptional scenarios very well.
> 
> Also, do not forget that this project has hard dependencies on Python
> and Babeltrace. What would this mean, on the packaging level, when
> making it part of LTTng-tools, which has a very limited set of
> dependencies on purpose?

This is why "baking it" into the lttng-tools project/package make little sense
and leaving dependency management to the package managers would make sense.

Simply a matter of "do we install it by default or not?".

> 
> I believe our mid/long-term goal is to:
> 
> 1. Release Babeltrace 2 ASAP.

Babeltrace 2 was on the verge of being release 2 years ago if not more. I know that both you
and Jérémie are working quite hard on that and that should be imminent. Still, I
do not think that efforts of putting lttng-analyses in the spot light ,even if it is
considered "experimental", should be put on the Babeltrace 2 backburner.
Even more so if help is coming from a long time member of the community (tahini).

> 2. Optimize Babeltrace 2 for the typical CTF input with stream muxing
>    scenario.
> 3. Create/transfer LTTng analyses as Babeltrace 2 filter or sink
>    components.
> 4. Encourage people to use Babeltrace 2 to analyse LTTng traces.
> 
> That's not to say I disagree with the highlighted problem: our efforts
> should be directed towards offering a streamlined experience to the
> user, from instrumenting to tracing to analyzing.

> 
> By the way, there are still a few professional, rigorous individuals who
> read the documentation, thank God ;-).

Yeah, the doc is very nice. But sometime people need to see "magic" before the
"I want to know how" feeling kicks-in.

IMHO Geneviève's goals can be done outside of the
lttng-analyses project anyway.

>>> 1- Make trace collection with lttng for newcomers a painless process,
>>> easy to document and explain, to get fast results (whether with
>>> lttng-analyses or Trace Compass)
>>> 2- Develop and document methods to collect traces in an OpenStack/ceph
>>> cloud, in conjunction with monitoring tools.

Cheers

-- 
Jonathan Rajotte-Julien
EfficiOS