Open Telemetry Uncategorized, 16 Nov 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: 2022-11-16 meeting

Description

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

A

B

C

How's it going.

D

Good good, what about you.

C

Good looks like it must already be pretty dark. There.

D

Yeah, it's winter clock.

C

How early does the sun set there, because you're you're fairly significantly further south than we are.

D

It's uh about uh five I, think, okay by 5 p.m. Just I, don't want to work day ends yeah, but in the summer it's about like.

B

D

Okay, what about you.

C

I mean in the summer it can be as late as 9 30. uh I'm, also on like the far west side of a very big time zone, so that kind of affects it too, uh but yeah. It's about five o'clock here also.

C

See I can tell you exactly and then we can get the meeting started today. The sun will set at 508.

C

all right, let's get started. Let me uh share my screen here.

B

C

All right um well, the first item I have on the agenda today is the the metrics ga finalization, uh which is just the uh contrib release. So all of the contrib packages have been updated to use the uh latest SDK and API packages.

C

um So I was going to release this, but before I did that I wanted to make sure that everybody had a chance to see it. uh So I'll probably give it another.

C

You know hour or so after this meeting and then merge and do the release, uh which should complete the metrics GA release, which is pretty uh pretty exciting.

C

um Anyone have uh any immediate thoughts here, any any pull, requests or issues, or anything like that. That should block this release that you know of.

C

Okay, um I just have like next priorities here, just a list of high level items that I'd like to focus on now that we're done with metrics and have a little bit more bandwidth.

C

um Obviously, logs is important because uh it's the next uh signal that we're uh developing um but also uh I, think I'd like to take some time to focus on some convenience helpers for the API. uh We've had a handful of requests for this and uh PR's, uh and uh things like that and I think that we can take some time to make the API a little bit easier to use, especially for new users. A lot of the other sdks have done similar things.

C

um Somebody I don't remember, who I think might have been Philip as a uh uh sugared, Tracer, uh PR right now and there's a handful of others. So I think I'd like to spend some time and focus on that uh and then also the developer experience I'm sure most people on this call are aware that a lot of our Dev dependency tooling, is a little bit outdated.

C

uh The builds take a really long time, particularly in contrib, uh and some things like that and I'd like to look into some ways that that can be improved.

C

um Also from my own perspective, the release of the 1.3 API and the 1.8 SDK was a little bit of a painful process because of the way that uh lerna works, uh so I'd like to uh try to find a way to automate that a little bit more, um we didn't end up having any problems, but some of the steps are very manual and they require emerging PRS. Even though builds are failing, and things like that. That don't make me feel particularly good. So I'd like to spend some time improving that um anybody have I.

C

Think I missed a topic here that that they think is important, that we should focus on next.

B

C

uh Then I guess I'll move on to the more concrete items.

A

Yeah, probably just like comment on the next priorities: yep I've almost got the sandbox well I fixed the sandbox emerging script, the history. My next step is to Munch that into the web form which I'm planning to like I'm at for the next two weeks. But the then I'm back for two weeks during those two weeks is when I'm planning on doing that. So hopefully come the new year.

A

We should hopefully have a a Sandbox, it's going to be primarily web focused, but we could potentially extend it for the node, but we can have a branch for that I guess um but anyway, but that'll use Russian roll-up. So because that's what I'm familiar with yep.

C

um Actually, uh Mark and I were just talking about that this morning, uh how the sandbox uses Rush um I think that's one of the things that I'm going to consider for the main repo as well uh just to try to get some of the the installation and build times under control.

C

um It's not so bad in the main repo. But in the uh contribury bow it's a little bit out of hand. It takes a really long time.

C

Okay, um so the first concrete item I have here uh is a PR that I talked about last week. um It's a little bit further along now. It's no longer a draft. uh It covers everything except uh what T2 mentioned here and I'll get to that in a second. uh If you're interested in how this PR works. You can look at this issue comment here, which shows a diagram of uh uh how the timing decision is made uh in the implementation is at this link here.

C

uh T2 brings up that uh if you provide a start time and you provide an end time uh the and they both come from the performance timing, API your span can still be uh shifted into the past, uh and that is true, but I don't have uh I, don't have a great idea on a fix for that.

C

Yet um so, while you're reviewing the pr, if you want to uh consider that, then I would appreciate that unless T2, if you have a suggestion or any thoughts on on uh how you would fix that, I am all ears.

E

Well, since I already mentioned that there currently is an assumption about very low time, steps that probably is forced, maybe uh then maybe also applying to time drift if time, drifting algorithm. If the time, if we assume that the timestamp is from performance API as the spends start.

C

So you're saying, if the if the start time is provided.

E

B

E

It's basically the same logic that is currently being used to determine if it's from performance API or it's an absolute timestamp.

C

C

I, guess that's so if the start time is less than the time origin I got it. So if the start time is from before the the page start, you had the offset um that makes sense to me. I.

C

I guess I can try to add that to the pr and and see if it breaks anything. um I know that the uh HR time input or whatever is called method, is already doing some.

C

uh Some changes like if, if the start time is less than I, think less than time origin uh it adds the it shifts it by the time. Origin amount. Maybe I, don't remember exactly yeah.

E

Exactly that, so that's why I'm suggesting the same logic.

E

So we, if that's supplied, then it becomes start time this offset and then the later it has that I'm origin to.

C

C

Yeah I mean I I, can't think of any immediate problems with that, uh but I would want to. Let me try to implement that this afternoon. It should be easy to add to the pr that I already have uh and make sure that it's not breaking anything.

C

um Anyone else have questions about this PR.

B

C

um I was hoping to ask for a logs update, but it looks like Martin is not on the call today. Well yeah he's out this week out this week. Okay,.

A

um I'm actually surprised at that PR that you've linked there as it got question. We already talked about that in the log Sig last week. That's splitting out the units of unlocked API, so.

C

Yeah, it emerged two days ago, yeah.

A

um It was only raised six days ago, so it was right. The day after we talked about it.

B

A

The log sink is directly after this one.

C

Okay, um I mean the the pr that uh Martin had definitely does not take this into consideration, but that's totally understandable, considering it's like the entire idea is only a week old yeah. So.

C

um I did review his uh logs SDK prototype uh this morning. uh Yeah it generally, you know, look good.

E

C

That that specification change is a fairly major change, uh but it should be easy to apply. um Yeah I I made some comments on IPR, but I can wait for him to get back. That's fine, yeah.

A

um The other potential big changes coming to events is uh again in Las Vegas. We contemplated effectively adopting the cloud events, uh the CNC of cloud events, project um to define the event data I already had a a PR open to Define event.data as our payload, um but Cloud events already has a data and does a whole bunch more stuff. So.

C

A

Things around splitting out the API.

C

Is that a data format, or is that a more like a semantic convention.

A

Really, just a structure yeah what what does a a cloud event? Look like so it has like you know the type schema, the data you know attributes and that doesn't actually Define what each event does it just says. This is what the what an event should look like got.

C

It and then is then agnostic to the actual transport, whether it's Jason or protobuf or whatever.

A

um It has the option of how you encode the data so the the by default. They will assume it's an object, but you can Define with a um a data content type exactly what the type is so can I handle binary data as well got it. Okay,.

C

C

um Yeah, that seems good enough for me, for now at least uh just wanted to make sure that that logs is still moving along. It sounds like it is.

C

um Do you want to provide a Sandbox update beyond what you already mentioned uh earlier.

A

um No sorry I I do have the the merging script is now working again. uh So the next step is to take that um merge repo with all the history and then push into the shape of my first PR, where it's building with rush and roll up to generate bundles and stuff, which is I plan to do um between my time off so I'm out for this for the next two weeks, I'm back for two weeks and I'm gone for the rest of the year. So in those two weeks are my target for this.

B

C

um I suppose I should have put this in next priorities. Although it's more of a a single work item, uh all of the docs should be moved to the website. uh This is something that Philip and Severin have been asking us to do for a while and I. Just had really have not had time uh so uh I will be working on this, but uh if you're looking at uh the repo- and you see docs that are there and you think you have some time, helping me to move them to the website would be appreciated.

C

If you are going to just make sure to create an issue- and uh you know mention any issue that you're working on it, so that we don't duplicate, work and I will do the same so that people know what I'm working on.

C

uh I did not add this next item. I, don't know me.

D

And I want to ask your opinion: I want to change the name of the instrumentation files. Currently we have types which is public types and the internal types for instrumentation and we separate them. So we don't accidentally leak a instrument that the package types from the instrumentation and then I thought about it again and I think the name config better suits this file because all the instrumentation just have the config and instrumentation configure so I, don't think it's a breaking change.

D

I would love to do it, but if anyone has any opinion or objections or support it there's an issue. You can comment.

C

Okay, um I mean it seems reasonable to me. um I think the conveying should be the only public type if there's any any non-config public types for the instrumentation, then I think that's leaking internals that we don't want to do so. I I think it's a good idea. Renaming it to config makes it obvious what it is and then, when people are writing instrumentations, uh it makes it a little bit more obvious what should go in there.

C

um Yeah I'm generally supported with that I'll give a thumb up here.

B

C

Have a comment there.

C

Okay, then I guess: let's move on to bug triage.

C

No new ones in the main repo, that's what we.

E

C

To see and contrib bugs looks like we have one new one here: a few years ago, instrumentations yeah.

D

So so he asks to add another semantic attribute to what is instrumentation uh um I think uh if he wants to do it, a great can opt for grab it.

C

Yeah is it a requirement.

D

It's a recommended if different from zero recommended.

C

B

D

um I think it makes sense. uh It's also.

B

E

B

D

C

I think I'm just going to change that to an enhancement, because it's not really a bug. We maybe want a different label for semantic conventions. Maybe there is one: no, there isn't um yeah I'll put this up for grabs, I, guess yeah. It seems if it's in the specification I, you know, don't see any reason. Why not.

D

Yeah and it's not only for the ladies forwards, or also for uh the previous uh ladies instrumentation as well.

C

C

Okay um and I think that's it. uh Anyone have anything that they want to bring up before. We uh call today.

C

All right, uh please, take a look at the contrib release. Make sure that uh there's nothing in there that shouldn't be and uh I will talk to you all in actually I suppose before we go, we should talk about. Should we cancel the meeting next week. uh Thursday is a U.S holiday. Most people in the U.S will have Thursday and Friday off uh and I. Don't know how many people will take other days off I'll be here.

C

uh If we want to do the meeting we can or should we just cancel it I think the spec and maintainers meetings were canceled.

D

I can join, we don't have a holiday here.

C

Okay sounds like: if people don't have an opinion, I'll just keep keep the meeting then I'll show up, and if there aren't enough people we can always just close the call all right. uh Thank you, everybody for your time. uh Matt Ware votes for canceling uh I'll join the meeting. I might just uh expect it to be a short meeting uh Although. Our last few have been short, anyways yeah, so don't cancel on my behalf, but but I will be out on Wednesday. So.

A

That that was the reason why vote.

C

Yeah yeah I figured okay, um then I guess I will see some of you next week and the rest of you later.

A