That was my expectation on how it would work
My +1 was the idea of moving the Tracer to a separate service and having
clear instructions for how users get back to the current functionality
(how these two repositories get deployed), *before* it's removed from
core Accumulo.
This is because of the very clear testimony from a user about useful the
feature was to them.
On 3/16/18 7:36 PM, Christopher wrote:
Would you both (Michael and Josh) be okay with moving it to a separate repo
within the Accumulo project rather than ripping it out and leaving it only
buried in git history?
On Fri, Mar 16, 2018 at 7:15 PM Josh Elser <els...@apache.org> wrote:
I think I'm in agreement with this subset of Mikes.
I like the idea long-term. The tracing service is "add-on", and can live
outside Accumulo.
I don't like the idea of moving the code out and taking away code which
is functional today. I am +1 on the idea of building the same
functionality outside of the core product. I am -1 on removing the
functionality in the core product until the replacement is ready (e.g.
clear docs for users covering how they get back to "normal").
On 3/16/18 6:49 PM, Michael Wall wrote:
Yeah, I get it. That should have said "without a working example
alternative". Something to make it as easy as possible for someone
currently using tracing to not loose functionality.
Thanks
On Fri, Mar 16, 2018, 18:38 Christopher <ctubb...@apache.org> wrote:
The alternative is to configure any of the other HTrace sinks which are
available. The current code for Accumulo's tracer service could even be
forked and supported as a separate sink to optionally use (but as I
said in
my original email, I think it'd be better to encourage contribution to
other presentation projects to use Accumulo as a backing store).
On Fri, Mar 16, 2018 at 6:34 PM Michael Wall <mjw...@apache.org> wrote:
I am in favor of removing the tracer ui from the monitor and the tracer
service that stores the spans in Accumulo. I worry about doing so
with a
working alternative though.
On Fri, Mar 16, 2018 at 6:25 PM Mike Drob <md...@apache.org> wrote:
Do we have a migration story ready to go for folks that are used to
seeing
traces on the monitor?
On Fri, Mar 16, 2018 at 5:17 PM, Tony Kurc <trk...@gmail.com> wrote:
I like this idea.
On Fri, Mar 16, 2018 at 5:09 PM, Christopher <ctubb...@apache.org>
wrote:
Devs,
(This discussion is somewhat of a spinoff of our previous recent
conversation about HTrace, but I'd like to narrow the discussion to
one
specific topic regarding our tracer service.)
I'd like to remove Accumulo's tracer service and corresponding
presentations in the monitor for 2.0.
The tracer service currently acts as a sink for the traces from
Accumulo.
While there is interest in tracing Accumulo, and Accumulo may
itself
be
suitable (with the right schema) for storing traces, I do not think
acting
as a "trace sink" is really the kind of thing we should be doing as
part
of
Accumulo's out-of-the-box core functionality.
Also, the presentation and search capabilities of the traces found
in
the
trace table (by convention, and assumed by the monitor) is far from
an
ideal presentation of this data, and I don't think the Accumulo
project
should continue maintaining that inside the core project's monitor,
either.
I think we should encourage interested volunteers to contribute to
other
trace presentation software (wherever they may exist) any necessary
"backing store" implementation based on Accumulo.
None of this would remove tracing instrumentation from Accumulo...
it
would
just require users interested in trace data from Accumulo to
configure
an
appropriate sink to collect that data in some other integrated
component
of
their overall architecture.
Decoupling the integrated trace sink from the instrumentation in
Accumulo
like this could even be a step towards providing support for
multiple
different tracing libraries. (I guess we could do this now, but it
would
be
easier if we were not also trying to provide a sink implementation
for
one
specific version of one specific instrumentation library.)
Thoughts?
