Re: [DISCUSS] Introducing OpenTelemerty into our public API
No invitation necessary, the connection details are here, https://github.com/open-telemetry/community#discussions On Tue, Nov 16, 2021 at 7:35 PM 张铎(Duo Zhang) wrote: > Thanks Nick. This is also my understanding if I read your email > correctly... > > And could you please invite me into the OTEL slack channel? > > Thanks. > > Nick Dimiduk 于2021年11月17日周三 上午1:45写道： > > > > From conversations I've had over on the otel slack, it seems that all we > > really need to do is make sure that there's a "current" span when handing > > flow control over to user code. > > > > On Mon, Nov 15, 2021 at 6:15 PM Andrew Purtell > wrote: > > > > > If the exposure is for/within coprocessors, I think that usage falls > under > > > the same exception we make for LimitedPrivate and other things that are > > > necessary for server internal extension but are not public API either. > > > > > > > > > On Tue, Nov 9, 2021 at 4:04 PM Nick Dimiduk > wrote: > > > > > > > Let me find some clarification on what/how might be exposed. > > > > > > > > On Tue, Nov 9, 2021 at 3:34 PM 张铎(Duo Zhang) > > > > wrote: > > > > > > > > > What does ‘expose’ actually mean here? > > > > > > > > > > I think a typical usage is that, users create a span and a scope, > and > > > in > > > > > the scope they call our client API, and our client API will make > use of > > > > the > > > > > Span in the current scope? > > > > > > > > > > So at least we need to let users know they have to use otel if they > > > want > > > > to > > > > > trace HBase calls. But do we really need to expose other things? > > > > > > > > > > Thanks. > > > > > > > > > > Sean Busbey 于2021年11月10日 周三05:40写道： > > > > > > > > > > > If it was akin to slf4j, that integration has been relatively > smooth > > > > > > for downstream. > > > > > > > > > > > > log4j effectively being in our public api through configuration > > > > > > formats has been a maintenance nightmare. > > > > > > > > > > > > These would effectively be in our java binary API though, right? > > > Would > > > > > > we gain any meaningful isolation from trouble later on if we had > > > > > > wrapper objects around the otel stuff? > > > > > > > > > > > > On Tue, Nov 9, 2021 at 2:29 PM Nick Dimiduk > > > > > wrote: > > > > > > > > > > > > > > Heya, > > > > > > > > > > > > > > I've been kicking the tires on the OpenTelemetry tracing work > and I > > > > > have > > > > > > an > > > > > > > ugly question to present. One of the things suggested by the > otel > > > > > > community > > > > > > > is that library implementers (like us, with hbase-client) > expose > > > the > > > > > > > Span/Scope objects to callers so that they can add context > > > > > annotations. I > > > > > > > think this means adding API calls that return otel instances. > From > > > > our > > > > > > > previous experience exposing Guava objects in our API, this > sounds > > > no > > > > > > good. > > > > > > > On the other hand, log4j and SLF4j are effectively in our > public > > > API, > > > > > and > > > > > > > so maybe otel is of a similar breed. > > > > > > > > > > > > > > I have not yet attempted to implement exposure of their > objects in > > > > our > > > > > > > client API, so as of now, my position is that of speculation. > I'll > > > > > report > > > > > > > back as I make progress in this direction. If anyone else has > > > already > > > > > > > traveled this road, please speak up and share your experiences. > > > > > > > > > > > > > > Thanks, > > > > > > > Nick > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Best regards, > > > Andrew > > > > > > Words like orphans lost among the crosstalk, meaning torn from truth's > > > decrepit hands > > >- A23, Crosstalk > > > >
Re: [DISCUSS] Introducing OpenTelemerty into our public API
Thanks Nick. This is also my understanding if I read your email correctly... And could you please invite me into the OTEL slack channel? Thanks. Nick Dimiduk 于2021年11月17日周三 上午1:45写道： > > From conversations I've had over on the otel slack, it seems that all we > really need to do is make sure that there's a "current" span when handing > flow control over to user code. > > On Mon, Nov 15, 2021 at 6:15 PM Andrew Purtell wrote: > > > If the exposure is for/within coprocessors, I think that usage falls under > > the same exception we make for LimitedPrivate and other things that are > > necessary for server internal extension but are not public API either. > > > > > > On Tue, Nov 9, 2021 at 4:04 PM Nick Dimiduk wrote: > > > > > Let me find some clarification on what/how might be exposed. > > > > > > On Tue, Nov 9, 2021 at 3:34 PM 张铎(Duo Zhang) > > > wrote: > > > > > > > What does ‘expose’ actually mean here? > > > > > > > > I think a typical usage is that, users create a span and a scope, and > > in > > > > the scope they call our client API, and our client API will make use of > > > the > > > > Span in the current scope? > > > > > > > > So at least we need to let users know they have to use otel if they > > want > > > to > > > > trace HBase calls. But do we really need to expose other things? > > > > > > > > Thanks. > > > > > > > > Sean Busbey 于2021年11月10日 周三05:40写道： > > > > > > > > > If it was akin to slf4j, that integration has been relatively smooth > > > > > for downstream. > > > > > > > > > > log4j effectively being in our public api through configuration > > > > > formats has been a maintenance nightmare. > > > > > > > > > > These would effectively be in our java binary API though, right? > > Would > > > > > we gain any meaningful isolation from trouble later on if we had > > > > > wrapper objects around the otel stuff? > > > > > > > > > > On Tue, Nov 9, 2021 at 2:29 PM Nick Dimiduk > > > wrote: > > > > > > > > > > > > Heya, > > > > > > > > > > > > I've been kicking the tires on the OpenTelemetry tracing work and I > > > > have > > > > > an > > > > > > ugly question to present. One of the things suggested by the otel > > > > > community > > > > > > is that library implementers (like us, with hbase-client) expose > > the > > > > > > Span/Scope objects to callers so that they can add context > > > > annotations. I > > > > > > think this means adding API calls that return otel instances. From > > > our > > > > > > previous experience exposing Guava objects in our API, this sounds > > no > > > > > good. > > > > > > On the other hand, log4j and SLF4j are effectively in our public > > API, > > > > and > > > > > > so maybe otel is of a similar breed. > > > > > > > > > > > > I have not yet attempted to implement exposure of their objects in > > > our > > > > > > client API, so as of now, my position is that of speculation. I'll > > > > report > > > > > > back as I make progress in this direction. If anyone else has > > already > > > > > > traveled this road, please speak up and share your experiences. > > > > > > > > > > > > Thanks, > > > > > > Nick > > > > > > > > > > > > > > > > > > -- > > Best regards, > > Andrew > > > > Words like orphans lost among the crosstalk, meaning torn from truth's > > decrepit hands > >- A23, Crosstalk > >
Re: [DISCUSS] Introducing OpenTelemerty into our public API
>From conversations I've had over on the otel slack, it seems that all we really need to do is make sure that there's a "current" span when handing flow control over to user code. On Mon, Nov 15, 2021 at 6:15 PM Andrew Purtell wrote: > If the exposure is for/within coprocessors, I think that usage falls under > the same exception we make for LimitedPrivate and other things that are > necessary for server internal extension but are not public API either. > > > On Tue, Nov 9, 2021 at 4:04 PM Nick Dimiduk wrote: > > > Let me find some clarification on what/how might be exposed. > > > > On Tue, Nov 9, 2021 at 3:34 PM 张铎(Duo Zhang) > > wrote: > > > > > What does ‘expose’ actually mean here? > > > > > > I think a typical usage is that, users create a span and a scope, and > in > > > the scope they call our client API, and our client API will make use of > > the > > > Span in the current scope? > > > > > > So at least we need to let users know they have to use otel if they > want > > to > > > trace HBase calls. But do we really need to expose other things? > > > > > > Thanks. > > > > > > Sean Busbey 于2021年11月10日 周三05:40写道： > > > > > > > If it was akin to slf4j, that integration has been relatively smooth > > > > for downstream. > > > > > > > > log4j effectively being in our public api through configuration > > > > formats has been a maintenance nightmare. > > > > > > > > These would effectively be in our java binary API though, right? > Would > > > > we gain any meaningful isolation from trouble later on if we had > > > > wrapper objects around the otel stuff? > > > > > > > > On Tue, Nov 9, 2021 at 2:29 PM Nick Dimiduk > > wrote: > > > > > > > > > > Heya, > > > > > > > > > > I've been kicking the tires on the OpenTelemetry tracing work and I > > > have > > > > an > > > > > ugly question to present. One of the things suggested by the otel > > > > community > > > > > is that library implementers (like us, with hbase-client) expose > the > > > > > Span/Scope objects to callers so that they can add context > > > annotations. I > > > > > think this means adding API calls that return otel instances. From > > our > > > > > previous experience exposing Guava objects in our API, this sounds > no > > > > good. > > > > > On the other hand, log4j and SLF4j are effectively in our public > API, > > > and > > > > > so maybe otel is of a similar breed. > > > > > > > > > > I have not yet attempted to implement exposure of their objects in > > our > > > > > client API, so as of now, my position is that of speculation. I'll > > > report > > > > > back as I make progress in this direction. If anyone else has > already > > > > > traveled this road, please speak up and share your experiences. > > > > > > > > > > Thanks, > > > > > Nick > > > > > > > > > > > > -- > Best regards, > Andrew > > Words like orphans lost among the crosstalk, meaning torn from truth's > decrepit hands >- A23, Crosstalk >
Re: [DISCUSS] Introducing OpenTelemerty into our public API
If the exposure is for/within coprocessors, I think that usage falls under the same exception we make for LimitedPrivate and other things that are necessary for server internal extension but are not public API either. On Tue, Nov 9, 2021 at 4:04 PM Nick Dimiduk wrote: > Let me find some clarification on what/how might be exposed. > > On Tue, Nov 9, 2021 at 3:34 PM 张铎(Duo Zhang) > wrote: > > > What does ‘expose’ actually mean here? > > > > I think a typical usage is that, users create a span and a scope, and in > > the scope they call our client API, and our client API will make use of > the > > Span in the current scope? > > > > So at least we need to let users know they have to use otel if they want > to > > trace HBase calls. But do we really need to expose other things? > > > > Thanks. > > > > Sean Busbey 于2021年11月10日 周三05:40写道： > > > > > If it was akin to slf4j, that integration has been relatively smooth > > > for downstream. > > > > > > log4j effectively being in our public api through configuration > > > formats has been a maintenance nightmare. > > > > > > These would effectively be in our java binary API though, right? Would > > > we gain any meaningful isolation from trouble later on if we had > > > wrapper objects around the otel stuff? > > > > > > On Tue, Nov 9, 2021 at 2:29 PM Nick Dimiduk > wrote: > > > > > > > > Heya, > > > > > > > > I've been kicking the tires on the OpenTelemetry tracing work and I > > have > > > an > > > > ugly question to present. One of the things suggested by the otel > > > community > > > > is that library implementers (like us, with hbase-client) expose the > > > > Span/Scope objects to callers so that they can add context > > annotations. I > > > > think this means adding API calls that return otel instances. From > our > > > > previous experience exposing Guava objects in our API, this sounds no > > > good. > > > > On the other hand, log4j and SLF4j are effectively in our public API, > > and > > > > so maybe otel is of a similar breed. > > > > > > > > I have not yet attempted to implement exposure of their objects in > our > > > > client API, so as of now, my position is that of speculation. I'll > > report > > > > back as I make progress in this direction. If anyone else has already > > > > traveled this road, please speak up and share your experiences. > > > > > > > > Thanks, > > > > Nick > > > > > > -- Best regards, Andrew Words like orphans lost among the crosstalk, meaning torn from truth's decrepit hands - A23, Crosstalk
Re: [DISCUSS] Introducing OpenTelemerty into our public API
Let me find some clarification on what/how might be exposed. On Tue, Nov 9, 2021 at 3:34 PM 张铎(Duo Zhang) wrote: > What does ‘expose’ actually mean here? > > I think a typical usage is that, users create a span and a scope, and in > the scope they call our client API, and our client API will make use of the > Span in the current scope? > > So at least we need to let users know they have to use otel if they want to > trace HBase calls. But do we really need to expose other things? > > Thanks. > > Sean Busbey 于2021年11月10日 周三05:40写道： > > > If it was akin to slf4j, that integration has been relatively smooth > > for downstream. > > > > log4j effectively being in our public api through configuration > > formats has been a maintenance nightmare. > > > > These would effectively be in our java binary API though, right? Would > > we gain any meaningful isolation from trouble later on if we had > > wrapper objects around the otel stuff? > > > > On Tue, Nov 9, 2021 at 2:29 PM Nick Dimiduk wrote: > > > > > > Heya, > > > > > > I've been kicking the tires on the OpenTelemetry tracing work and I > have > > an > > > ugly question to present. One of the things suggested by the otel > > community > > > is that library implementers (like us, with hbase-client) expose the > > > Span/Scope objects to callers so that they can add context > annotations. I > > > think this means adding API calls that return otel instances. From our > > > previous experience exposing Guava objects in our API, this sounds no > > good. > > > On the other hand, log4j and SLF4j are effectively in our public API, > and > > > so maybe otel is of a similar breed. > > > > > > I have not yet attempted to implement exposure of their objects in our > > > client API, so as of now, my position is that of speculation. I'll > report > > > back as I make progress in this direction. If anyone else has already > > > traveled this road, please speak up and share your experiences. > > > > > > Thanks, > > > Nick > > >
Re: [DISCUSS] Introducing OpenTelemerty into our public API
What does ‘expose’ actually mean here? I think a typical usage is that, users create a span and a scope, and in the scope they call our client API, and our client API will make use of the Span in the current scope? So at least we need to let users know they have to use otel if they want to trace HBase calls. But do we really need to expose other things? Thanks. Sean Busbey 于2021年11月10日 周三05:40写道： > If it was akin to slf4j, that integration has been relatively smooth > for downstream. > > log4j effectively being in our public api through configuration > formats has been a maintenance nightmare. > > These would effectively be in our java binary API though, right? Would > we gain any meaningful isolation from trouble later on if we had > wrapper objects around the otel stuff? > > On Tue, Nov 9, 2021 at 2:29 PM Nick Dimiduk wrote: > > > > Heya, > > > > I've been kicking the tires on the OpenTelemetry tracing work and I have > an > > ugly question to present. One of the things suggested by the otel > community > > is that library implementers (like us, with hbase-client) expose the > > Span/Scope objects to callers so that they can add context annotations. I > > think this means adding API calls that return otel instances. From our > > previous experience exposing Guava objects in our API, this sounds no > good. > > On the other hand, log4j and SLF4j are effectively in our public API, and > > so maybe otel is of a similar breed. > > > > I have not yet attempted to implement exposure of their objects in our > > client API, so as of now, my position is that of speculation. I'll report > > back as I make progress in this direction. If anyone else has already > > traveled this road, please speak up and share your experiences. > > > > Thanks, > > Nick >
Re: [DISCUSS] Introducing OpenTelemerty into our public API
If it was akin to slf4j, that integration has been relatively smooth for downstream. log4j effectively being in our public api through configuration formats has been a maintenance nightmare. These would effectively be in our java binary API though, right? Would we gain any meaningful isolation from trouble later on if we had wrapper objects around the otel stuff? On Tue, Nov 9, 2021 at 2:29 PM Nick Dimiduk wrote: > > Heya, > > I've been kicking the tires on the OpenTelemetry tracing work and I have an > ugly question to present. One of the things suggested by the otel community > is that library implementers (like us, with hbase-client) expose the > Span/Scope objects to callers so that they can add context annotations. I > think this means adding API calls that return otel instances. From our > previous experience exposing Guava objects in our API, this sounds no good. > On the other hand, log4j and SLF4j are effectively in our public API, and > so maybe otel is of a similar breed. > > I have not yet attempted to implement exposure of their objects in our > client API, so as of now, my position is that of speculation. I'll report > back as I make progress in this direction. If anyone else has already > traveled this road, please speak up and share your experiences. > > Thanks, > Nick
