Open Telemetry Uncategorized, 23 Feb 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: 2023-02-23 meeting

Description

Instrumentation: Messaging

A

B

B

C

C

uh Welcome everyone can y'all, hear me: okay, uh I think we're two minutes in, but it looks like we're getting pretty close to Quorum, so we could probably start here in just a little bit. If you haven't already, please add yourself to the attendees list and if you have topics you want to talk about, add them to the agenda, and we can just uh I think it's starting in about a minute.

C

David, are you on a business or personal vacation.

A

Personal vacation in my bedroom.

C

Oh nice, I was gonna, say um we don't have Crystal Palace on the call today. So I was a little concerned. Yeah.

B

Yeah, it's it's uh snowing a lot here, so I decided to be lazy and not go in.

C

Yeah, that's fair. We got about uh anywhere between like four to a full foot, four inches to like a foot of snow here in Portland as well, so which I'm sure to you uh on the east coast is closer to like you know five feet of snow because this entire town shuts down but.

A

I was gonna say that sounds like an actual amount of snow I.

C

Know right, I saw the Bay, Area was supposed to get snow and I was like wow. That is um that's interesting.

B

Yeah I'm a little scared I'm going up to the Bay Area in like two weeks so I'm like. uh Hopefully it's a little bit warmer because I'm contending with like 90 degree days right now,.

C

A

Man yeah. On the other hand, we got a lot of freezing rain last night, so all of my trees are drooping over. Some of my friends had trees that have come down.

C

Yeah, that's the scary one right because that's when you lose power, yeah.

A

Yeah yeah, thankfully I haven't lost power, but I've got a couple notifications, one yesterday that Verizon had power issues and another. Just now saying that there's power issues in my neighborhood.

B

So so you might be experiencing an arbor-pocalypse just like we did this past month, yeah.

A

Yes, it's been a good 12 years, since that's happened here in Buffalo, so we're doing.

C

uh Well, I, guess, with that, we should probably hurry through this before Anthony loses internet or power um I've.

A

Got ups for about 20 minutes, it'd be fine; okay, perfect.

C

uh Cool I'll start sharing my screen then, and we can jump into this um all right cool, so uh welcome. Everyone starts off uh Aaron. You have the first thing on the agenda. This is talking about a community ticket to bump the required test to 120.

B

uh Yeah um I just wanted to see if we have done that. Yet, if not um probably the beginning of next week, I can take it on yeah.

C

I think uh I haven't opened, it I, don't know if Anthony, if you have.

A

No I'm wondering if we can get up from under needing to do this, though, by setting up uh like in in The, Collector, contrib, they've, broken out unit tests and lenders into many jobs uh and then have a second job. That depends on all of those finishing. This one is actually required, and so they can change the jobs that that depends on and that's the requirements without needing to change the actual required checks.

C

It's in the collector contribute yeah, okay yeah. That sounds like a great idea like.

A

The build and test workflows is one um you'll see. There's like uh first sets up the environment, then there's a lit Matrix and a unit test Matrix, but those aren't the the ones that are required, as workflows like lint is and unit test is, which then depend on those Matrix jobs. Okay,.

C

Yeah I think that's a great idea. um There's a lot of great ideas coming from The Collector, uh including this concurrency thing. uh I, think that's, that's pretty helpful. I think we're defaulting pretty well right now, but this could probably get increased, so I think a little bit better uh yeah Aaron. What are your thoughts on looking into something like this.

B

um I don't know if I'll have Cycles to do that specifically, but I can definitely take the grunt work of of switching us to 120, so we can get rid of 118.

C

Yeah I think uh that sounds good. We like I, don't know if I have the Cycles either I'm like behind them like a lot of other things, um but maybe just an action item here to create a ticket to um to track that work and then maybe put it as like. I mean honestly. That's a good first issue ticket uh because it's just GitHub, docs and referencing, like um The Collector, does.

B

B

I mean for a long time, I've wanted to break out linting away from having to run it before running tests anyways, because the tests tend to have better information when you're actually developing but I mean that's a bigger.

C

Okay, I I can take a section, I, don't know.

C

Okay, cool, then your Aaron's gonna take that so one thing I did want to say, though, on this one though Aaron is that I would wait to open this until we have a release, uh because I wanted, like it's one thing to add the requirement for the 120, but I'd want to do the required like add to 120 and then remove the 118, but we'd want to remove support for 118. So I think we're going to do that in the next release.

C

um After the next release, so I mean you can add the 120, but like the 118 I think we still need required until we have. The next release is the only thing.

A

um So the next release would be the last one supporting 118.

C

Yes, yeah and then after like right after that, we could just take drop support for it. I mean that's our policy for versioning for the Upstream go.

B

So the community ticket just changes the required label on the test. Can we do that before the release as long as our tests are still passing.

C

uh I mean I: guess it's just going to require human um Consciousness that all the 118 tests pass right instead of it yeah button mechanisms.

A

Are better than intentions.

C

Yeah I'm glad you said that, because I'm thinking the same thing, not personally I I I could uh I could miss that.

A

C

Like also like the CI stuff like for um coverage can fail sometimes- and it's like I'll notice it, but it's not like you know, maybe there's also a 118, that's also failing so I I, don't know, I, don't have strong opinions but I, like the mechanism checks.

C

That being said, I hope that the next release is coming out soon enough, where that's not anything, going to be an issue yeah, um and on that note, uh let's talk about the metrics.

D

Just just one thing, because I'm not sure if I follow right now go want. 18 is no longer supported right.

C

It's no longer supported Upstream by the go team. Yeah. Currently the open television go. Project still supports it in this next release.

D

C

Okay, yeah the next the next release. After this, though, is not going to support, it um is the cycle there, yeah uh yeah again, like I, don't know if there's like the exact right policy, but this is what our policy is. So that's what we do yeah.

D

C

uh Okay, cool: let's talk a little bit about the metrics API, so we talked last week and we were pretty close to a release candidate. In fact, we were I went back and I looked at the entire metrics API, and one thing that kind of stuck out was this units package that we have um so I guess these look at this issue, so I created this issue to try to kind of track this. So one thing that kind of stood out to me that was like wrong. Is this concept of like milliseconds?

C

Is we have a unique like it's all the prefix and the unit are tied together right now. This is copied from open census, which is actually um a good statement about the stability or how far this can get.

C

You I think this can get you pretty far but I'm a little concerned at this point, because there's also talking specification to try to split this like right now, they're discussing whether they want the default to be seconds instead of milliseconds, um and so then that kind of brings up the question as to how does this package evolve uh going forward right? Do we just add an entire new, constant called seconds uh that lives besides milliseconds, it doesn't seem like a really great structure um to me to have prefixes tied to the the units.

C

I think that that's an underlying law in this design and one of the other problems that I was kind of noticing, is that, like this uh type definition with the unit, just wrapping a string, I think is really useful, but it also means that the unit can't ever be extended um because the you know you can't add another field to a string. It'll have to change its underlying type.

C

I, don't think, there's a strong reason to try to extend it too far because of uh after investigating this. If you try to extend it really far the comparability this needs to remain comparable and, like there's, There's a constraint here. The specification also really is pretty specific and saying that a unit is just an opaque string. So at some level it needs to.

C

It doesn't actually say like it's like a type definition needs to be declared as a string, but it does need to say, like you know, it needs to be treated that way and it needs to essentially be as close to an opaque string as possible. So you know if you try to change a unit to be this really complex structure. I think that you're diverging from the specification, but it also means that, like um I, think that you can tie the prefix I think a little bit better to this.

C

So there's a proposal here which I probably say, don't look at it's abandoned um because it involves I think extending the unit beyond what it should be extended to. So this is like a big problem that I was kind of. Having is uh when you do something like this, the principle and like say this is a property. This is a really kind of um token things that you could about it. They become comparable as well.

C

So if you create a new um unit- and that unit is, you know, say a second, but it has a print symbol and one and a not a principle in another they're, technically different units, uh which is not what a user really wants.

C

I think under the hood, so I try to there's like a thin line here between what the ucum, which is the underlying standards, definition for like what we're trying to implement and what open, telemetry, Define and so I was looking at this for a while and thinking about, probably too much, um but it ended up coming up with this proposal. I ended up just marking this as ready for review right before I came here.

C

I did want to walk through this, because this is not a really accurate representation of how much this is changing, so don't be too scared. um This includes a standards definition from the ucum, that's all XML, so there's like yeah there's like 2 000 lines of like XML in here that I am not expecting to be reviewed. uh It's more of I mean you can go verify that I copied it correctly, but it's just coming from Upstream.

C

uh So I just wanted to like kind of point that out to start, uh but then one of the other cool things is like. So this is. This is the actual proposal uh that I I have put forward and that's restructuring the unit to just be this uh prefix and code, so it wraps the prefix and wraps the code. So this means that like seconds will be different from milliseconds, uh because it'll have a prefix which I think is a useful thing as it as it needs to be.

C

But it also means that if you try to create um seconds with, you know the correct uh ucum case, sensitive code, which is kind of important, because if you do create it with the case insensitive code, it will be a different unit. um But anyways I don't know how to fix that because that's like, unless we switch open television entirely to vacations instead of code I, don't know, there's a way to fix it.

C

um So it does distinguish that it ties prefixes into like this separate entity, so they're still comparable. So you can compare milliseconds to milliseconds and seconds to seconds um and so I think. If there's this, like also, you can compare whether it's it's one or the other, um and it has a base unit.

C

That's similar, there's a marshalling um one of the nice things is that there's a prefix uh set up here and the setup for the prefixes just like these are functions that you're going to pass a unit to and they're going to return back a unit so again like the decouples.

C

The unit from the prefix is kind of the goal here uh and then I think that the nicer thing also was that I tied this to generating it so I, don't actually I, don't intend this to be a curated Set, uh specifically because there's this is the thing that you could evaluate like I mean there's, there's a lot going on in the specification, um and you know this is kind of opaque, but there's just things in here that are like you don't actually need, but it's also nice to have us that you could generate it.

C

All repeatedly uh is the goal so there's also. This also includes generation codes. It does uh generate a subset more like. Currently, we only have technically, second and byte uh technically Billy. Second year but I added bit Hertz Watts volts in degrees celsius as well, just because I expect these are going to be used in a Technology Center uh setting. It's really easy to add more units, you just add their name here, um and they just run the generation code.

C

It's really easy to remove these as well. If we decide like, we really don't want to add um any of these as well. So I think that there's there's some value in this generation just because it takes a lot of the user error out of it, and it makes sure that, like the ucum standard is actually used, um yeah and then the rest of this PR is just uh it's really easy, like updates like. Instead of this, is no longer a string, so you need to you know, pass a string fears underlying um inversions.

C

This is how, like you, would look at a milliseconds in the new standard, so I think it's a better API, but I was hoping to get some feedback on it, because I do think that this is something that's going to block the metrics. Ga uh the units API I, think, is something that needed to get done so I'll just pause here, see if there's any feedback.

B

um So I might have missed this, but uh where does the ucum requirement come from? Is that actually, in our specification.

A

B

It is okay, but.

C

uh Yeah, it is it's, it's not obvious, it's not in the API or SDK specifications down in the otlp um side of things and then there's a trans yeah. It's a transfer protocol, yeah.

B

Okay, um the other thought that I have is: is there any way we can have some of the common ones? Can we have the ones that we want to, or that are clearly defined like millisecond, uh follow something similar to the time um millisecond, where there is a defined variable? That is, that the millisecond that could be underlying built by the millisecond code, but people can reach for that one, as that will probably be a common occurrence.

C

So I didn't want to do that because that ties prefixes to a unit. um You know it's really easy to say like milliseconds is the standard, but it's really also easy to say that microseconds or nanoseconds is a standard.

C

um It's you know, and then you start to get into that slippery slope of, like you know just EXO seconds make sense to also have as a as a unified thing and.

B

I would be fine if it was just the ones that are specifically mentioned within the specification which I believe are milliseconds, maybe seconds and bytes.

C

Yeah, so that's changing as well right, uh so then you're then you're, going after a moving, Target and and you've started to allow this like subjective idea of. Do we add prefixes for ones that are in the specification and what happens to the specification changes, because then we can't like remove that right, like that's, got to be forward supported so by decoupling, it and having it. This has a function, argument um and a function, return, I, think I, don't know it seems it seemed like lower overhead for the long term.

C

It also seemed like you, get rid of the combinatorial expansion issue, because you know okay, so yeah like you do that for milliseconds. But why not? Aren't you doing that for bytes?

C

um And you know, then, when somebody comes to you- and he says like well actually, like I, think I think that bites are great but I want uh you know, megabytes or megabytes, or something like that like defined as well like there's, really not a line to say, yeah we're going to just Define those as well and all of a sudden. You have like two or three different ways to actually reference a unit. At that point, you know: does a user use the function, Milli wrapped with a second or do they use?

C

The underlying uh you know result that we've stored as a variable as well and I think that, having a single way to do that helps clarify that I also, don't know if it's really that much of an overhead to just call the function um is how I looked at it.

D

Personally, I'm not concerned about things like milliseconds and things like that are More Concept about non-standard units like minutes like hours months, which are you know, cannot be created. You know you know.

C

Because our standards actually in the ucum and.

D

Okay, so we'll have them as well right.

C

D

But then we do not want to have like kilo days right so.

C

They that runs into an interesting problem, because those are called non-metric units and non-metric units are not allowed to be prefixed in the ucum, and uh that is something that I was thinking about in this API is. Do we want to restrict that here? uh You know, I, don't think so. I think that.

D

C

D

Sorry for my question.

C

No, no, it's a good question because, like Fahrenheit is also a good one right like why do we have Celsius in that Fahrenheit I.

A

Don't think this white is non-metric, you can't have a millibyte.

C

uh No bite bites of bytes isometric, actually I I I I'd have to double check that, but like um no, that one I'm pretty sure actually is the the definition of metric in the Ecom is a little bit um weird I. Guess, let's see yeah bite and bit are both metrics uh bod is a metric, but uh something that's measurable right. A bit per second is well, it is something that's on the it's actually something. That's on the ratio.

C

Scale and historically comes from uh the European uh I, don't know Zeitgeist of metric I guess you could say um because it's it's. It is somewhat of a cultural phenomenon. How you describe this, in fact, uh a lot of these other metrics are either called arbitrary, so they're, something that are just annotations around the dimensionless or they're special and they wrap uh already prefix, metrics or other base units into um standardized units, or something like that so like parts per million is a is a is a non-metric definition of a unit as well.

C

um So like yeah I mean that's, that's a it's. A fair question, Fahrenheit is is one since it is not on a ratio scale. It actually has um you know the conversion between Kelvin to Fahrenheit is non-linear, and so therefore, like you can't actually prefix it based on these prefixes, there's, there's a whole class. Sorry like I definitely went down the rabbit hole so I've like there's a lot out here.

C

I could say on this one, but like yeah, that's a problem like uh because currently right now, the only thing included metrics are base metrics or metric metrics, I'm, sorry I'm, using the wrong terms, base units or metric units right and all of these are allowed to be prefixed um and the moment that we do add something that isn't allowed to be prefixed like syntactically. You can still pre-fix it.

C

uh It wouldn't be valid ucum, but I also I'm like well at what point do you just say like the user has to be able to like know what they should do and if they want to provide bad data, then that's kind of up to them. I've, no problem in fixing this, like I, think that we could still fix it going forward, but it becomes a you know. Usually at this point.

C

In the conversation, people start tuning out as well, because it's units- and nobody cares um but like I I, don't know, like that's a really tough question to answer. um But I do think that there are ways that we could differentiate between metric and non-metric units and.

D

Like the only problem like solving this in future, if that, if someone will use it now, and it will work then in some future release, if we are, if you decide to not allow such construct, it will simply break. We could say that it's a fix, but you know this is just a well.

C

Yeah I'm quite aware: that's why, like I'm, looking at an API redesign.

D

C

And this is where I'm landing into that camp of just saying that, like providing the ability for a user to provide a string which, on on the hotel side, is what it needs to be done right like you need to provide some sort of opaque string and providing like the um algebraic properties of the ucum and trying to find like the spectrum between those two things. I.

C

It's it's a dance right like because you can, you can get really detailed under the ECM and, like that's kind of where I started was like, you could provide a print symbol.

C

You could provide like the case insensitive as well into the unit and like how do you combine them like there's actual operations and like you can look in like different types like they can be combined so like a prefix with a a non-metric right like there's a lot of things that you can do here, but like I'm, looking for like the simplest, but at the same time also like uh hits the important points and I think you know at its core. It needs to provide some sort of, like you know, an opaque string.

C

Interface for the user and needs to be comparable and it needs to distinguish between uh prefix and a unit, because otherwise, if you tie those two together, you're going to have these combinatorial like expansion issues and you're going to have you know, uh I, don't know 30 different definitions per unit, because you're trying to comprehend like comprehensively Define each unit with each prefix that could be combined with it.

C

uh Yeah, this is probably the point where everyone stopped paying attention. um Okay, so I yeah I mean these are all interesting points and like I've, definitely like it's. It's a tough one. So I would appreciate a review on the pr uh I think that it's it's a step in the right direction, um but yeah I think we can probably just leave it there.

C

I do want to say, though, that it is going to be kind of important, because it would change the metric, API and I want to make sure that we're we're doing that before the RC, so this would be blocking DRC, uh so yeah I think it's I think it's worth taking a look. I also think it's a worth, taking a look as a just a practice for everybody on the call like to go.

C

Look at the metrics API, uh everything in that package or anything in the sub packages as well like and making sure that, like we don't have any other like well-known things that we want to address or change beforehand.

C

C

uh Cool next up, I wanted to talk a little bit about the metrics SDK beta I, know, um internet and Anthony uh and I have talked a little bit about this asynchronously, um but it we're also done with this. As far as I can tell, is there anything else somebody knows about that needs to be included in the metrics SDK beta.

C

Okay, save a lot of no's, uh so this project could probably get closed in fact, and then we could start if we need to including uh items into the metrics SDK uh GA project I think is, is the next one.

C

It also means that this is ready for a release so that we can also uh state that the metrics signal is in beta.

C

uh Let's see, maybe that's also a good question as to like: where are we foreign.

C

Package is the only thing blocking the metrics um Milestone, the 114.

C

uh That's a good thing. We should probably talk about. This still needs one more review. It's slated to. uh No it doesn't. It doesn't.

B

Mean I just started the checks before the meeting. So unless something came back.

C

uh Stupid coverage yeah.

B

C

One yeah all right so yeah this looks almost done, uh we'll call it done post a post meeting and then the schema is also done. So literally. The only thing we're waiting on is just a review of this um metrics API, and then we should be ready for an RC for the metrics, um uh potentially an RC for the metrics API. Unless people find things after this meeting and then the Beta release for the metrics SDK.

C

uh Okay, cool that actually is really great news. We're moving right along uh cool, then there's two other PRS I wanted to talk about, but maybe I'll just pause here see. If there's anything else, people want to talk about at a high level of the metric signal.

C

Okay, uh well, the next thing on here is Aaron opened this issue around uh reducing memories in the pipeline. um One of the top level questions Aaron I wanted to ask you is what project does this belong to.

B

I I think technically. This is like post GA, because I don't think this does any changes but I had the code ready to go so might as well put it out for review at this point.

C

All right, yeah, I, agree, I, yeah I, don't think it means it should be excluded from review. I just wanted to like make sure it's not in the uh beta for sure, um and not the Milestone, okay cool, then I. Think that sounds good. We'll include that there anything else you want to talk about here. Aaron.

B

um I probably should have put this in the uh with notes, but I believe it reduces um two allocations for every collect. That happens so not two allocations per um metric, but just the two global allocations.

C

Okay, yeah yeah, that's uh helpful. Did you get that from our Benchmark tests? Yeah, okay, cool uh I'm, saying four hex here: okay, I'll have to run that I'm interested in those numbers. It.

B

Goes It goes from five to four I think or six to four.

C

Okay, uh yeah that sounds great and yeah I'll. It's on my list of things, take a look at it, seven counter until yet so.

A

Speaking of memory usage, we do have a report of a memory leak coming from a user um in 112.. It's the second one on the list there 31.65 or 37.65. I've asked for some paper off data to try to help debug, um but I don't know if this should block us from releasing or if we want to just mark this as we'll address it. When we have the ability to address it,.

C

Yeah I um I obviously saw this as well, but I I agree like this is a it's concerning, but it's also like I. There's, really no actionable information in this issue right now other than um creating something that I think we I I say actionable like trying to reproduce. This is going to be quite hard. uh We should maybe try to run this over the time frame, so this is like over I guess like a day three days here, um something that does uh um some sort of health check.

C

Every I think it's five minutes is what it said here to try to reproduce their five seconds yeah, so I I think that we could try to reproduce that, but outside of that, like I, think that your question is exactly where I was headed with. This is like I need to see the P Prof or some sort of like memory allocation, because there's no way to show right now that this is coming from the hotel, SDK or or.

D

An example program, whatever.

C

Yeah yeah or or the API or if it's coming from the user code as well like there there's a lot of things that are unknown at this point,.

A

No all right well I, just added it to the ga project for SDK, then, um if we don't think we need to hold up on a beta for this.

C

Yeah I uh I'm a little hesitant to hold up on the beta like I I, mean I. Guess they say that they're really only doing upgrades here to the hotel, I, don't know if there's any other changes included, um but yeah I I'd be interested to know I'm. Also, like you know, I look at this and I say like okay. This is actually like. You know. Rounding off. This is almost looking. Is this a logarithmic, or is this asymptotically like approaching some sort of limit right, I, yeah I? Don't it's!

C

It's really I'd have to investigate this with some sort of, like I, think example, program to try to figure that.

A

Because, like if this.

C

Is just like uh GC thrash or if this is just some sort of like memory, cache loading like there's so many things that this could be I, don't know um how this how this you know I would really want to know if this eventually goes to like an out of memory. Error like that. That's a critical error, um but yeah until I get underneath like understanding like what it is. It's really hard to make a deterministic understanding of like how severe this is, but yeah it's important to bring up thanks for bringing it out.

C

uh Okay, cool yeah I mean I'm subscribed. So hey you know uh tune in next week. Hopefully, I have some more information: uh okay, cool, so yeah, I uh Anthony! Are you okay with not blocking the beta on this yeah.

A

Yeah I just wanted to make sure we were all on the same page about that. Okay, cool yeah sounds good.

C

To me, okay, Robert I also added uh your PR here for hotel, metrics um export interval and hotel metrics export timeout uh PR. Here. If you wanted to talk a little bit about this.

D

Though I think the only thing that sort of mentioning is that I also created a second period, an issue connected with it, because basically, the parsing and the code are responsible for for like reading the environmental variables uh is in a few places, so I created a separate issue to address the refactoring.

D

uh Yes, it is, but I didn't want. I first wanted to create something like I, don't know. If, what's your preference simply I discovered it during implementation, didn't want to put too much think into one PR, because I thought that it will be too much.

C

Yeah, so I've uh been somewhat following this and I think this issue makes a lot of sense uh because, like you say, there's uh three probably more places um that do environment, parsing and they're very similar and have overlap. uh You know, abstracting, that to a central place, internal to the project, I think is a good idea. The order of operations is the thing that I would uh I'm interested in your thoughts on, though I I think this is a prerequisite for those other PRS is what I'm I'm. Seeing from this.

C

Is that how you think about it? Could you repeat please so I think that you should have this done before those other PRS are I.

D

Can do it if you prefer for me it's anyway, I can do it just afterwards. It.

C

Just seemed like Damien was asking uh for fixes here um and so I think.

D

But he was proposing putting it in SDK interval and which I think it's wrong anyway.

D

So that's I propose to keep it like uh like side by side and then left the refactor into one place, because I think that Demon's proposal is not also not correct, so whatever I'm. Finally, for both this piece already, you know prepared and ready to review.

C

Yeah right, like that's, why I'm asking uh you know I'm asking because it's like you're gonna, add one more place. You have to change it in the in the APR, where you refactor it, but it's up to you I mean that's what I'm asking should people be reviewing this or do you want to go the other way and have them review the environment PR that you could open.

D

I think that reviewing this PR as they are here are easier to review and then I can refactor it also because uh by reviewing them it will be like I think you in my opinion, would be easier. But if anyone disagree you can block and the request changes. I work simply you know and I would do it. I will also create a PR for refactoring tomorrow and I can resolve the conflicts later. So whatever you know, works better for you, I will be.

C

I'm just telling you how I would do it, but that is I that is completely subjective in how I operate so I I'm, just asking I'm happy to review this first as well. So, okay.

D

Yeah I just didn't want. This is ready. You know the refactoring I cannot do soon and then then you know tomorrow your morning because it's you know it's late for me. So you can repeat today. That's it. Okay,.

C

Okay, cool um then yeah I will also try to get this on the agenda for review today. uh Just kind of a heads up on this one like this is used across all the otlp exporters. Right or sorry, um this is the the readers right: okay, yeah, okay, cool.

A

uh So I think one thing that comes up looking at the 3766 is that we have existing code in SDK internal AV for dealing with variables that are related to the SDK um I. Think Robert's, proposing moving that up to Oto internal end, which makes it part of the API package, I'm not sure, is appropriate.

A

C

C

That's a that's a good point, so it does. It does move it up to the top, but it also is an internal package. So it's not exposed to users or end users right.

C

uh So the problem Anthony I'm open like what do you think about trying to get it to work for exporters as well, because the exporters also have their own um environment. Variable parsing right.

A

They do there's configuration that can happen through the environment.

C

A

And that's all I can.

C

Fix with the hotel right, if.

A

There are helpers for dealing with environment variables that should live in the top level package. That may be fine, but I think what exists or the bulk of what it is in SDK internal end should not because.

C

It is internal.

A

C

Yeah no I I, agree, I. Think so. Robert meant to clarify this a little bit, because I didn't think that this would include SDK specific. This is more generalized functions where, like you'd, ask for a string, give it a default value and then the keys aren't prefixed with any sort of SDK specific thing right. This is just general environment variables.

D

Like uh this is like the set of the environmental variables like like, we have, for example, in otlp, when you can have several Keys, which Define, for example, an end point, and it will just use. Do you know uh like the based on the priorities which will it will? You know populate what's first here, I do not understand the.

C

So I yeah, so let me so yeah I got that so like this is where you could pass in like an otlb endpoint or the otlp like metric endpoint, and one needs to take preference over the other yeah. So that's why this is very attic, but it's you would pass in a key that is Hotel underscore oclp underscore endpoint.

D

Right, yes, I want to also pass here. I want to pass the key I do not want to pad put the list of the Enviro of the keys inside this package. Yeah.

C

Okay, so yeah I think Anthony I, think they're just helper functions.

D

Yes, these are just hurtful factors. I do not want to put the keys of the of the SD case Etc in this package. I think it will be not cohesive and it will be just you know, a big ball of much package so.

B

This proposal is just moving the like int end or function, but yeah in a different way.

D

Exactly and just making sure it's not copy pasted in different places, which is right now done.

A

All right, yeah, I, think I need to see the pr that makes sense to.

D

Me yeah I think it will be easier.

C

Yeah, okay, yeah.

D

So like this isn't.

C

Being moved, but this would be.

D

No, no okay, exactly things like that: okay,.

C

uh Okay, yeah, that sounds like we have understanding there. uh Okay, next up Aaron, you have fixed pieces, you have collector and contrib.

B

Yeah um there's three instances where collect is called directly in test and contrib. um This is a contrib one. uh This will prob. This will block contrib being released once the new version gets released. So.

A

C

Should be in the beta SDK, then right.

B

uh Yes, I believe so: okay.

C

Thanks yeah I Milestone don't go across repos, but you know the project. Okay, uh actually do we have a milestone, yeah sure, whatever needs to be done, uh cool.

D

Yeah basically retailer, like my issue, didn't have any Milestone project. I, don't know if you want to put it or not so.

C

It I added uh this.

D

C

I, don't yeah I, probably wouldn't add it. I'll. Definitely add it once um if it gets merged before we I don't want to block the current release on this being done so I'm not going to add to the Milestone and then the related PR here I did I thought I added this to a milestone uh yeah to the post GA at least so uh project, not a milestone because again, like I did, if it gets merged, I'll add to a milestone, but otherwise so.

D

Probably both could be positive.

C

uh Yeah I think you're right if this isn't uh yeah sure good point.

C

C

Okay, cool um pause here see if anybody has anything else, they want to talk about.

C

Okay, any uh cool open slums for uses in the past uh week, it's been a week. It's been a fast week.

C

Robert anything in the.net world that we should know about.

D

I'm not sure, if you you should know there, there is a new table version of SDK and API of the SDK coming probably tomorrow, and we'll also create a new version of the auto instrumentation. So and we know that more and more users are using Dot and out instrumentation, because people are asking on wrong channels on slack about questions.

D

So we see usage and we have issues because, if, like a few months ago, uh even not many people know about how to instrumentation.net. Now we see that there is a quite a traffic. So that's exciting for us, but now I'm more focused here on go.

A

C

That's a good point. We do have the auto instrumentation project here and go as well that we're so slowly working on again one of the things I'm behind on responding to but yeah I think. That's, that's cool to see people starting to use it.

C

Well, cool um I think, if that's the case, we could probably end it here. It's 15 minutes in time to go, review things and catch up thanks everyone for joining. We will uh see you all next week or asynchronously uh online. All right, bye,.