It is also important to note that while aiming to be an instrumentation api, OT would have to be used a specific way in order to retain parent semantics in the same way as existing htrace instrumentation does. For example, if someone writes to the OT api, with multiple calls to "childOf" reference, it would need to end up semantically the same as existing HTrace instrumentation or the spans won't be as usable.
This is very different than the zipkin integration as zipkin does not require use of a specific programming api. The zipkin integration is a simple model conversion, rather than something that implies a rewrite of HDFS instrumentation, for example. One milestone for an interested contributor would be to make OpenTracing instrumentation which ends up in HTrace as if it was written with HTrace's SDK. A proof of concept could attempt to forward OpenTracing library calls to HTrace core library calls (this is a typical pattern). It would also need to consider in-process propagation which is still not yet formalized in OpenTracing. I'd expect such an experiment to take at least a few days from an experienced developer. Once the concept is proven (the OT api has the features needed by HTrace), a call to formalize such becomes more interesting and relevant. My 2p -A On Tue, Mar 21, 2017 at 2:59 AM, Raam Rosh-Hai <r...@findhotel.net> wrote: > Thank you Colin for the quick and thorough reply, that's just what I was > looking for. I didn't know what words to use since you can use htrace with > zipkin, the parents are dropped automatically. The multiple parent thing is > what I suspected to be "different" in the words of opentracing > http://opentracing.io/documentation/. > > Thanks again, > > On 20 March 2017 at 19:54, Colin McCabe <cmcc...@apache.org> wrote: > >> Hi Raam, >> >> As you know, OpenTracing is an API which uses other tracing systems as >> the backend. So, for example, you can use OpenTracing with a >> proprietary backend. Or you can use OpenTracing with Zipkin as the >> backend. In this context, the function of the "backend" is to store and >> process the spans. >> >> There was some recent discussion on the mailing list about setting up an >> OpenTracing connector that would send spans to HTrace. That sounds like >> a good initiative, and perhaps that's what you mean by "OpenTracing >> compliant"? >> >> As I remember, the main difference between HTrace and OpenTracing data >> models was about whether spans should have multiple parents or a single >> parent. The single-parent model was simpler to display in GUIs, but it >> leads to people needing to use other IDs to associate related groups of >> spans. This is something we might revisit in the future if there are >> better ways of doing the same thing, but for now we have multiple >> parents. In any case, this will not prevent an OpenTracing-to-HTrace >> connector from being written if people want one. >> >> best, >> Colin >> >> >> On Mon, Mar 20, 2017, at 09:49, Raam Rosh-Hai wrote: >> > Hi Guys, >> > >> > For my talk about tracing scala application I talk about Htrace and >> > zipkin, >> > After reading the opentracing spec it seems like htrace does follow most >> > if not all of the open tracing spec, for completeness and correctness I >> > would really appreciate it if someone can describe what is missing in >> > order >> > for Htrace to opentracing implementation. >> > >> > I am not implying it's neceserry that htrace should be complaint but I >> > think it would be interesting to highlights the differences if any >> > between >> > the methods. >> > >> > Thanks, >> > Raam >>
