I am +0 for this proposal and agree that putting it in a separate repo
would be preferable to dropping it. I tend to think that a better eventual
home for the Accumulo span receiver would be in HTrace itself -- that would
solve a lot of our version compatibility issues. That said, I wanted to
Christopher hit the nail on the head.
Based on my comments, what I didn't say explicitly what was more valuable -
the instrumentation or the tracing service. My opinion is that there are
other tracing backends (
http://opentracing.io/documentation/pages/supported-tracers.html) and if it
was
If you're talking about Tony's user testimony, he already indicated in this
thread approval of this proposal prior to any mention of another repo. My
understanding (perhaps he can clarify here) is that his primary concern was
keeping the instrumentation and the ability to send to another sink.
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
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 wrote:
> I think I'm in agreement with this subset of
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
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 wrote:
> The alternative is to configure
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
Nothing is "ready to go". We've barely started the discussion.
Is there a story you'd like to see?
On Fri, Mar 16, 2018 at 6:25 PM Mike Drob 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
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 wrote:
> Do we have a migration story ready to go for folks
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 wrote:
> I like this idea.
>
> On Fri, Mar 16, 2018 at 5:09 PM, Christopher wrote:
>
> > Devs,
> >
> > (This
I like this idea.
On Fri, Mar 16, 2018 at 5:09 PM, Christopher 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.)
>
>
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
13 matches
Mail list logo