Open Telemetry Uncategorized, 4 Nov 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: 2022-11-04 meeting

Description

cncf-opentelemetry meeting-2's Personal Meeting Room

A

A

I wasn't sure if anybody's gonna show up.

B

I'll come hang out while I eat lunch at least yeah.

A

That's fair, I, actually, don't know how much there is to do today either.

A

A

B

Had a project has all.

A

The issues triage but I mean I. Do wonder about this? um Let's see if I can find it.

A

Oh yeah I saw you comment on Josh BR Josh's pierced Maybe have opinions here, but um so like this integration, testing for the runtime instrumentation I was going to add it back, but then I'm like looking at like uh I also. This is kind of cool I um created some labels uh for the instrumentation, because we just had like a generic instrumentation label.

A

So I created this like uh instrumentation label based on the package itself, and so I was looking at this I went through and I like tagged. Everything and there's like seven issues already open for the runtime, instrumentation and they're. All like relate to especially like refactors to the thing that I think that, like I I, don't know, I, don't know if it's worth building instrumentation or integration testing for something that, like uh we're, planning to change like I. Guess it's somewhat because, like I guess it's going to be similar, but I.

A

Don't I thought that maybe it might be worthwhile trying to resolve these before building an instrumentation testing um which I I added as like a blocker and I was looking at um Josh had a PR or no, he has this uh instrumentation in the light step, repo which I don't know, I feel like also Aaron, you should tell Josh. This is kind of funny that it's in the latest every moment. It's definitely copyrighted to the authors of Hotel, um but I. Don't know this looks like I. Don't know why we're not doing this.

A

uh This looked like already, you know, I mean there's like some small things. I would probably change, but like the approach that he's taking is essentially taking, um you know, observers and then wrapping anything that comes from this uh runtime metrics package, and he does it dynamically. So, like it changes, each release has better metrics change. I was looking at the semantic conventions for the runtime metrics, and it all looks like um up to the language how they wanted to find the so like this seems like a completely valid approach.

A

uh I think that I don't know it seems like I. I might just want to try to do this and then I was looking at it. I was like well, you know like one of the things. That's always bothered me by the runtime package. Just doesn't match our naming.

A

So I was just wondering like if we could just take this and put this in the contrib package or the contrib repo like I was thinking something like um instrumentation runtime and then maybe like a subdirectory of this called Hotel run time and then yeah or V2, or something like that. Like.

C

They would put it in a weird spot uh for releases, but.

A

Not really because it's not stable, like I mean it's I, don't know if I'd actually go V2, because there's no V1 right like um but I I just mean like it's just like we should I mean we could do like something like a a second version here.

C

But I think that you could also.

A

Align it to be more in line with all the other instrumentation, but I, don't I was just looking at that. I was like well. If we do that, then I think building integration testing off of that would be a lot more useful. So I was wondering if we want to block this um and just just go that direction.

C

um I'm 100 on board, with uh redoing the runtime instrumentation uh to something that is better um but I also don't know if that needs to be part of the um uh like the Beta release or even the stable release honestly like um it would be a nice to have, but like I, wouldn't I, wouldn't put that, as you know, blocker for actually getting something out.

A

I think that's fair um Okay, so.

A

So maybe we take uh this issue and move to a different project like a post, GA project.

C

Yeah, that's probably where I would put it: okay,.

A

um Status backlog I would probably then add all of these to that same actually, I think that's a better way to do that, um but same project. If that makes sense.

B

As a rule of thumb, should nothing can contribute, go in the beta over GA milestones.

A

Well, we definitely needed the go SQL um uh package stuff because we had like views and things we added just to get the alpha out that we wanted to correct So like.

C

I think generally, um the things that should go in uh from contrib are if we make an API change, that's reflected in the contrib.

A

C

So like, if, uh if we land the views, change um that you were talking about yesterday, that will necessitate that might necessitate changing like test cases or something in contrib, in which case that should definitely be part of the project, but other than that.

A

B

So, like Hotel testing, we.

A

We changed the API for what this looked like in the testing package. We just essentially blocked this out. That's why this was added back.

C

A

I included in the beta just because it's like we said it'd be in the next step. I guess it doesn't technically need to be, but I don't know. It's already done um these other two, though the runtime which we just took out and then uh host integration. That is the other one. um I think these were adding tests, not necessarily adding back to us uh so I. Think that makes sense to put this in, like a post, ga.

A

C

The question I like to ask here is: if we didn't do it for beta, what is the consequences like? Is it possible that we won't be able to do it after beta or yeah.

A

It's just going to be user complaints, but, like that's not the end of the world, um yeah I guess yeah I mean it's not it's not the end of the world. um How about these though? Aaron? Do you want to add these to that post, GA projects?

A

um We need these for the other integration testing. We were talking about.

C

Yeah like they would have the same kind of priority right. If, if we don't like, if we don't do these and um yeah, my general idea is: if we don't do these until after beta um and there's no drawback to doing that, then yeah, let's, let's do them after beta. Let's focus on the things that need to be done for beta well,.

A

They weren't even in a project uh but I do think that they need to get tracked is what I was trying to say. um Yeah.

C

From the looks of it like not having to Dove deep into these, it looks like they need to be Consolidated into, like one master.

A

C

Yeah um but I don't think we need to take the time to do that now. No.

A

That's why, like I, created that post GA, essentially like as a bucket of like address this stuff, like this stuff, needs to get cleaned up, I imagined a lot of that will get cleaned into its own projects after the fact as well, but yeah, uh okay,.

A

A

This was added; this is, let's see it done.

A

Easter ready to ignore Fields, um yeah I added these two issues, I'm wondering if they hit the criteria you're talking about like, if we don't do these, um the problem I have is like it may need to restructure this metric data test package in order to accommodate these. So I'd want to like have like a line of sight about what the solution is. I, guess, I added like this ignore option essentially like I, was doing a bunch of testing, and um you know like, as.

C

You're doing it yeah yeah.

A

Like it just becomes so useless that you have to just essentially build your own.

C

Yeah and if that's the case then um like I, would be 100 on board with, like the scope of this for within the project. Right now is um to have kind of a proof of concept of what you would want to build. Not necessarily have it all built, like maybe another option or maybe like a line around. What changes need to be made and why yeah and.

A

Then it really stuck out to me is like this ignore option from this compare package like it's.

A

um It's used like it's kind of it's a different style right, like users, ignore in like these filter paths and filter values right in.

B

A

uh Google package here so it's like this may actually change the way we want to. uh What's our current ignore option, I think, oh time, I'm sorry like yeah so like it may be that this could be like a superset event and replace that. So that's kind of why I think that's why I remember right now. I might want to actually just change that.

C

um I would be a hundred percent on board I, don't think we use go, compare yet.

A

C

That's I'm not.

A

Saying well, you should yeah I'm saying that, like we need to build, look into like how this was built and then maybe try to build something like that. Here's, what I'm saying.

C

If we're gonna rebuild the go, compare I would maybe prefer to use the go. Compare but well.

A

I'm not I'm, not suggesting we like look into how filter paths algorithm is used right like because this may be just simply calling reflect under the hood right and then.

C

A

Ignore options there so like, if that's the case like I, don't know you take this and like I, don't we don't need, go compare we just need.

C

A

Identify types the.

C

The the trick there is there's a function called normalize uh path, or something like that yeah. um That is not. Is it normalized option, there's somewhere in there, where it actually like normalizes out a path, and um it that's not usually pretty trivial, especially if we have like reflects with um uh what you might call it with with uh different kind of container with interfaces that have different containers under the hood. Like our some some data point versus histogram data, point versus you know so.

A

Yeah I I, okay, I.

C

B

Want to make it clear.

A

That I'm, not suggesting we use I, do I think that we need to look at an alternative to our ignore structure. That's what I'm I think this is more suggesting so.

C

Yeah I'm perfectly happy with that and and having it scope to get us what changes might come from this so that we can. We can.

A

Learn data package is really useful, um but you have to have complete deterministic knowledge of what the data You're Expecting is um so like yeah I think it yeah same thing with attributes like sometimes that's a whole other ignore thing. Maybe we could yeah I.

C

A

Could probably build something that like works for all of it, so I just wanted to make sure it's included, though. Thank you um this with namespace option for the Prometheus exporter, I think is probably worth discussing as well. David I posted your comment yesterday.

A

um So I don't know, I think I think it's worth, including, though, just because like we need some way to have compatibility uh with open census, which apparently already supports something like this. uh So I don't know, I think it's also worth including that.

B

Sounds reasonable we can always either discourage use later with comments, or uh if we have a replacement before this goes stable, remove it with instructions for people so yeah.

A

So I kind of talked.

B

Something useful.

A

Yeah Paulo definitely pointed out that, like it's not ideal but like it's just open census, already has apparently an option that looks just like this um and I said well like. Why? Don't we just do something like this?

A

Where you take a prefix, but you also take a scope, and if you pass an empty scope, then it would apply for everything, so it would be a backwards compatible like you could just be like okay yeah, um but then you know our essentially like or pass a scope with some sort of wild card in it, but like having this being a match. Criteria could also just be like we could Define what that match. Criteria is, and then I think it works.

A

I think it's backwards, compatible and I think this might be like more long-term usable. um The problem I have with something like this is like it's cool, but now you have to take this view that came from your exporter and then pass it to your meter.

B

A

Like it's like I, don't know, let's that's. Okay,.

B

I would expect if this existed at all the namespace view thing for it to exist as part of the view API is some helper or something right not to be part of an exporter.

C

Could as because one of the the problems here is Prometheus, doesn't have any kind of way of name spacing things. Could we have an option that maybe would work that's um taken as a flag to just put the scope name or or some like sanitized version of the scope as the prefix for the? Why.

B

Are you trying to name space.

C

Isn't that the whole goal of the of this option.

A

Yeah I mean it is I'm guessing I'm, guessing they're, trying to name space just because there's conflicts and instrument names in two different libraries, sorry yeah.

B

But hopefully we've solved that.

A

B

A

Mean honestly, like yeah again I think these can solve it better, but you need that context of the existing name.

A

That's a good question like I, don't know like.

A

If we think we can get that view, refactor and like I I, think it'd just be better to just say like use a view and not add API surface area here, but I'm also not opposed to doing something like this, which is essentially like its own implementation of a very specific view in the exporter.

A

B

A

We don't have to solve this in the triage meeting. I just wanted to make sure we are comfortable, including this in the in the project right now, yep.

B

A

um Open census, metric Bridge doesn't work with Telemetry Prometheus exporter. Is this still a thing I.

B

Don't remember yes, I think it is right. Aaron we didn't ever merge any of.

C

Our bridges, no, we haven't, um did that ever land in the.

B

Spec no I I've taken a significant amount of time off from that, but okay.

B

Yeah I'm almost back the kubernetes releases cut and are the code freezes in a few days, so I'll be back from random stuff. There.

C

Oh nice, nice um yeah, like I, think from my understanding. This was kind of predicated on some kind of consensus and bare minimum contestants from The. uh uh What you call it from the spec.

A

C

Agree uh before we be commit to to including something like this yeah.

A

um But it does seem like it's something we're gonna be able to accomplish in the beta right like this is something we should be able to include.

B

Depends on how quick.

A

The beta is at the current rate, it's going. You have a few months so yeah you.

C

B

Bit of time, yeah.

A

Yeah, yes, it's.

B

Time, why do you think it's going to take a few months, uh uh just a lot of changes or yeah.

A

I mean there's, there's been I, don't know if it's just a slow time right now, but presenting things in progress right now that like, if you want to look at this past two weeks of a pretty dang slow and it's only going to get worse as the holidays come right like uh we've got Thanksgiving coming, we've got um Christmas after that. So I don't know. There's probably like another four weeks of solid work where you're gonna have a lot of the contributors. Actually I mean or like participating. So are.

B

Those all user-facing.

A

B

17 of these well I see things like unified caches and.

A

uh uh User-Facing I mean these.

B

Internal implementation details are these all actually Behavior changing.

A

uh A lot of them are internal, uh but there are definitely some that are API basic. um This is internal.

A

This I mean I, don't it's like? What's internal like I guess the API is not going to change here but like if there's a big bug that needs to get resolved. um This is external. That's a that's, probably one of the biggest external ones. Right now this would be in addition to the API, but it may also be a refactor of the current API like I. Don't know if this is possible if I have Json coding with um ignore time stamps. So that might be uh this.

A

uh This is again like it's internal, but it's Behavior like it's. A bug like currently we're exporting aggregators with um empty data sets partial success, response that was added yesterday. That's again, a behavior like at like the API stuff, is only like, probably one or two, but it's mostly bugs and um I guess then then it's optimizations as well like there's that caching one but yeah.

A

I think it's bugs honestly. David has been a lot of our time being spent that I've seen and addressing feedback, because it's also well. This is this. Is another um API one as well. This would change our API structure memory allocations. That's optimization! This!

A

uh It was I. Think it's just gonna go away. If we get a view refactor um the reader one. That's a that's a big question uh also, this I think is just about reader compatibility in exporters, but there's also just this question of like. Should we allow users to be setting readers.

C

Yeah, providing open readers right, yeah.

A

Open readers like Arizona.

C

Yesterday, I never got around to writing an issue around that, but, like that's still on the on the thing to on the docket for me to deal yeah.

C

um And that would have an accompanying API change.

A

um Absolutely yeah, it may be backwards compatible, but it may it may not be honestly too, like um well, probably won't be actually.

C

Well, since a user couldn't have created a reader without embedding a reader.

A

Yeah, that's true right! So then, if you move forward and you like, take a private method and make it public, is it really backwards incompatible then yeah.

C

Yeah, the only incompatibility I could see is if somebody had created a a function, a public function of the one that we uh just made public.

A

Yeah I mean it's not the end of the world. I either like our API is not stable. So that's up to them. Yeah.

A

But so then also Aaron kind of on that same thing like the, so that's just for the beta metrics SDK, because we still have the the ga process, which is a review and audit to make sure that we're compliant, which I have a low level of confidence right now and our compliance given the current state of the SDK questions that we've had um so I think this is going to be a protracted experience like working with some sort of TC member to verify this sort of thing.

C

What's what's in the the API ga.

A

uh Someone actually picked one up yesterday. um Actually, where are they yeah uh so documenting the public interfaces with our versioning policy and then literally just going through and having every single section of the API specification verified that we are compliant with it. I I was talking to bogdon and he still is not happy about the package structure, so it it might um I don't know. I was going.

B

A

Another look at it and see like if it's really that atrocious um and if we need to I, don't know if there's a better option but I.

B

Did get the same feedback from a uh one of the Prometheus client maintainers.

A

Yeah I've gotten heard from a few other people as well um bargain's, the one I worry about because he's on the TC, because that would block our GA.

A

um That's why I said like I want to take a look at it again and I. Don't know it doesn't it's it's a true Ash reading. There's a lot to say about this: I! Don't think it's the end of the world, but some people do and it may make the project better like it may make it so it's more usable and they make it more discoverable for other people from other languages. So, like I, think there are things to go. Look at.

C

That was a month-long compromise like a two-month long compromise that we went back and forth on a year ago, more than a year ago,.

A

I know and I still don't yeah.

B

But user feedback is also not something I guess we had a ton of so it seems like we've gotten amazing.

C

Exactly like I'm not wedded to it, I I'm more wedded to having like a definitive direction to go in and yeah um going in a direction that we can help not break people over and over and again.

A

C

Mean that's true, but.

A

It also is if the API changes in a like a one-to-one fashion, and you can deprecate a package and just say like hey instead of using this use. This, like uh that, seems like totally fine, like it's not ideal, you're going to frustrate people, it's when we go and we say like we're going to completely redesign the SDK controllers. Don't even have a concept anymore. You got to go from like this completely divorced concept to this one that one's like I mean it's totally valid at our versioning policy, but it's also like yeah.

A

Let's try not to do that. Every cycle, oh.

C

No, like that, that's a thing, but.

A

C

Also, like controllers, that that was an interesting byproduct of of a lot of different versions. You know of the the actual metric uh specification so like, while it would be nice to have a direct upgrade path like it would also very much complicate our our like.

C

There would be a large swath of our API that we basically would say uh that doesn't have a real analog in anymore.

A

Yeah and that's the thing that I don't think would happen if we restructured like the packages like I think they were. There would just be like instead of importing this and using this just use this package and use this function or something so it's like that's not like I I think like I, have to go. Look but I, don't think. There's anything like big deal, I. Think there's also like a big question of like um or SDK implementation.

A

How that would look uh because, like if it'd be a I, don't know it's not the end of the world.

B

A

Is that there's user feedback we should I think one would be great to document it so I mean the bargains documented it but David do you know if, like your um the other person who was telling you with a feedback, could could like put it in slack work or even just an issue or something like that, or is that.

B

A

B

I could probably talk to them. Okay,.

A

C

B

C

Be appreciated.

B

I agree: I'm gonna just pick him now, although it means I'll have to. He asked me for something, so it means I'll have to. If I go, ask him for something yeah.

A

You gotta spend a little of that technical Capital. There.

B

Yeah, um okay, I'm in debt I need to go pay off my debts and that I can ask for a.

A

Few things yeah exactly a new load, um David.

C

Just so you're not surprised I put you on the actual attendees list since there's three of them.

B

Yeah, no, that's great. Sorry I meant to do that, but yeah yeah look. It's.

A

My name um I have a hard stop at 10 today. Is there anything else we wanted to to talk about on the triaging side, things I think it's pretty well structured.

C

uh The only thing I would have to to ask is: do we want to do this again, like do we need this next week?.

A

Do you think that we could do a better job I think we have like 27 open PR's? uh Some of them are like almost a year or so old and going through some of these, like I've, independently, been going through a bunch of old issues in the contrib I, don't know Aaron. If you saw that like I was re-tagging things like um I think we could that could that could be helpful um but yeah, maybe maybe we go like hey?

A

Do you guys all have time like the day of or something and then decide if you want to cancel or something.

C

uh I'm totally fine leaving it here and coming back and expanding the scope of it. I just wanted to make sure that we got a focus on the metrics beta was was the goal of this. So if we want to expand this scope to be just a more General triage session, fine I'm I'm 100. Okay, with that, um we could build a process around what we want to triage and and where we want to put it and and how we want to account for it, I'm fine with that.

C

uh If we want to just keep it at the metrics beta and we say we're done with it, and we want to cancel this meeting I'm fine with that too.

B

I actually I don't know if it's that helpful to like review our project boards, maybe like occasionally, maybe once a month or something but mostly I, I, expected this meeting to be looking at things that haven't been stuck in a project or a milestone or had labels or whatever that's what I've seen in other projects.

C

Yeah, so um that's that's what this started out as uh yeah, the the what.

A

A month ago there was I'm definitely down for whatever you guys decided. Okay,.

C

uh A month ago this there wasn't a project board uh so over the four meetings that this has had, including the one that Tyler did during kubecon we've gotten to like the first one. I did a load, I think the second one there might have been two.

B

C

Second, one um yeah I I had an emergency then and then I think the last one was during kubecon.

C

um But anyways uh uh the idea there would be we would expand the scope of this to be um like general triaging for go and contrib would be kind of keep it around and expand it uh versus calling it good we've we set out to finish what we did. We finished it, and then we don't need to keep coming back for this and I'm up I'm up for either way.

C

Honestly, I I, we could propose this at the next triage meeting and just say of the people who show up like do. We want to keep doing this before we uh before we get into actually triaging anything.

B

B

This one pick me um I, think it's good to have triage sessions. I think they could be less often if we want, if we're not getting that many incoming issues. It also seems like a lot of the maintainers, are already active, triaging things, so we might not need a group triage sort of yeah sort of, but.

C

Why don't we do it again next week and then, if we get through a load of them like there's a bunch and contribute that is just not triaged in any way shape or form right sure right um if we get through a bunch of that then um or or the go backlog like we could then.

C

We we could see where we're at or at the beginning of it just say: hey do we need to do this? Is there better uses of our time?

C

Cool all right, see, ya, see ya. Thanks for coming.