[
https://issues.apache.org/jira/browse/HADOOP-15566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16807619#comment-16807619
]
Elek, Marton edited comment on HADOOP-15566 at 4/2/19 10:16 AM:
----------------------------------------------------------------
Thanks the questions [~bogdandrutu], sorry I missed this comment earlier.
bq. What implementation will be shipped with the official HBase binary?
I don't know it depends from the HBase imho. With using OT we can use multiple
implementation, HBase can provide any implementation.
bq. How can somebody use a different implementation?
It should be configurable. AFAIK the only vendor specific part is the
initialization code. It's easy to create an interface to initialize different
implementation (eg. a class name which should be called to initialize the
implementation.
bq. How do you ensure that a different implementation (that is not tested with
your entire test suite) may not corrupt user data? I think it is very important
that all the tests are running with the implementation that user uses in
production.
I don't think that we need to test all the implementation. We should prove that
the OT api used well and use one implementation as an example. And we clearly
write the documentation what is tested and what is not. Not tested
implementations which are provided by other vendors can be used but should be
tested before by the users.
bq. use one implementation (pick something that you like the most) and export
these data to an configurable endpoint
Interesting. Can you please give me more details? What is the configurable
endpoint? How the tracing information would be stored?
was (Author: elek):
Thanks the questions [~bogdandrutu]
q. What implementation will be shipped with the official HBase binary?
I don't know it depends from the HBase imho. With using OT we can use multiple
implementation, HBase can provide any implementation.
q. How can somebody use a different implementation?
It should be configurable. AFAIK the only vendor specific part is the
initialization code. It's easy to create an interface to initialize different
implementation (eg. a class name which should be called to initialize the
implementation.
q. How do you ensure that a different implementation (that is not tested with
your entire test suite) may not corrupt user data? I think it is very important
that all the tests are running with the implementation that user uses in
production.
I don't think that we need to test all the implementation. We should prove that
the OT api used well and use one implementation as an example. And we clearly
write the documentation what is tested and what is not. Not tested
implementations which are provided by other vendors can be used but should be
tested before by the users.
q. use one implementation (pick something that you like the most) and export
these data to an configurable endpoint
Interesting. Can you please give me more details? What is the configurable
endpoint? How the tracing information would be stored?
> Remove HTrace support
> ---------------------
>
> Key: HADOOP-15566
> URL: https://issues.apache.org/jira/browse/HADOOP-15566
> Project: Hadoop Common
> Issue Type: Improvement
> Components: metrics
> Affects Versions: 3.1.0
> Reporter: Todd Lipcon
> Priority: Major
> Labels: security
> Attachments: Screen Shot 2018-06-29 at 11.59.16 AM.png,
> ss-trace-s3a.png
>
>
> The HTrace incubator project has voted to retire itself and won't be making
> further releases. The Hadoop project currently has various hooks with HTrace.
> It seems in some cases (eg HDFS-13702) these hooks have had measurable
> performance overhead. Given these two factors, I think we should consider
> removing the HTrace integration. If there is someone willing to do the work,
> replacing it with OpenTracing might be a better choice since there is an
> active community.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
