Open Telemetry Uncategorized, 23 Mar 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: 2023-03-23 meeting

Description

cncf-opentelemetry@cncf.io's Personal Meeting Room

A

B

Good morning, good afternoon, good evening,.

A

One is always right.

A

So it's a good morning for you right.

B

It is morning for me, yes, I'm, on the west coast of this U.S.

A

It's uh afternoon from you.

B

I do like the way I think one of the Linux groups would do it in their IRC Channel, which was you always say good morning when you join the channel, no matter what it's morning for somebody somewhere and you always say good night when you leave the channel. So that's.

A

C

Is Trask still out.

A

I think so, yeah.

D

I think so too yeah I think he's back next week. Jason.

B

What is your hat? Is it a Quaker State? What is it unplugged, Hotel unplugged wow. Look at that thing. Where'd you get that uh sweet, sweet piece of swag.

C

I got that at the hotel unplugged event at kubecon.

B

C

B

Have one for you, do you not still have one for me? No.

C

B

C

Right there, for you, I grabbed the second one.

B

We need to do lunch one of these days and uh I. Can we can do the handoff.

C

Yeah, when there's not a wintry mix happening yeah.

E

E

Well, there's nothing on the agenda today, so this meeting might be short.

B

Jack, what is that? What is that uh lit up thing that looks like a bookcase or an aquarium or a plant stand behind you.

E

uh It's a hydroponic garden. um Yeah got all this uh I got it wired out to monitor with open Telemetry nice.

B

E

B

The metrics to New Relic, oh.

E

B

E

And then I uh I built a little web app around it so that every time I, plant or harvest something from it, I can record some simple data about. You know how much how much the yield was and how good the quality was and I can track that over time to combined with the uh you know, the state of the system, the ph and the nutrient content and stuff to find the the best conditions for different varieties.

B

Cool yeah I still monitor them with the why the temperature in my wine cellar, sending the the metrics to New Relic.

E

In that free tier yep, yep.

C

Are they ever going to take that away? I thought they were going to I, haven't.

E

Heard any plans of it I.

B

Mean originally New Relic would give away a free for Life uh account for every employee. That's.

C

What I was talking about? Oh but you're, talking free tier yeah, okay, sorry.

C

B

Think they took away the employee.

C

B

Oh, did they I, don't know too many former employees, oh zinged,.

E

B

It looks like Mr Benson added an agenda item.

E

Tyler, why don't you take the floor? You're the only person with an item.

F

So I was just gonna, throw this out there. This is something I suggested to Alex uh button on uh and he's talking about it with the uh The Collector group, but one of the things that I found a little annoying uh in the hotel scape uh that I missed from when I was at datadog uh at datadog, uh at least in the Java repo. What we did is we have uh we had um since I'm, not there anymore uh uh GitHub action that would automatically assign merged PRS to a specific milestone.

F

uh So that way you could see. Okay, uh this PR is going to be released on this particular version uh much easier, and there was another GitHub action that would automatically update those milestones and you know, help keep track and uh I felt I found that that worked pretty nicely for uh for helping visualize that okay, uh this PR is fixed in this version.

F

uh It even worked with issues where, uh when a release was merged or uh when a when a a release went out, uh the action would add a comment to issues that said, um you know this issue is fixed in this version and you can now go download the uh the version. uh The the new release.

F

Does that sound like something that uh I guess? First of all, do we use milestones for anything else in this repo? Are there open milestones.

B

Which of the many repos are you referring to and I think the answer is no. In all cases.

F

But I guess Java or Java instrumentation.

F

B

F

Process really can apply to either so.

D

In general instrumentation, we use Milestones uh three team match at the last stretch when we're releasing things into just add the things that we want to make sure they get merged before we hit the button, uh that's the only use of Milestones that I'm aware of.

E

It's a very situational.

F

So yeah, okay I see 20 closed Milestones um but yeah. Okay,.

F

So I guess in the instrumentation repo there is some use of milestones.

F

So I guess the question is: uh do you see value in automating that uh and and kind of formalizing that the idea is like you always have an open Milestone uh so that way as PRS get merged, you can automatically add it to that particular Milestone. And then, when you go to release you close that Milestone and create a new one based off of what the the next release version would be.

E

G

E

Gut reaction is this feels pretty similar to the the change log, where we already reference, PR numbers and Link out to them, but there's there's something that's kind of uh like missing from the change log, which is you know if you're, if you're starting your navigation from an issue, uh you you don't you don't understand which release it was included and you can start at the change log at the release and navigate back to the issue, but not vice versa. So it's kind of like a one-way, one-way street from a navigation standpoint.

F

Anyway, I was just going to throw this out there as an idea that something we could consider that might make the uh interaction within the repo a little bit nicer.

F

uh Alex is gonna, try and evaluate this in the collector repo, uh and if it works out well there, uh then maybe we can adopt it and maybe there's some sort of like shared GitHub actions that we could use uh between all the various different repos.

E

Yeah I'd like to see what the collector comes up with yeah.

D

The repository with some kind of like shared structure of uh GitHub work, workflows.

F

Oh really yeah.

F

Sorry, could you point uh point me to where that is I'll.

D

Try to find it I think it is one of his personal reports, but I'll.

C

D

I'll post it here.

C

F

um Another thing that I was going to ask I have on a branch somewhere that I haven't checked in uh a couple of changes that I was just going to throw out there and see if uh y'all think would be useful um in the original datadog repo.

F

We had this feature uh this flag, that, during the the um Gradle build you could disable the shadow relocate uh so that you could create a build that was much easier for debugging purposes, um so that was one uh and then the other one uh was a a Gradle flag that you could disable uh to uh the job, the version numbering so that way when it published when it built locally, it was always the same uh file output, uh much easier to to reference.

F

Do those sound like uh VR builds a PR um changes that I should push to the the repo that y'all would y'all think would be useful.

H

I think so, I'm pretty sure they're rules already in a an issue about uh skipping shot, skipping package, relocations.

B

F

Cool I'll uh I'll go ahead and submit PRS for both of those.

C

F

C

Jump in with my next issue: if that's- if this is a good time, um I guess I can share, my screen probably makes sense to have something to look at.

C

Is that the correct window? Okay, um let's see so.

H

C

Issue and there's this repo, so this I was uh looking at some old issues and you know we're in the process of trying to donate our Android instrumentation to open Telemetry clients, work and, as part of that, I found this uh pretty old issue, which was like hey.

C

We could build a rapper for hurl and we I mean we have this volley instrumentation now and I think that I think the limitation was that uh there was some Android build stuff that didn't make sense to try and work out in the job, instrumentation repo and all the only reason I'm. Bringing this up is because I'm wondering what we should do with it.

C

We can either you know, leave this issue open or we could say I mean I could just make a note that this will probably be included in the in the donation in some form, uh just wondering what folks think we should do about it.

C

D

C

I, don't know I, don't care, that's also fine.

D

I think we could either include it in the donation or uh put it into the contributable because, like with all the build problems involved with uh yeah plugin I'm, not sure if putting this into like the instrumentation report is a good idea.

C

Yeah and it's I mean I guess it remains to be seen if we'll have a contrib repo for mobile, like for Android but yeah yeah. That might also be an option.

C

I think it probably does make sense to have it in the main repo as part of the instrumentation offerings, the the main repo being sorry, the what will eventually be the Android repo yeah.

D

The main Android yeah, okay.

B

C

Right, okay, this.

B

Is if, if this hurl stack stuff, which you know I wrote this issue and I used to know what this crap meant, but I don't know anymore. um If it's only an Android library, then it makes sense to put it in the mobile like in whatever the Android mobile instrumentation. Repo is I, think it is yeah.

D

It's exclusively Android yeah.

E

Based off the package name, it is that is that Library published as part of the you know. The Android toolkit.

B

I think this is a third party thing, I believe, but.

E

Maybe I could just com.android.

B

I, don't know, maybe maybe I'm wrong yeah.

D

Isn't there the Google library I think it is so it's kind of like semi-part off it's okay at.

C

C

E

A

C

Must be part of it.

E

My point was: was just gonna, be that um you know, hopefully, if that is kind of a strong ties to the Android ecosystem it could it wouldn't have to go into like a mobile control repository. It could just go into the the main mobile repository wherever that ends up being yeah I.

C

Think I agree with that: yep, okay! Well, I won't belabor it that's uh just wanted to mention it since I've been thinking about it.

E

What's the status of that donation, how what were you at with the process? Oh.

C

We're still ripping out all this Splunk stuff and trying to make a separation so that we can still have a working distro. But.

H

You know it's never.

E

Been closer, all right, thanks, yeah!

E

Well, next up is Bruno. uh This is most likely continuing the conversation from last week about the OK HTTP dependency of the otlp exporters.

E

G

What are your thoughts on this Bruno, so um I? Really thinking about the picture of the project and um nothing to considered um I, see two options to easily do this.

G

One is to use a multi-release jar to use the to continue to use the okhdp for pre uh Java 11. and after that we can use it in our jdk HTTP client, which is only available after 11.

G

um or we create. We need to create a an exporter on the side that can be used for Java, 11. and more, but we would need to to extract probably the common.

G

The common, uh the leaves sorry, the the classes inside the common lib that can be reused.

G

To a more independent module that doesn't depend directly on okay, http I. Imagine.

E

Yeah I'm a I'm, a fan of that approach. I've, given a little bit of thought to this, so there's kind of two versions of the otlp exporters. We have there's the grpc variants and the HTTP variants, and so uh last I checked it's not possible to do the grpc variant with the jdk HTTP client, because it doesn't support trailing headers. So we can't Implement that protocol, but I think it's perfectly suitable for the HTTP protobuf variant and I. Think we should do that.

E

It's been on my list and you know in my head, I was thinking about a multi-release jar which we've we've done in a couple of other places to take advantage of things that are available in later versions of java, so yeah I think we'd have to kind of flush out.

E

Some of the details of you know how that all works, but um you know I I see a future where we have uh a version of the otlp HTTP exporters which uses the jdk, HTTP client, and um you know, I- would hope that that would actually morph into our default recommendation for the otlp exporter over the grpc one that we use. Currently, um you know a zero dependency version of it is always going to be better than like a version that depends on okay HTTP.

E

So what we've recommended using the grpc one in the past I think that, should we should consider um you know you know, recommending the HTTP variant in the future.

E

It would be a good sort of uh encouragement, uh uh encourage users to upgrade to Java 11 plus it's it's been too long, javades quite old.

G

I don't know if anyone else has an opinion on this.

G

G

I guess um we'll need to to hack something.

E

If you want to so there's like a short term, so I'm gonna do the jdk version at some point. It's just like a matter of kind of where that slots in like it's, it's it's on my list of things to do.

E

If it's a high priority for you, you can work on that and you know I'd be glad to offer comments and try to work work with you to try to get that merged um if you're kind of in an even bigger hurry than that and can't kind of work on that in the in the short term.

E

Future, uh there's always the option of using the internal, um the internal serializers in the short term, to build your own HTTP, client um or you know, using Vertex or uh whatever you you were talking about just serialize the the bodies using the internal classes, to get you um to get you unblocked for the short term.

G

Yes, so we will need to fix this very quickly, because we have long-term releases of several products that are going to to go out and depend on uh open Telemetry, and we we cannot have that there, because it's almost unmaintainable because of kotlin.

G

E

Then there's like three options for you in the short term, there's, like you know, for your long-term release, use the grpc version and include uh the uh the you know, one of the Upstream grpc transports, like the like the one that's nutty based um so use that so that you don't have to use the OK HTTP dependency um or you know, help Fast, Track, This, jdk, HTTP, client implementation or build your own HTTP client um that uses vertex and you know, use the internal serializers.

H

You could also shade the code independency, so it wouldn't conflict with it, but send the application.

E

I think Bruno's uh I think what Bruno is saying is that you know old versions of of okay. Http have you know bugs or security uh vulnerabilities and newer versions depend on kotlin, uh and so you know, shading, okay, HTTP and its version of kotland uh seems like a big ask.

G

Yeah, because there can always, um we can always have another cve inside and we would need to to rebuild it to to in order to fix it.

G

um So it's it's it's it's a big risk on the long term, especially because one of our products has.

G

um A support period of years, so anything can happen in a couple of years.

G

Thank you, foreign I'll, give you a ping uh once I had to discuss this with other people, because we need some timelines as well and see what what we can do. I would prefer to work on the on the attacks putter here, because well it's it's uh always better and more people will use it and it's it will be more resilient, but um but let's see how it goes.

E

Right sounds good.

A

Would it actually be less of a problem if users were using kotlin just out of curiosity, because then they would update kotlin on their own.

G

Well, that's that creates yet another big problem, so for starters, most apps on Java, don't use kotlin the the ones that we know about here um for this particular application that we that I was talking about and even if they use kotlin.

G

um A particular version of the exporter will be tied to a kotlin version, and if people kill keep upgrading kotlin, there will be a point where they might have problems um between the versions that they are using and the one that was built that was used to build.

A

Api changed or what does the root cause.

G

Well, many things can change so uh I, don't know so.

A

What I'm, having in mind is that um if we could say that kotlin is provided, then we would take whatever the user is taking, and then we could say if you're a kotlin user, then you can use okay HTTP um under this abstraction that we have just talked about, and then this would give the user another possibility.

G

um The problem is not the user himself because they can use whatever they like and if it blows up well, it's their their their problem. But uh what I'm talking here is a product that is maintained by us and we need to make sure that all the dependents play ball and they work and making sure that this happens uh for kotlin.

G

uh Well, it's a big problem because most most of the apps don't use kotlin at all and would need to to build Captain from scratch ourselves to make sure that we can maintain the CVS for a very long time, because even kotlin won't maintain the their environment for the amount of time that these products live. Okay,.

F

So are there any? Is anyone aware of a back Port of the Java 11 HTTP client that works with uh Java 8.

C

Darn, no, do you think there is one.

F

I I'm not sure like yeah I would be surprised if there wasn't, but uh then again the the other option is uh maybe we should just try to uh consider. Switching to you know, HTTP URL connection as much as I hate that.

E

I I think we should I think we should try this jdk HTTP client with the multi-release um jar and see how far that gets us. um You know see how many users are left kind of that are stuck in a situation using Java 8 and have issues with the kotlin dependency and have issues with like okay HTTP, like that's, that's an increasingly small intersection in the Venn diagram uh and so I. Don't know you know if we can avoid having to use you know HTTP URL connection than I think we should.

H

How would you do that would like release charge? The char8 version still has dependency to okay, http.

E

A Java 8 version does.

H

So would you like me to make okay HTTP optional dependency and when you're on Java 8 manually, somehow added.

E

Yeah, it could be that you know we could tell users that it's a compile-only dependency and you have to you know, add a dependency on okay, HTTP yourself or the other way. We we provide like an implementation dependency of okay, HTTP, and you know, maybe, if you care about that, you can explicitly exclude that.

G

Yeah, that's probably the easiest way, because whoever has a problem with that can exclude it.

H

Yeah, it will be kind of strange that when you're running on Java 11, you don't need it, but still by default, get it.

E

Yeah, if and if enough, the users are on Java, 11, plus and Java 8 users are the minority, then maybe it would make more sense to have it, be a a compile, only dependency and provide additional instructions to say, like you know, if you're using Java 8 and you need the okay HTTP client, then you know you have to add your own dependency like this.

H

Maybe it will still make more sense to have two artifacts one with the okay HTTP and the other one with jdk.

E

G

Have also to take it taking mind that uh the multi-release uh jar doesn't so Java 8 doesn't know about that, so it, the default code, has to include the um okay http um dependency somehow, but it can be excluded on later versions. So if we build with Java 17, for example- um and we place the code under Java, 11.

G

folder and the Java level, it will pick up the classes there that are more recent, but for um Java 8 doesn't know about this schema. uh It will just use the default stuff.

G

So we need to keep that in mind, but.

E

Bruno, can you have a, can? You have a like a palm that varies for the Java 11 versus the Java 8 release.

C

E

Always includes like a dependency on OK HTTP, then.

G

We might need to do have some magic on the on the compiler plugin, at least on Maven uh I've. Seen that happening I, don't know what how it can be done on on cradle.

G

But the dependency has to be there and it exclude eventually on on whoever is using it.

G

And then include explicitly.

G

E

Kind of where my brain's at- and you know I mean we have a lot of work to do so. We can hash out the details, um but you know I would probably if I was writing this I would I would start with that and see where we bump into issues.

H

Yeah another question I have about motor release. Chart files is that, um like the jtk cluster support them, but two like other class loaders, also work with them. Foreign.

G

Only after Java 9.

E

Are you asking about like growl.

H

There is more meaning jar into Tomcat, a stormcat class of their handled correctly.

G

Oh that this this this is a Java feature, so the runtime knows about that. After Java 9.

H

Well, it could be nice to verify it before we attempt to use them.

E

E

E

Well, that's all that's on the agenda. Does anybody else have anything they want to talk about.

E

All right, then, we can end early thanks. Everyone see you next week. Thank you see you all right. Take care.