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? > >>>>>> > >>>>> > >>>> > >>> > >> > > >
