Open Telemetry Uncategorized, 10 Nov 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: 2022-11-10 meeting

Description

Instrumentation: Messaging

A

B

C

How's it going.

B

Oh man, it is going.

B

A

Yeah, hello, howdy.

B

Long time no see.

D

I, don't know I, know and and get this I was at Coop, calling what no yeah it.

A

D

Make it any of the hotel stuff.

B

I'm, like I.

D

Didn't see you there, it's interesting to go. I was looking through the uh the flicker photo set for the contributors Summit this morning, which I was in attendance, and it was interesting to see how many people I saw in the photos that I never saw in person. Foreign event.

C

I think that was um The, Shocker I, think I saw pictures from uh the EU kubecon and I realized that Anthony is probably like seven feet tall or something like that.

C

Yes, we were sending next to a bunch of other short really contributors if I haven't met, also as well so but yeah I was just like it's just like and then like I've definitely met other contributors in person and just like it's so funny, because we're all the same height in the video but, like you get to the university just like. Oh man, people are wildly different heights. Yeah yeah.

D

There's shocking things in three dimensions that we don't get here.

C

C

Okay, um I think we probably have corn. We could probably get started here if you haven't already. uh Please add yourself to the attendees list. If you have anything you want to talk about, uh please add us to the agenda. It's pretty Tyler heavy right now um and I'll start sharing. My screen.

E

Wow, okay, um Okay.

C

Cool, so just heads up I am out next week: um I, don't think I'll be at the Thursday meeting. I, don't I'm trying to remember my schedule, but I, don't think that's gonna happen so also just anticipate I think a lower level of involvement um uh or none uh yeah. It depends on the Wi-Fi situation, enjoy.

B

The week off, yeah.

C

Yeah yeah, that being said, also um I, don't know if everyone has access to the maintainers calendar, but um we are going into I, think the holiday period uh with Thanksgiving coming up later on this month and then um Christmas and the New Years and other country uh holidays. um So yeah I think that if we could just try to like uh keep that I think up to date would be helpful. I do also anticipate just um involvement to kind of slow down, which it always does this time of year.

C

So just stands up: okay um cool. The first thing I wanted to talk about was uh next metrics API non-compliance. So this is kind of a big one. um I was looking at if you have an open project to GA the API and so I was reading the specification a little bit and I found a few issues here um which are uh pretty important to resolve. So we can be compliant with the specification, but also I. Think that there's like uh some some bigger uh I, don't know.

C

There's a lot of work and I wanted to try to prioritize this um So. Currently, one of the things I'll just kind of go through them uh is that the API uh for the asynchronous instruments does not allow you to specify a callback during its Creation. In fact, the options that we have for synchronous instruments, as well as asynchronous instruments, are the exact same um and I think this is really important point, because this breaks the Symmetry between the synchronous and the asynchronous.

C

uh There needs to be another option or there needs to be some other mechanism. I guess it doesn't have to be an option, but um there needs to be some mechanisms to actually specify a callback during the creation of these um uh instruments, so that was a big one that came out.

C

Another one was for the current way that we do actually specify the registration of a callback. You also need to be able to unregister, uh given the fact that if you have a meter, if it accepts the registration, it needs to be able to turn off that registration.

C

um So I was looking at the Java implementation. I put in some suggestions here. uh I do think the registered callback method itself could be improved as well. So one of the things that I thought was, you know be really easy to just do what Java does, and so, when you register it, you get some sort of like unregister um is what I called it here, where you can call that and it would just unregister it. You know in the tracing API. We also have like this unregistered callback uh or unregistered span.

C

Processor, I, actually, I, don't know if we still have it, we used to have it, um but the hard part is definitely going to be. The fact that go does not have a comparison ability of functions without going deep into the reflect uh package so like having the this return. Something is going to be really I think advantageous, because otherwise you have to keep track of this coupling and this kind of just pushes it onto the user. So I think this is probably the direction we want to go.

C

um I also said: maybe we want to call it registration uh as a return value with a cancel function. Just in case we wanted to add methods to this registration in the future. I, don't know like it. This matches the go naming scheme. This seems for identifying I, don't have strong feelings there, but one of the other things that I did also pull from java. Was this idea of structuring the call Signature?

C

Instead of passing the function and some sort of slice of asynchronous attributes, you would pass the function um and then you need to pass at least one instrument which is a requirement. Otherwise it I don't know why you're registering this like you have to pass some sort of instrument, but then uh having additional instruments be very attic. I think was kind of a cool idea uh and changes um some sort of function called.

C

It looks like this with some sort of slice wrapping existing instruments to just being something that looks like this, um uh so I'll pause to see, Steve's got his hand up yeah.

D

I I understand that the technique, because it's always annoying where you don't want to mislead people and make it seem like I'll, accept any number, including zero. One thing this doesn't work well with, though, is the um sort of ellipses Splat operator or whatever you want to call it like. If you so say that you assemble a slice of uh of arguments and then you want to you know, dump them all into your command.

D

um Go does not accept that you need to manually pluck off the first one past that as a distinguished argument, and then you can pass the rest in you see what I mean yeah I do yeah I'm missing all of the correct spec level terms for um for those things, but I think you get the gist yeah.

C

I know you're talking about.

F

Pretty sure splat's the technical term.

D

That's enough to argue against it. I've done this in my own code, a few times where, as the author of the of the function or the method, I think ah this is the right thing to do, and I turn around and I become the caller somewhere else in my program and I'm going. Why doesn't this work? Oh yeah, that's right! It's.

C

Yeah right because then that would just mean that, like um if you do have some sort of slice, you'd have to do like uh I, don't like all the sea back. But then you do like. You know some slice, the first element and then uh s like uh I, don't know one on yeah yeah. That is.

D

Right yeah, yeah, yeah.

F

D

Yeah um that way.

F

You're feeling.

D

Kind of like a compiler laughs like why does it figure this out, but yeah I.

C

Always feel like a compiler, um oh man, GitHub, it's just not rendering things lately.

E

C

E

C

Yeah I think that's probably a good reason to not do this, I mean I, don't know what other people's opinions are. I do think that just changing this to being a very attic also helps reduce this um boilerplate of having to wrap things here, um and it would support this a little bit more natively and then, if you return, if you give zero like it could return an error or it could I, don't know like I. Think there's that's minor honestly.

C

uh This issue is definitely more around the unregistered side of things um and I think that that's kind of the key thing here uh that I wanted to focus on, but yeah thanks Steven for pointing that out, like that's good, to know that maybe they'll cut on that road.

F

um Yeah I would strongly prefer the straight variatic approach in returning an error if they give zero as well yeah. The one thing that stands out to me here is: if you, if we go back to the last issue, we were just talking about, though, needing to do this at instrument creation time. How do you get the unregister out of that.

C

You don't it. There is no way the specification talks a little bit about this and says that if you register it at creation time, there's there's no way to unregister. It.

B

um I'd also like to go back. uh This was discussed at least once before. uh When we first landed the API I know we had a community agreement or we had at least some level of community agreement to uh go with the API that we chose so far um and I don't think the spec has changed in regards to these the statement uh so I know we have different assortment of people. We could choose a different thing at this point. uh There is a cost to that.

B

There are people using the API as it is so I want to be very clear that we need to have a both a good reason to change it, but not that it's not 100 uh set in stone.

C

Well, I mean I, yeah I mean I'm open to other interpretations, but like I, this is direct from the spec and the API to construct your synchronous instruments must accept the following parameters. So this is one of the parameters. We don't accept it. So we're not confused right.

F

We accept zero callback functions, that's compliant.

C

F

It says zero, zero or more, and we accept zero.

C

D

We don't accept or more that's not how I read. I yeah I appreciate these.

B

We took some licenses to vary from the spec because go interpret like creating these things and go, makes it a little complicated and also in go. They very much recommend, there's one way of doing things. This introduces like either or ways of doing things, and um it's not very go-like to do that. So yeah we're not compliant with the spec, but you can do everything you is ask for in the spec.

B

By doing the other form, that's.

C

True, that's where we landed all right, I I, don't know if I agree with that anymore. If that was something I was agreeing to then like I, don't think that you can create an instrument and pass a callback in which you can do in other languages.

B

But you can create an instrument and the Callback that you need.

C

Yeah and then registered after the fact, but the thing is like the specification says, there's two ways: you need to be able to support both of them like they're, the requirements, they're, not recommendations.

C

um You know like I I get it if they're like you, can choose one but like I, I didn't read it that way, so I think that we need to be able to support. Both is my my issue here um so I. If you have uh different interpretations, I'd appreciate it.

C

If you can comment in the issue, um we need to get some clarity on this, though I I do think that we're not ready to release a stable, API given I, don't think we are compliant with open summary right now, um but I'm happy to have a discussion about it. Anthony I did I did also want to say, like this is I think where that sense, I was going to go.

C

Look for it after the fact, but I think this is where it says that like functions can be permanently registered or they're going to be permanently and I just interpreted permanently, as when you pass it at the startup. That's how it's it's recognized. If that makes sense.

F

C

F

Values permanently.

C

Yeah I know right: I do think it's under specified what that actually means, but I'm.

D

Wondering what is the antonym there that they're guarding against like it would work? It would be bound for a few seconds and then it wouldn't be anymore. Oh.

C

No, it's it's! What Anthony was saying so when there's no way to unregister yeah, you can't unregister it yeah so like. If you go this other route here, where you use this register callback method on the meter, you should be able to unregister it, but if you create an instrument with callbacks there's, it's permanent here means that there's no way to unregister that callback in the future time.

D

Okay, and does that mean that we would be non-compliant if there were a way to remove them? That.

C

I, don't think is the case because of the non you do. Anthony.

F

I I yeah I mean this says permanently registered, so if there were a way to make that not permanent, that would be non-compliant.

C

F

C

Yeah yeah well I think that uh strengthens the argument for not having some unregistered method here, um because then you could potentially pass it in and we could you know an implementation could misuse that, but yeah I mean I. Think that's that's fair, um yeah, I! Think! If you, if you allow them register, you may be not a compliant, then you.

D

Could you could create two flavors of registration, or one of them gives you nothing back with what you've got to register.

C

It, oh yeah, that's what it does. Yeah yeah! No, and that's that's what I would recommend um this is all culminating. I did have a work in progress to actually Implement that no Steve. That's like exactly what I think I was envisioning. Maybe maybe it needs to be a little clearer. um What that actually looks like, um but oh.

E

C

um Sorry this is hard to scroll through.

C

Yeah so there's a um you know the way I saw it was that there's just an option.

C

um You know with callback and then, since you're passing a function in with the Callback, that's going to go into like being an observable like it's just there's no way to unregister this callback, because there's no method for it is what I would say on that one. If that makes sense, Stephen.

D

Sorry, muted I was thinking at first uh one thing, I've seen in in other interfaces like this is you could pass in some kind of a token that you create? You know like, be it a string that gets associated with it that you could feed back in later. You know you pass XYZ there later you can unregister with the string XYZ. The difficulty is nothing then stops you from using the same cookie token, whatever you want to call it for multiple registrations, that's ambiguous! What should happen.

C

And that's that's why I really like this thing that I picked up from the job implementation? Where there's no like you, don't need to give me anything because I'm going to give you back the method that you just call, it's just a function and you yeah. You know the association, because you call you you gave the call site and you got the response, like you know exactly the association how you want to track. That is entirely up to you.

C

It also limits you to not I mean you can't pass in a function to register that you've already registered then get the unregister like it would just be a duplicate registration and that duplicate would get unregistered right so like the original would still exist right.

C

um So yeah I, don't know, I think if that's a positive approach there, but um okay, so the other thing that I noticed is that we don't actually follow the naming recommendation um like I think this is again something we recognize, but I don't like the issue here is that I'm noticing that there's a highly recommended first off this recommended is NOT capitalized, which uh just a nitpick.

C

um It annoys me, um but it essentially is saying that it's highly recommended implementations use the name of the verbal counter as a verbal cage up down counter um and some sort of language Affair like uh specific way to do that.

C

We currently call things asynchronous or a uh async in 64 as a package name prefix, but we all call them counters or gauges or up down counters I, don't know if we don't like I, don't see any good reason why we are not following this naming guideline um and given it's a recommendation, I think there needs to be some sort of compatibility or uh like if we were stable reason, but I don't see a good reason.

C

Why we're not following this naming guideline, and it just seems like we're not compliant without that reasoning and I guess this is more of a question to the group is like what was the reasoning here.

F

Okay, um recall they're being any specific reason other than that we had already been using async and it doesn't seem to matter um like it. I I find the the observable X kind of nomenclature, a bit odd, anyways.

C

I mean I think that's the answer to a lot of these um issues that I'm finding is I I find especially the next one um that you know similar to this registration thing like the specification is under specified in many ways, but it's also over specified and I think that this is one of those situations. That's over specified the problem that I'm.

C

Having, though, is that like this group needs to conform to the specification, so we either need to go in and we need to change the specification or we need to change our implementation is, is the issue that I have yes to you? Yeah.

D

Do I see that they nod here about the language idiomatic variation business, it seems to me like what they should instead prescribe. Is that there's some sort of a dictionary provided with each SDK or API, like you, read about the abstract notion of let's say an asynchronous up down counter, and then it says in this API. That's called whatever, because this is pushing, even if it they're mangling the case and putting an underscore in there's still different languages have different conventions for say how verbose they would be.

D

These look very much to me, like uh Java style names, for example, that you.

E

D

Expect to find in like a rust program, you know, so it is overly prescriptive.

C

I I agree, like I, think it's overly prescriptive, um but I also see their point in the discoverability like you're saying, like you're, recommending that there's a dictionary that could do some sort of translation. It says like go look here and we could have something that looks like a well-structured go program but also uh conforms, but the thing is I. Think at their point here is that you want the discoverability to be a part of the naming.

C

So if you're already, you know taking a python application and trying to you know duplicate it and go or something like that, you know that the name of an observable counter is going to be observable counter and I. Think that's that's the problem that they're trying to solve here is that you're not going to go looking for something that's called async.

C

uh You know N64 counter or or even the Asics 64 package like I, think that's what they're trying to address here is that, like, um if you name it consistently across the project, then you actually are able to translate between one language and the other like I I'm, not commenting on the um correctness of that I guess, I guess: I'm! Just commenting on the fact that I think that's what the motivation was uh for for this specification language at least.

C

um Okay, so I think that that's an issue we need to resolve as well for the specification, but this is I, think the big one um and this one I think I wanted I've thought a lot about So.

C

Currently, the open system specification states that there must not be an API for creating a counter other than a meter similar for asynchronous counters histograms, like synchronous, gauges, Uptown counters, async or something counters, and we provide like four different apis for this, and these are all these instrument provider apis that are not in the specification and like I, don't know like API is not a really well defined term.

C

So, like you, have to kind of go back to how the specifications using the term and I don't think that we're living up to the the spirit of what the API specification is is trying to stay here in that we do have additional apis and these providers that are the source of actual instruments.

C

um But I, don't know like it's a little bit nebulous, but it's also again I. Don't know why it's so specified because at the end of the day, you're producing the same thing. But I I just wanted to raise this one because it explicitly says you you are required to not have an additional API and we do.

F

With that, API is through the meter. What's that that API is through the meter, you can't get an instrument without a meter.

C

uh Well, kinda right because you can get one.

E

C

From the meter and then you can create as many of those instruments as you want from that API.

C

Like I think this is like the key here is that they're saying that the meter is the source of all of these creation points, not another API.

C

um And so I I, maybe we need clarification on it, but I definitely think that the way this is written, it's a creation operation and it has to come from the meter and so I. Don't think that we're in line with that either from having these instrument providers.

C

That being said, I don't think that this pattern is so I did build a prototype on on how we could resolve this, and our SDK implementation can still absolutely use an instrument provider under the under the hood and it does um to solve all of our like uh generics or abstracting. But I think that the API itself needs to be constructed when one were.

C

The meter is the creation of all these instruments and I think you can still solve that through our API being moved by our SDK still being abstracted and simplified through an instrument reminder code. If that makes.

F

Sense, I think, though, that that puts us back in the pattern that we were trying to move away from, which is a top level API package that has a pile of functions that doesn't guide the user.

C

I mean I I agree, um but I also think that our current implementation is not compliant with the specification is my problem and I think it's that it's the specification is really stating that we should have been sticking with that original pattern is uh on this.

C

The second read that I'm having of the specification and which you know then leads to the question of like how can we better document or structure that that design to help users understand it, but I I I, don't know if we can say that we can provide these like instrument, provider topics um and still move forward.

F

I also note here: they're called asynchronous counters asynchronous gauges, no observable here.

C

uh Yeah I mean that is true. It's also a little odd that in each of these sections, they're called asynchronous counters and then the instrument name specifically are called up to the observable counters. So the yeah I mean the specification is not consistent, I think in its language either um I think that comes from historical reasons, but I I, don't I, don't know I, don't know, uh but yeah I do think that's funny as well.

C

um Yeah because, like here they use the instrument name, and here they use the conceptual concept of an asynchronous of that kind or which the instrument name would be observable up down counter, but maybe that's too verbose, um so I don't know. um I did want to raise these, though, because like these are problematic, because I don't think we can go ga without resolving them, uh so I put them in the schedule or in the agenda here to reason to address them. I created this work in progress.

C

It's a PR I would be surprised if you want to take a look at it. It's it's pretty massive and there's not a lot of really good high level description in this conversation. Yet I was hoping to get it done this morning, but I'm working on other things, um but I would like to lay it out. I think this. This is a proposal.

C

um It addresses all of these issues, if I, if I, think it's correct, although like this one I think we probably need to iterate on a little bit better. um It has something like this, but, as we kind of pointed out, this may not be our approach. uh I do think that it's. The thing I wanted to know is like the scope of changes that are needed, so this is like uh 1200 lines uh plus or minus so really closer to like I, don't know two thousand lines of code.

C

If you think about the minuses as much as the pluses is something you need to review, and it's uh feature complete in the sense that it passes tests, it doesn't actually do the unregistered thing in the SDK.

C

Yet that is like a to-do that I left off, but I just kind of wanted to like show that, like we this this, does it exactly like you're, saying Anthony it moves back to having a top level single um source for all of the instruments in the meter, uh with just a function that returns them and having each instrument be a part of the package itself.

C

uh So I don't know it's a bounded estimate, though, is I I. Don't think, I'd probably submit this for review, given this size, um but I think that the point I wanted to kind of like call out, is like break down.

C

What this is actually doing is seeing if we could try to iterate on the parts or the components of this and and refactor it so, um but the key thing is: there's probably going to need to be, like you know: 3 000 lines of code uh plus and minus uh that need to be merged to resolve this.

C

So just like timeline wise, like we're, probably looking at like uh another month or two, depending on the uh review cycles, that we're actually going to see here was kind of my goal to get an estimate on that um I mean it also is a proposal like I.

C

Do think I want to try to clean this up and have you all look at the API and see if we can iterate on the API, but I think that there's ways to break this apart, where it's not just a 1200 line um additions that you need to review either.

C

Let's pause there really quick see if anybody else has some more comments. So that's pretty much my Spiel on the um metrics API, not compliance stuff.

E

Okay, um just one more thing from mind: this is like the first Sig meeting I'm joining Telemetry, so um the question I would like that and I just saw um fluid 64 and N64 um countdown stuff, like that. So do we really need to have separate for float, 64 and ends? You know considering that grona supports generics and stuff like that.

C

uh Yeah we do so. The goal for the API is to ensure um if somebody wants to write an SDK prior to go 118 that they could do so. We don't plan to uh we plan to write our SDK with support for go and 18 above currently, um and then that's a really release cycle, so we use generic Center SDK, but the API we tried to design without generics.

C

um That was the consensus before and I think it's still the consensus that we want to try to keep it that way. Our apis is generic Community or as um not language version specific as possible uh and so yeah. That's the reason. There's.

B

That's also the Practical consideration that you can't have a generic method on a non-generic type, so you can't have um counter that. Has that accepts an intern or a float on a meter that doesn't have uh enter a float? And if you do put it on the meter, then the meter could only produce in 64 uh instruments, uh regardless of uh which one you want to call. So there is practical considerations to that as well.

E

Okay, great thanks for the response.

C

That's also a good point, um and especially if this issue with the meter being the only place for instrument creation, can't exist, then we're really locked to that idea. So um yeah, that's a good point. That's.

F

A question that comes up occasionally, though, so maybe we should have an answer for that somewhere in the docs.

C

Yeah, that's a that's a good point. Anthony. Do you know of a good idea like maybe in our design like we don't I realize we also don't have a design deck? We have a contributing deck, but maybe we should split that into a design doc that would capture this.

F

um I would think, maybe just in the readme and godoc for the the meter package would be sufficient as well.

C

Yeah the thing is: is that I I don't know if users of the code would care, they just want to know how to use it, and that would show up in there. This is more of like a developer comment. I'm not opposed to that either though I just I'm thinking through it.

C

Yeah, okay, we.

B

Could have a contributing Doc in the the actual meter.

C

B

It's not a bad idea.

C

uh Even a readme right like in in that doc, uh although the readme shows up in the uh get a how the go package site but yeah I mean we could have a markdown file in there, there's nothing preventing that right.

C

uh Okay, yeah! But that's a good point: no you're, not the first one to ask that wisdom.

C

A

Other comments about.

C

C

Okay, um I'm hoping to maybe put some words to that work in progress and put it out there, but I. Think if you have time. Please comment on any of these issues. You wanted to uh question or have comments about so I. Think if that's useful, especially I, think that asynchronous instrument, one is like one where there could be some positive feedback on how we could handle that so uh I'd recommend. Looking into that.

C

The uh next two issues I have on the agenda are just carryovers. From last week. I wanted to follow up, I think I saw Aaron. uh Was he reviewed this instrument code path? I think this is after redoing. A lot of the um API like this is. This is.

E

Going to be really helpful.

C

um In cleaning this up, instead of having to change things in 12 different places, uh because you uh in that proposal, I have a fitness work in progress. I just essentially copied this, um so I'd highly recommend. If we can get this merge, be ideal and he's one other reviewer just calling it out um really appreciate it.

C

The proposal to replace the view, implementations, I talked I I, don't know if there's a there's, a huge spee between Riley and me, and here about um The Proposal. It sounded like uh if I might, if I could summarize and please others if they have different takeaways. From this conversation, it was essentially talking with Riley as one of the authors of the metrics SDK saying that uh you know, there's nothing in the specification that says give them that view proposal that we talked about in the last week's meeting this. This would completely be allowed.

C

um It's just a question of whether the maintainers want to move Beyond uh the you know how, if you add something that isn't specified, how comfortable are you with it not being introduced by a specification at a later time and conflicting with your implementation and I? Think that, given the um the structure of how this view proposal was put in place, we like kind of live in the best of both worlds. With that new view, still supporting the SDK I'm, sorry still supporting the specification, but still providing access to the underlying uh view, implementation.

C

One of the things that I found was really interesting, is that.net is a stable language with a stable, uh metrics implementation that has almost exact API. uh It turns out I didn't look at them for this inspiration, but like they do exactly this, where you can pass in um I think yeah I mean they could just look at this. This isn't the actual place it's defined as Riley pointed out, but this is eventually a public interface uh where you can pass in an instrument name and just a replacement name.

C

uh You can pass an instrument name with a bunch of stream configuration which looks very similar to our new view, except there's more matching criteria in New View. That is more compliant with the specification, and then they also allow you to just pass in a function which is entirely in line with what the view type would be. So I was uh happy to see that there's other languages that have that have done a similar implementation.

C

The question I wanted to ask, though, in the group here today, is how we want to move forward with this. uh It's been in review for 15 days now so I didn't know. If there's like there's six thumbs up, uh there's been a little bit of conversations. We talked back with the specification Anthony. You were the one that asked about the specification. How are you feeling about the response from Riley.

F

I think I'm. Okay, uh also, this came up in not this particular issue, but a similar issue came up in maintainers meeting on Monday um JavaScript was asking about Force flush on uh metric readers um and I.

F

Think the the consensus we kind of reached there in that discussion was that the API uh portions of it probably shouldn't be extended, but if the SDK wants to go above and beyond, what's specified as long as they're, careful and intentional about it and careful about during that they do it in ways that we don't expect to be stepped on by later spec. uh That's probably fine.

C

Yeah: okay, that's almost like exactly what Riley's response was: um okay, well, okay, cool! Then, if that's the case, I will uh like I'm off next week, so I, don't I. I definitely can commit to um opening PRS to make this view translation um the week after so I. Guess that would uh I guess that's the week of Thanksgiving, which is not a great week either, um but I will try to open PRS at that point. I will not. I will open my PRS at that point to try to move this forward.

C

If that's the um consensus of the group, if you have um concerns still I'm, definitely happy to to review the issue until then um so yeah, okay, cool, uh the last thing up is I, wanted to review the metrics SDK beta uh progress and just kind of go over highlight uh on this. This is um let me just pause here, though, and just in case somebody has another agenda item they wanted to talk about before we jump into this.

C

Okay, um all right so I wanted to talk a little bit about this. This is definitely going to be impacted by the uh API. If we need to change that, which is again, why I try to look at that proposal to understand the scope of how that would change. I do think that there are no open issues after I looked at it really quickly. Last week that would essentially be closed or invalidated.

C

um I think there may be some more work uh specifically around the unregistered uh work that we would need to do to support this I didn't include that in the work in progress for the metrics API refactor, um but I I mean otherwise it's like. That is a good point about all of these API changes like it stinks that it's something that's in a package, that's been out there for a while, but it also is a one-to-one functionality.

C

Mapping as it currently or an addition of functionality, so, like I, don't think that there's anything in our SDK that completely goes away or we need to be changed in its approach. So I think, if that's positive, um but it does mean that it would change uh in the structure of the SDK API as well, so I think if that's something that we want to keep in mind.

C

That being said, if uh I think that I kind of called out the two issues I had in progress that had like some reviews on I, don't know if there's any uh there's a bunch of other open PR's in the in progress that could use some reviews, uh I think we were down five uh issues since last week, so we're making some progress. This is a great place if you're looking to help accelerate the metrics uh stability. uh Reviews in this column uh would be helpful or any to do.

C

I guess a secondary thing that is still open. We definitely could use some help on that as well, but other than that I. Don't think. There's too many. um Oh, this is a good one. I think this is the only other. uh Aaron opened up this issue to alignment Ace encounter Behavior that we talked about last week. That's um well documented uh I think it's gonna be complex, so probably wanna.

C

If you are looking up solution, maybe put a proposal in the issue before you actually do the um work, or maybe even out of a draft. If you wanted to think in code. That sounds great.

C

um This one came from boxing this week uh to not expose the um Proto definitions here. I think that our client Library I, when I wrote this just copied it from what we already had. But um it's a good point maybe not expose the proto-definition in our API itself.

C

I think that this is going to be stable, but it's not stable yet so that's probably a smart move, so we don't run into issues where this part of definition is uh out of sync: it's not like the end of the world, but it is kind of like a point of contention that we probably want to address.

C

I was looking at this client library and this client implementation like I, don't I, don't know if we need it um right now. This is in the otlp um metrics exporter, and the exporters are all at this top level otlp each one of the client implementations actually has some sort of like creation method here uh and that creation method returns back an exporter.

C

uh This is really just here, so that third parties could also write their own clients to this I. We could also just put this in an internal package and just not have this exporter. Client interface live at this level, and it would only be something that you would import from one of these otlp metrics, jrpc or HTTP libraries, I I, don't know of any external libraries that are actually using this client interface. I. Do think that with this implementation like this would be pretty hard to implement a client in, say the HTTP Json Library.

C

If that ever becomes a thing we want to add so having the ability to change. This interface is probably useful, um so hiding Us in some sort of internal package might be useful. Just my thoughts on it I think this is a good issue to include I added it to the um project. So just I don't know if anybody else is taking a look at it.

F

Yeah, so here we're going to end up with uh income grudity with the tracing exporters. If we do this, though,.

C

That is true, that is a that is a good point. um Yes, that is true. I.

C

So I want to say you know like uh this is maybe a little bit uh contentious statement that um moving forward bad ideas is not necessarily a reason to move them forward in the first place, um but I do think that if it's a bad idea, it needs to be defined as to why it's a bad idea, um and so like this. This leaves justification to say that it's a bad idea that we've had stability, guarantee issues that we could not actually comply to.

C

um That being said, like yeah.

F

In the in the OTL free stability discussions that we're having, though, as well we're we're looking to ensure not just wire level vertical stability, which is the only thing bogdon cares about and and the only guarantee he thinks we should provide.

F

um We are looking to try to ensure that generated code will not break assuming that the code generator doesn't break right. So there's there's still a risk there, but I think that the stability guarantees we're going to end up with, for otlp mean we won't be doing silly. Things like changing instrumentation Library named is rotation, scope, name anymore,.

C

Okay, um yeah I mean I. Think that's like that's also what I I saw when I read this. It was like you know, like I thought. The goal was to get to the point where that would be stable enough. We could rely on it.

C

um So I do see that point as like it being a non-issue one of the things that I also.

C

I think we could try to address is the forward compatibility so you're right if we did make say the client we took that entire client ecosystem and put that into a um uh internal package, I think in the future. If somebody came along and said, hey, like the traces Trace exporter actually has this client and we want to do a different exporter for otlp than what you support here. Can we build our own client I? Think at that point in time we could expose that client into a public package, and we we could.

C

You know we could add the Symmetry at a later date. That later date also might be at a time when the otlp is stable uh and makes guarantees around that. So we could keep that or we may need to adjust the client interface. If, ultimately, that isn't something like the code generated pathway is not stable, um but essentially this would just if we move it into an internal at this state like we would still provide exporters at the grpc and HTTP level, but we wouldn't expose this. Does that make sense Anthony.

F

Yeah I think moving in internal is a two-way door. We can always make it public again, shipping it as 1.x public is that's a one-way door.

C

Right right: okay,.

C

um Okay, I'll leave a comment uh about what we talked here. I've been thinking about it, but I didn't actually write anything so I'll leave a comments in that issue.

C

um Other than that I don't see anything else in the um the beta projects. uh Just a heads up. uh We did get the TC to actually make all of our projects public. If you didn't follow that issue, Aaron I know that you opened it.

C

um But uh if you want to share our progress, you can do that now publicly um people who are reading it don't have to be members of the openstorm tree which I was really excited because getting ping left and right. Where are you at so? um Yes, also if you're on the call and you're, not a member yeah, uh so let's open but cool other than that. uh That's the end of the written agenda. We can pause here. Anybody else have any other topics they want to bring up.

C

Well, cool any uh cool use. Cases for openstorm should go that you guys have seen or done. I know, uh David was talking about kubernetes shipping last week, um I, don't know if that was successful. It.

A

Was not successful, um I hit a bug in hotel HTTP that um prevented some stuff from working correctly in Cube, so I'll have to fix it and then stick it in next release.

C

Okay, so that's the uh no body stuff that you opened. Yes,.

A

Yeah, there's a link to the kubernetes issues it caused I actually still haven't really root caused. It um I just know that this fixes, whatever problems we were seeing so um okay uh yeah, maybe dig a little bit more to figure out exactly what happened.

C

We got you uh nonetheless good call out if you're on the call go, take a look at that issue and that PR and contribute to unblock kubernetes development uh in the next release cycle. So yeah.

C

Cool anybody else.

C

Okay, well, then, we can edit here thanks. Everyone for joining um I will see you all asynchronously for two weeks and then I'll see you after that I'm guessing. You all still have a meeting, so please show up next time uh same place same time, um but otherwise yeah I'll see you all later thanks, bye, all right. Thank you. Bye.

D

E