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 possible to send to any or all of these would serve my needs. This implied to me that the instrumentation was more valuable.
On Sat, Mar 17, 2018 at 3:52 PM, Christopher <ctubb...@apache.org> wrote: > 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's > what led to me discussing removal of this subset, instead of the full > removal mentioned in the previous thread. > > I'm fine with moving things to a separate repo, if that's in demand (can > help with that, too, but no guarantees on how much time I can devote to > it). One thing I think we definitely should do, is shift focus in our core > docs away from our specific tracing sink, and more towards the fact that > the sink is configurable and ours is only one possible. Of course, our > Accumulo-backed sink can have its own documentation. My hope long term, > though, is that other trace sink systems will implement their own > Accumulo-backed implementation, if that's something users really want. > > On Sat, Mar 17, 2018, 15:05 Josh Elser <els...@apache.org> wrote: > > > 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? > > >>>>>>>> > > >>>>>>> > > >>>>>> > > >>>>> > > >>>> > > >>> > > >> > > > > > >
