Open Telemetry Uncategorized, 9 Jan 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: 2023-01-09 meeting

Description

Open cncf-opentelemetry-meeting-3@cncf.io's Personal Meeting Room

A

Foreign and tell.

B

C

Happy New Year, Happy New.

D

A

Do we know who owns a calendar entry well I, just noticed that it doesn't have links to the any docs or anything so, which is what I use for finding things between.

C

I can update it thanks.

A

C

C

Oh, it's got it as like an attachment or something I had a link also.

B

C

uh I pinged Josh.

C

um Ted is there anything that you want to talk about today in case Josh doesn't make it.

E

um I think if we want to uh discuss more about the road map for semantic inventions, we could just briefly go over that and see if anyone has has input.

E

um I have a proposed timeline for like how we should uh how we should hit them. But you know.

C

That sounds good I know we have a couple of folks here that are very interested in the HTTP and messaging.

C

E

I actually have a question about that which is I. Think the HTTP working group disbanded The Village, you know, are people still meeting on that stuff or I.

F

Think we we gave up this band that yeah I think that nobody is training that meeting anymore. As far as I know,.

E

Okay, so maybe we can talk a bit about like how to reboot that effort, because I agree, it would be great to get that get that one done.

D

Yeah that will be great, actually I'm. Also interested in this uh I was out for a while, but it is still it is still a priority.

C

Or HTTP Ted I think we have a I think you had created a project on the board I'm.

E

I'm, looking I, don't.

B

E

Don't think I don't think we do have I, don't think we have one it's not on the project board currently and I'm. Looking in our issue backlog to see, if there's like a project tracking issue for it, oh.

F

We have a tab in um this group projects. Project 31 I can share. I can put the link in the chat yeah.

E

Could you share that yeah.

F

Of course, uh I will share my screen.

F

Okay, so this this is this working group and we have a list of issues, I think it's everything that Josh identified from that age, it's related to a http. Okay. We can try to go through this list.

C

Great or should we spend this time and kind of decide um who like how basically how to reboot that group, because it'll probably take a few weeks of going through these to make sure that we have and making sure that you know we set up the meeting. We have to tell your point about the two TC members.

E

Yes, yes yeah, so um a to-do item for this that I would recommend is to create a a project tracking issue. uh We need to just create one of these, um whoever, uh if we're gonna reboot this there needs to be like a Project Lead and the goal the project leads.

E

Is the person who's going to make sure that you know the meetings happen and the project issue stays up to date in the backlog and yada yada, um Dennis or Luke Miller I, don't know are either of you committed enough to this you'd like to to take on that role.

C

I can do the paper pushing also, if that helps. That's.

E

Great and I'm trying to not be the one who always.

C

Does yes, a lot of paper for us.

E

Great, so what I would suggest to to get this rolling is, if you go to um the spec repo and go to create an issue. There's an issue. Template called a project tracking issue, fill that out as much as it is fill out a bowl um and then uh create a new project board um for for that project for the HTTP project and move all of this stuff. That's in this project board over there so that we have a project board dedicated to that working.

A

E

Than having it all like mixed up, yeah I.

F

Think we already have one I think great. Remember the number number 20..

F

Oh! This is messaging I'm. Sorry 21., yes yeah! So we can move from this one great best part to here. Yeah.

E

Yeah get that one yeah just get this this thing Rebooted and um uh attached to that tracking issue, and then once we have that we can put it on the the project board, where we're tracking all the projects and and I will start poking the TC to um figure out who's going to join. It.

C

How do you find oh I, see I'm uh yeah.

F

I just pasted the link into the chat.

C

C

B

C

And there was the instrumentation stability working group that was where Joshua that was adding all of those before got it.

C

And so do we need a project tracking issue in the spec repo.

E

C

E

That fracking issue is where we keep track of.

E

You know the link to the project board, so we don't lose it and things like who's working on the project and then we're using those issues in our project board where we're tracking all the different projects. It's really helpful because from that project board you click on a project and you get all the information about the group who's who's doing what what are the deliverables when, when are the meeting times, etc, etc.

E

A

Don't feel like you.

E

Have to fill in everything in that template. You know just leave for stuff. If you don't know the answer to just like leave it um stock for now.

C

Cool and uh lidmilla Dennis um do you have a preference for time like keeping the same time as it was meeting before, or so we put out a like a doodle or something.

D

It was Tuesday 4pm, PST, probably yeah, that time works for me.

F

Should work for me too.

E

Yes, that was it was the um um the APAC uh instrumentation Sig ma is a meeting that still exists, though I kind of doubt anything is, is going on. There.

C

And then uh Ted, you said you would ping the TC.

E

Yes, I can I can ping the TC and say who, who wants to to work on this thing? um I I think you know I don't want to like block the group from starting. You know, but uh I do want to get that done, because that was part of why it turned into a slog. Last time was you know, the working group was doing a lot of work, but then it was like hard to actually get things pushed into the spec. So.

D

Yes, exactly actually that's something that I want also want to notice that we definitely need to have a support from TC from the very beginning, yeah.

A

D

So, since yeah we are going like in different directions. Otherwise, right.

E

Yeah we we can get started again, but we should presume that that's going to continue to be a slog until we get DC members assigned.

C

Yeah I'm guessing there's not a whole lot of appetite for starting up the group until we have the TC members assigned.

E

Totally I mean you could leave the meeting time. You know blank for now like if we don't want to start yet, um or at least make it clear that the group hasn't hasn't started working on this. Yet.

F

Yeah I wonder like the triage for some cons. Issues should happen on this meeting right so basically was a very little scope for the Tuesday meeting and all the triage happening here. It will be basically two meetings that would decide the future of HTTP semantic conventions, um and maybe it was Josh help here. We can work on things up there and bring it here for the final conclusion. We can try this as well.

E

Yeah I I'm a little uh con confused about this meeting. I. Think because, like there's like two levels to it, there's the level of like we have all these semantic conventions that we want to get through and we kind of have to organize how we're going to like eat the elephant, as you might say, um but then there's like actually doing the work to get HTTP stable, get database, stable, Etc and it kind of feels it feels to me like those need to be their own working groups.

E

And so, if we do spin up a working group to handle some area, then maybe we don't. We don't also I mean I guess we could also work on it in this working group. But it seems, like um you know, once there's a a working group then like they should they should kind of take over. At that point,.

F

Yeah right what I mean is, for example, the there are a few types of issues here, the first one. The first two are not common to http right then. This is all about metrics.

F

um We have a few very okay. This is also metrics, and we have a few probably minor things about the like HTTP specifically, and we either should focus on metrics in this new HTTP working group, and also this minor tiny corrections to the stuff we've already done right um or which we like. There is no point in continue and tracing Core Group uh alone. It should be General, HTTP, work group.

E

Right, so are the those more General issues. Are they not HTTP blockers? So much is Just semantic convention Lockers in general right. It's like some.

F

Of those yes yeah.

C

They would block all semantic convention stabilities, okay,.

E

Maybe we should pull those out into their own list or or maybe just rename this column like blockers for semantic com, stability and just pull the HTTP stuff into our new. Our new project list.

F

Okay, yeah good point: uh I will not touch it for now, but uh is there a volunteer to both issues around.

C

Yeah I can I. I can do that for the is get the HTTP one up and running.

F

Perfect and then maybe then you can rename this column, then too yeah more General thing. If you don't mind the desk yeah.

C

Thank you, yep.

D

uh One great question for me to to get to up to date um so do we want to, but from now on, to work on HTTP conventions, both for traces and metrics, or we still want to treat them separately independently to kind of bring Trace many conventions only to stable, States or like what is the plan for now?.

F

I believe there is a very few HTTP tracing semantic convention issues and uh I. Think a big part of stabilizing is to make sure that metrics Works in my opinion, would be that you need to group that that owns both and mostly focuses on metrics, because this is where the most of the issues are foreign.

D

All this stuff, because we want to kind of expand this goal for now.

E

I think Dennis. What you're saying is um we want to do all this work and that that working group should do both tracing.

A

And metrics but.

E

But are we in a place where we could, if there's just a tiny bit of work left on tracing, could we like get that done and declare tracing stable and then and then get the metric stuff done? Is that I think that's what you're yeah.

D

That's exactly what I wanted to ask like: do we want to bring tracing conventions to stable first, since it's it is really close right, but not to expand the scope and wait until we've done everything from metric, so we can kind of stabilize all of them at once.

E

Why don't we get that working group spun up and then like, like sit down and just like, have a like just like review the backlog and figure out? What's actually what's actually in there.

C

Yeah I think we could. You know uh the HTTP working group could propose to move tracing to stable first um and see what, if there's any general objection to that um in general, they from previous discussions I think the the thought was would want metrics to be maybe thought out enough that we're not going to create problems with metrics, where we want certain things to align. We want certain.

C

um We want the attributes to be more or less the same across tracing and metrics.

C

But if we do that kind of exercise in the HTTP working group and say, okay, we don't think this is going to pin Us in on metrics in any bad ways, we could propose to move tracing to stable on its own.

D

Yep, that's how it sounds good to me. Maybe we can spend uh one or two uh sync UPS, just to figure that out yeah and build a plan, but definitely at that point probably we need to have a confirmation from TC members that everyone is is fine with it with that approach in that direction, and then we basically can.

C

Yeah, let's kind of press it. Let's bring that specific topic up um back to this working group uh next time for Josh, because I think he's thought about this and I think that would be this working groups um decision if they want to um only move things to stable at the same time or allow the working group's flexibility.

E

Because this is definitely going to come up in every working group right in general, the tracing conventions are like farther along than the metrics ones. So it's a good question.

E

I would at least like to understand what about the metrics conventions would would get like what would get screwed up like what are the dangers? It's like not clear to me why there would be a problem to stabilize tracing before looking at metrics, but you know just because I can't see a problem doesn't mean there. Isn't one so it'd be good to understand that.

C

One example that was brought up previously was like the status code, should status code, be maybe a string so that it could be like 4xx and lower cardinality, um not that there was appetite for that, but just as sort of a a example of how metrics and cardinality could possibly affect tracing attributes.

C

If we wanted them to be the same, so I think in the case we discussed there was the idea was that should just be a different attribute than tracing attribute of um status code. Category.

C

But I like the I, like the the not blocking it on metrics uh I, like the idea of proposing that at least see if we can um make make people come up with a reason why we shouldn't do that. uh Yeah.

E

Because the additive um additive changes are backward backwards compatible, you know so.

C

What's uh one of Josh's open I, don't remember what came of that on the metric side if additive changes are Backward Compatible, oh.

E

I'm sorry I meant for tracing. Oh.

C

E

F

um Well, I think we have an issue somewhere and it's not for HTTP, it's a general one that we need to Define. What is backwards compatible because adding can you required attribute is not Backward Compatible, so we need to Define it, and this is a bigger blocker than any of the HTTP specific issues.

C

That would be yeah, so that's a good topic for this group, and probably anything that is blocking like that. We could move over to this new blockers column yeah. Once we remove HTTP from it, yeah.

F

Should we have another column, oh okay, so yeah this one will become the blockers one for anything. Yes, yeah.

E

Defining backwards compatibility seems like a reasonable proposal, so I'm behind it.

D

But what One backwards compatibility will be like a can be solved with a schema version.

E

Right right, we've kind of said that in general, which is like I, agree with it, but it is also a little hand wavy right so.

F

So the schema versions are also I think follow September right, so the breaking changes are like, for example, if you had a new recorded attribute, then you cannot list the schema transformation populate the information that was not provided before right. So in this way it cannot be solve this version colon or at least we're staying with the same major potion.

D

That's right, so, basically, that's that's mostly about like do. We want to increase schema version by adding a new features, new attributes or being Backward Compatible within the same yeah, but that's. It will be probably a good topic for the work group, not only for HTTP work group but overall yeah many conventions.

E

B

E

I'm, pretty sure Josh has a lot of thoughts on this, so wait wait until he gets back before you tackle it.

C

Well, I think that's a good step forward, um so we should be able to get that stuff um in place before the next. Our next bi-weekly meeting here um I'll work on I'll, get the uh the http board up and or tracking issue up and running so that we can um try to pin down a a couple of TC members on that.

E

Great, thank you yeah once I have that once I have uh send me a ping me on slack once you got that set up sure I'll put it in the right places and throw it at the TC.

D

Thank you, so trust will be the next meeting of that group. This Tuesday.

C

No, let's give it at least uh uh I would say it won't be until um we get TC members on board, um but so maybe, if we're lucky, we might meet next week.

D

Okay sounds good: let's, let's look forward.

C

Yeah cool I definitely keep you posted.

D

Great. Thank you very much.

C

Was there anything else that anybody specifically wanted to chat about in this meeting today, yeah.

F

I had a topic I wanted to ask group opinion, Upon Our TFC. What does the general guidance it's regarding messaging semantic conventions and what we'd like to do there? We would like to extract a per specific per messaging system sections into their own files, um like, for example,.

F

Here we would have a folder for messaging and we would have links to specific sections to the zoom in okay. Is it good, okay, yeah cool? So then, uh what we're thinking about that uh yeah, the specific messaging systems will be in individual files and like the main concern here, is that they may reach the ability at different moments in time, and we want to have a status per document, uh especially I.

F

Think Kafka and rabbit is something that we want to include into the messaging stability, but rock it and cure any other messaging system that will show up after will not like can never reach stability. We don't know whatever it even is stability for such conventions and I. Think the group has some thoughts on where this documents should even leave. Should they be owned by open, Telemetry or not, um but I wanted to get your folks opinion and see if what we do in other semantic conventions, because it's it's a general concern.

E

Yeah so I think it's related to the question of where does the instrumentation live and who's, maintaining it uh the semantic conventions, we're writing or for the purposes of of our instrumentation and then, if someone else writes instrumentation, we want them to follow ours, but if we have to write instrumentation for these systems, we want to write our semantic conventions down to make sure that you know they're the same for like the clients and all the different languages.

E

So I think that's when it comes to some of these things like rocketdb or whatever, that I'm not even sure what that is. But if, if we don't have instrumentation for that stuff, when we're not planning on writing it, then maybe we don't need to write down the conventions for it. Well,.

F

They are already there right. Basically, the question is: if we can.

C

F

Yeah at least while we don't just well, maybe we should have a specification country report. They should go there without a very little uh supervision right, but for now, uh if we want to stabilize things and if we want to refactor them, maybe we should split those up and say: okay, this is not our responsibility and the status could be different on those and yeah.

E

Well, we we have instrumentation for these things right, that's that's! The thing we have is that.

B

What you're saying to ask yes.

E

Right so since we have instrumentation for it, then I think it goes in our spec and but I think it's fine to to have those broken out and still be say experimental.

E

You know, rather than declaring them stable, along with everything else. If, if there's like a concern that we we didn't, if we're concerned that we didn't like necessarily do the world's greatest job, but you know specking them out and we want review of them before we stabilize them.

E

You could still call them experimental, but.

A

E

Should still be in the spec, because you.

F

Know, yeah and I think it's more like a refactoring part of the work, so uh they what is this proposal? They still live in the spec. It's just a different file in the same folder, where they are defined.

E

That makes a lot of sense to me, um and that makes it a lot easier to be clear about the um the the status of stable versus experimental I. Think yeah.

C

I, like that, um that's very confusing a couple places where there's they're, like the the status is mixed um in some parts of the page are stable in some are not.

F

Yeah and then maybe if uh somebody on messaging working group would uh continue they suffered I think it should be done uh across uh all the specs, where we have massive uh different systems- databases messaging fast, maybe something else. Yeah.

E

Okay, something I had wanted to do but kind of shelf because it turned out to be more of a hairball than I thought. It would be because we auto-generate a lot of this stuff was reorganizing the conventions in general to right now, they're split out.

E

It's like metrics tracing resources and it seems like they're, a lot easier to it'd, be a lot easier to have HTTP and tracing in metrics and log logging conventions for HTTP all in one place, and you know all of the Kafka conventions all in one place, rather than buried in three different folder structures.

E

But I I looked at that, but I was afraid to touch it because I'm not really familiar with, like the the the code.

B

That auto generates.

E

These things, and also like, would that would I be like breaking anybody's stuff that pulls off of it. But.

F

B

F

It makes sense uh we'll try it I, don't think it's it's something urgent that people would do, because the stability is still far away, but yeah I just wanted to know. If, if we had any plans for something like this in the future, yeah, yes.

E

Yes, I I think this should be our, but this should be our pattern like everywhere, like we have our generic conventions for that domain, like database conventions and then for every specific database. It should be its own separate file uh in that folder, rather than all like smushed into one one big file, uh because it's it makes it hard. For example, if I look to even know what we have conventions for, if it's all buried within one file, so I think it's a good proposal.

F

Awesome. Thank you.

C

Anything else that anybody wanted to bring up specifically today.

F

Somebody added a fast working group on the agenda.

E

Yeah I I did oh okay, just just a heads up that um that group uh did get fully staffed and so they're um they're getting going. They still need another TC member they've got one, but just I just was bringing it as a heads up, because I wasn't expecting us to deal with fast until later, but it turned out.

E

There was a big appetite because we have a lot of people using Lambda and it's like a little painful right now, apparently so um just letting people know um and I'll try to let the people in that group know about this. One I think I'm just slightly concerned, they're like off in a corner so I'm trying to solve the off from the corner problem a little bit.

C

um Yeah, that's a good idea to like if at least one person from each of the semantic convention working groups can attend this meeting also yeah.

E

I'm gonna go to their kickoff meeting, which is uh tomorrow, I think yeah. They meet at noon Pacific tomorrow, it's on the calendar, but but I'll I'll bring that up at that. That meeting and I'll kind of let them know apologize.

C

Is that around semantic conventions or.

E

C

E

Mix right because.

A

E

There's like the semantic conventions for functions as a service, need to get fleshed out and stabilized and I know they're planning on tackling that. But then there's a bunch of like Lambda specific implementation, junk uh that they have to they have to dig into so so it's like kind of a mix of stuff but I I do want to. Let them know for the semantic convention stuff to kind of important coordinate with us cool.

E

um If we don't have anything else, uh I could just show this like conventions timeline. uh Maybe just get some feedback from people. uh If that's cool.

C

E

E

Here's a link to the doc and I'll share my screen, so this this document here is just trying to put a road map together for like how we're gonna tackle these conventions. uh I've shown this before so I'll skip over it. The first part here just explains our project management thing in general, which is what we're already doing we're, including tracking issues and stuff um for actually tackling these conventions, because we have a lot of them.

E

um I was proposing that we take three quarters to do it. The first quarter is to just like prepare the working group, and if that takes less than a quarter to do that's cool but um The Experience. My experience so far is like trying to get subject matter experts to participate. They usually have to go back to their the organization. They work for and get permission, and that means they have to wait till their next like planning cycle before they can start.

E

So if we want to get like SQL experts or something from Microsoft and other organizations, there's usually like some lead time um to kind of get our ducks in a row. That's at least been my experience. I wouldn't want to block a group, that's like ready to go, but uh it does feel like. If we're gonna have a good group, we need to First spend some time.

E

You know trying to organize everyone into it and that might take a little bit of time. So that's my experience then actually trying to like get these specifications like hashed out our experience so far as it's like ungodly, slow, it's like just been super super slow and we have so many conventions. I'm concerned it's gonna take like 10 years or something crazy to to actually get through them. All I don't think it has to. But it would be great if, when that group met I've been saying like.

A

If, in a single.

E

Quarter, we could get through all the work of stabilizing a semantic convention and I'm curious. What people think about about this proposal so like the group would get together and they would have like six weeks to like say we're gonna figure out databases or at least SQL databases.

E

That group would get together with TC members attached and they would have six weeks to prepare all of their proposals whatever it is um and then submit them to the public, and we would have like four weeks of like public review and then, if there aren't any blockers, we get them integrated into the spec and we have like two weeks to get that done. So that would be like three months start to.

E

You know, start to finish, like the working group kicks off and then three months later we have stability for that section, I'm curious what people think if they think this is realistic um or not, does anyone have any thoughts about this.

C

I think meeting several times a week is key um to make that kind of accelerated timeline work uh yeah and that will can always be tricky with time zones and busy schedules.

C

Yeah yeah also will depend a lot on the the complexity of the item. Like there's no way messaging, it could Coulda Coulda could do this.

F

And anyways the Head Start uh for two years, I think we can finish it.

B

F

I think that the problem I always telling messaging, is that, first of all, if this working group is Forum plus the people who know the area and up and telemetry, then it's it's feasible. But if there are key members like subject matter, experts who don't know the area or if there are a lot of people who are not familiar with open Telemetry, uh then uh it becomes challenging yeah.

E

I think that's sort of what I was thinking about by having this lead time for like working group, prep is I kind of because we're gonna run out of TC members. You know, and so it feels like we shouldn't kick these working groups off unless they seem like they're staffed for success like if we have some people interested, but it feels a little lopsided that we should actually hold.

A

E

On trying to tackle that that area I don't want to block things, but it seems like we. We should wait until we feel like. We have a group that has the right mix of stuff and has like the time available to actually dig into.

B

E

Or things will just be kind of like Get smeared out over a year or two and I don't know I I feel like I might be overthinking it just because messaging and the client rum stuff we're like big enough domains that they actually hit real. Like structural issues within open Telemetry, it wasn't just semantic conventions. It was like. Oh, we have to go write the logging API now and things like that and I. Don't know if, like the other conventions, are going to run into similar issues or if they're more of a straight shot,.

E

And anyways just a thing to to think about, um and then the the third stage is one that I. Don't think. We've done any organizing around this yet because we also haven't stabilized anything yet successfully. But but when we do, we need to like update all of our instrumentation and I'm a little worried that if we don't, if we, if we don't have like an organized way to do that, like um things will be just kind of uneven.

E

uh In particular, it seems, like you know, there's in some languages like Java there's like a lot of instrumentation maintainership and it's like kind of centrally organized, but in other languages. There's these big contribute pose that with a maintainership is a little more dubious and I I feel like as a as a group. We kind of need to figure out like what's like.

E

How do we like keep track of that and kind of stay on top of it, because it's not helpful to stabilize the semantic conventions if, if the instrumentation itself is all out of date,.

F

Assuming Korea like scenes, the implementation happens after they are declared stable. It sounds uh impossible to solve any problems that we might arise during implementation and, if we should have, maybe uh we have a frozen status. Maybe the semantic conventions should be frozen after stage two is completed and can become stable after at least some reasonable effort in stage three I understand that postponed stability, but I guess the stuff. The the timeline is not our goal. Our goal is quality.

E

Great yeah that that makes sense like a kind of release, candidate phase yeah. We definitely need to have prototypes when we're speccing this out. Like that's the lesson we've totally learned is we need to be actively working on at least some instrumentation uh to figure out what the issues are, and you know in the past, for, like other spec work, we tend to say, like um prototypes in a couple different languages that look different from each other, but I. Think with like these semantic conventions like we can do that and still miss things.

E

For example, with http um a thing that popped up was around like signed requests that ended up affecting right where we were saying, retries should have new span IDs, but then it turned out signed requests like can't. Can't actually do that because of the way they incorporate the headers into the signature, um and that's not a thing. You would catch just by modeling, a couple HTTP libraries in different languages right.

E

You had to pick something like the AWS API to to find that so I totally agree with you that we could pick a couple of prototypes and still miss something critical.

E

D

E

Go ahead, yeah.

D

I'm, sorry that one there I think yeah, basically I wanted to say that last time was HTTP. It was uh probably the decision not only to get with the prototypes, but for like an actual implementation for at least three languages, so I I believe we decided on that match Java and Biden that time yeah uh but yeah. It actually I, really like the proposal from Miller bets. uh Once we are ready to actually go and implement, we can announce the or Mark these signing conventions as Frozen.

D

So basically people aware that no new changes are coming and it's it's only. A verification State when we are actually like I, want to confirm that everything that we wanted to do is actually visible. Yeah.

E

B

D

Yeah, it probably will be a really good addition to the whole process and you know bring people some. um You know confidence that everything goes in the right way.

E

Right so we would version the conventions at that point when they became Frozen right we'd, add it you'll get a new schema version number and then, if no further changes happen after we've implemented, then we would change that to stable and we wouldn't need to issue a new version number that makes sense just.

A

The thing I'm, the.

E

Thing I'm worried about, though, is like we don't. There is no like organized group of people to actually go update. The instrumentation and I I think this is just like a it's like a kind of like a broader issue.

E

I think we have to work out with with the different language maintainers is that we have like language maintainers but they're, mostly like SDK maintainers, and they don't have enough bandwidth to maintain all of the instrumentation, and so so it's just it's just this other aspect of this work is like I think when we start trying to do this, we're going to discover this issue in different languages of like how do you actually update this instrumentation or like even know what instrumentation needs to be updated right.

B

D

uh I remember last time, last year, actually little Mueller had a great proposal on that as well. uh It was kind of it, looks like it can be automatically or kind of you know technically solved, and if you have a kind of framework or a platform which will allow us to kind of verify the the current implementation and gains uh any kind of semantic conventions version right, it will be and actually something that we probably need to have anyway.

D

Just because we need to know what is the current status of uh a particular platform, language system or SDK against a a specific version of semantic conventions. Yeah, and that's something that we can just probably do within this word group just to have a verification framework or something.

E

Yeah that would be super cool, um yeah I would love it if we had something that verified what that, rather than us, like writing down somewhere in a dock that we have to keep up to date. You know if the um the tests for each Library spat out, you know a yaml file or something we could Hoover up to no, what semantic conventions each thing implemented and like what version number they were at.

E

That would be a good step towards being able to keep track of all of this stuff, but sorry go ahead. Go ahead. I.

F

Just wanted to say that uh the tooling well, it might be well, it's some effort right. We need some uh similar tests in each language and, yes, we can validate them. I, don't know on The Collector. We can build the plugin to collector. We can go and build one that would validate uh certain scenarios uh and say that okay, this this looks compliant right. It does not mean uh we cannot move without it right.

F

We can just have a table like similar to the feature metrics, but for each spec right um and we can at least make it explicit that uh certain Implement T instrumentation Library, cannot go stable until the changes are implemented for this version of stable semantic convention. For this thing right and then, if uh spec, rep or sorry contribute pointers, still some pressure from users. So if users want to contribute if they want to make stable, they know. Okay, this is not marked uh in this Matrix, so maybe I should contribute, or maybe I, shouldn't use.

F

This instrumentation yet uh like at least give this feedback to everyone in the process.

E

Yeah yeah I. Definitely don't want perfect to be the enemy of finishing.

E

um Maybe the thing we can use for this is the registry. We have like a.

B

Simple registry.

E

You know uh that's basically like a big markdown file on the website and maybe, as part of doing this work, we we get that thing up to date um and we could. We could modify that thing to you know include any flag or column that we want to be able to track this stuff. But if we do it there, then it's a resource that our end users can make use of as well.

E

So maybe that's the place to to do it and then, if, like at a later date, we can make that registry be updated from like test data or something rather than by hand and that's great, but we don't need to.

E

We don't need to build all that stuff to to get done.

F

Yeah and maybe uh like, we also have something similar for each uh signal, so I think each open, Telemetry repo has the stable with metrics logs and traces saying which state there on uh country. Repos can have something like this and we can go and initially contribute Alpha everywhere.

F

E

Cool well something to to chew over we're we're at it running out of time here, but yeah I just wanted to flag that as like this is this pile of work. We tend not to.

A

E

About when we're talking about stabilizing the conventions, so we we just need to be aware that this is like coming for us and it's like a different kind of work right, because it means going into different languages and updating a bunch of libraries um or working with the maintainers if they exist to update them. So so we should just be aware that we're gonna.

C

E

To figure out how to do that, yeah.

C

Who's, this do we need to staff, should the the first quarter Staffing take this into consideration.

E

I kind of think so I mean it's I I feel like I. Don't have a strong answer to this because I don't think it's realistic to say that we have people who can update everything in every single language right. That seems probably not feasible. No.

C

But we could ask for all the in ever list out all the languages and ask for somebody who would from those languages who would participate in stage three yeah.

E

F

E

I think smaller.

F

Process for metrics right, we can learn from them, but they've done.

E

Oh yeah that'd be helpful, but but.

A

E

Metrics, that's uh that's like the language maintainers, who are maintaining the SDK and like they're, all like those maintainers are like pretty organized but outside of like Java. The contribos are like much more diffuse and the language maintainers, don't necessarily um maintain those things or at any rate, it might be a lot of work to dump on the language maintainers to say: hey. You guys, go update these things, so we.

F

E

To figure it out.

F

I mean we can learn what was the criteria for making it stable and see where the gaps are and say. Okay, we are good in Java, while trust can make an assumptions for you uh and we may be good in python or JavaScript and just making things up. uh Is this enough? Okay, and we have a gap. I don't know. Can this aerial goal, for example? So how do we solve this problem? It's much a smaller problem to solve than just figure in everything. Now the criteria itself, yeah.

E

Foreign that was super helpful thanks for going through this with me. Everyone.

F

Thank you, yeah.

C

Thanks bye, yeah.

F

Thanks everyone.