Open Telemetry Uncategorized, 4 Apr 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: 2023-04-04 meeting

Description

cncf-opentelemetry meeting-2's Personal Meeting Room

A

B

C

B

It's maybe wait another two minutes or yeah, so actually waiting for Alan to join and uh yeah I think we can start. Let me share my screen.

B

A

You all see the dog.

A

D

B

Right so, uh first item on the agenda is no Lego um like an announcement that 1.5.0 Alpha 2 version was released, which has exponential histogram support for odlb exporter, um so yeah we could keep continue to work on the other exponential histogram related work. That is due and uh the second item. I put it there.

A

B

It's for I think we discussed about this because of some contribopr, which was trying to stick to the older, unsupported Target framework for their unit tests.

B

So I wanted to ask uh like.

B

Is there I I like so? We currently have net standard dependency, but our unit tests for the main repo are not gonna test that biology like we have.

B

We don't have any net core netcore app, 3.1 or anything in our unit test. So my question was: if, if there is a way to know that we are not using any net standard API which is not supported in net 462 or like four seven and the above ones, then could we just drop the net four six two uh Target instead and then have our unit tests for net Frameworks uh cover the net standard binary.

E

And my vote would be no because there's reasons why you have that net stand or The NET Framework Target, uh trying to load it all into context.

E

um So.Net standard, 20, supporting.net framework isn't real until like net four seven, something one or two.

A

E

When you have.net standard on.net framework, four six, it allows it, but the actual full surface of the API does not exist.

E

So you can run into weird things so having that NET, Framework Target just make sure it allows it to always work, because we basically compile an actual binary, and if there were issues it would manifest at compilation. I'm, pretty sure. That's why, on the.net guidance, it says to do that.

A

E

It's safer, I think doing that than trying to run these tests, which I think have debatable utility.

F

Yeah I think we want to proceed with that with caution. If we wanted to entertain that I, you know it's kind of like one of those things. If it's not broke, don't fix, it is my kind of first gut, but like I, don't have a I, don't have a strong reason. Why, like? That, would absolutely be terrible if we dropped the net 462, but I I I agree like I, it seems like it would probably be safer to keep it regarding the test.

F

Specifically, you know, I did just a real brief grep over the code base for uh free compiler directives identifying locations where you know we're we're doing like pound. If NET, Framework or pound of you know, net standard and I want to say I think I only found one spot that only had coverage of uh only net standard um and Mike fixed. That I pointed.

G

Out to him, I was in the Jaeger exporter.

F

He'd merged a PR last week, um so, for all intents and purposes like everything is tested, um we can we we should probably validate again. That was a quick, quick grip, but like that, that's that's what I did like just to see um and.

G

Then then I.

F

Think it becomes like a code review uh concern like when someone in a PR is introducing pre-compiler directives. If you know the pre-compiler directive involves net standard so long as it also uh involves some concrete um thing that we like run time, that we have tests for that I think we are okay uh from a testing perspective.

B

So I guess like for our repo. We are still good, but um I think we would need some kind of guidance for the country. Repo component owners, as well I, mean I, was wondering if there's like a way to know uh at like compile time build time, whether you're using any net standard, 2.0 API, which is actually not supported on net462..

B

If there's a way to know that beforehand, uh then I guess we could tell those contract component owners that you could drop your NET Framework Target and have a like unit test switch Target net 462., which will depend which will use the net standard reference.

B

The net standard binary of the of your project. So this this whole thing started with the like. I think this PR right, like like our discussion about this last time when it started.

B

If it was this one, but.

C

Use this yeah that that was the pair yeah.

B

But like yeah essentially like um like what what do we want to tell, or do we even want to tell anything to be component owners in for the quantity, repo, I guess for our repo? We are pretty safe, uh considering we don't have any code, which is. Thank you, sir Alan. Like uh maybe for our code. We are code. We can also enforce like in the main repo that, if at all, we use and if net standard pre-processor directive, we always use it along with a concrete implementation, so maybe either till that to them.

B

I would like just tell them that if you're not.

B

I thought there was a response here by the person which said why they particularly wanted uh an older framework or something.

C

Yeah, so they they wanted to test the net standard binary um because they added net six Target on their package. So as soon as they add Netflix Target, the net standard will not uh be used for testing purposes uh for both net 6 and net seven. uh So that's why they were trying to add, like an older netcore, app 3.1 Target in the test, so that they could like have net standard use in the unit test, so that that was the reason.

F

Can we do a quick look over I didn't look at this code, but can we do a quick look over the code just to get a sense of like what code is not would not be covered by tests.

C

I think they have some, um they got rid of the the Newton soft or like they wanted to use the system text Json from net 6., okay, yeah plus.

B

But like from the in the code files, they don't have any specific.

B

In specific FP.

G

Processor directive.

B

Or anything like.

C

Yeah, most probably no I haven't seen the code.

B

So I have another question like here in this case: if so, if a unit test project now targets net four six, it's going to pull up the net six binary.

F

B

So then they can just add a net four six, two framework for their thing, like that.

F

Looks like it already does yeah so.

C

A

F

I think it's covered if it's just the, if it's just the Json Library that they're they're looking to validate, then if they have net 462 tests.

F

I'm guessing that, then it's tested, yeah.

C

uh They also have net 462, Target right or no I thought they had. uh So that will be loaded right, like the net standard will not get tested in that case was.

C

Yeah NET Framework over there like I, see okay.

B

Oh yeah, so this is the 462 and then they have.

A

B

Right so I think like uh I mainly wanted to ask like if, if this is something we can do, if this is an alternative should be recommended to customers like dropping The, NET Framework minimum version itself.

B

Is there anywhere to know that beforehand? If it's too risky, then like, we should be able to tell the other thing that they are okay without testing that standard 2.0, specifically using netcode apps.

F

uh I know you've all have talked with the net team a few times about this, but maybe not about this specific question. uh You know maybe just raising the concerns that Mike brought up.

F

And validating whether you know they see any concerns.

E

So we talked to them, I think it was last week about it.

E

The answer we got is runtime does not test on any unsupported Frameworks so for their net standard 2-0, they don't like go out of their way to run like 3.1 or 2.1 or anything, but they do have a wider set of things they test against. Like mono, you know xamarin they build across architectures and os's. So I don't know if we're certain if some path through their Matrix actually test them at standard, 2o, I sort of looked you know: I just went to some random PR on like activity and I.

E

Looked at all the CI there's like a.

A

E

List so it's kind of unclear to me. If maybe they're testing it, you know haphazardly via something I, don't know, I also don't know if we're interested in going through that effort, they didn't seem to have any concerns with just not testing it. So I think it's up to us. If we're okay, adopting that or we want to pursue some kind of solution.

F

um Yeah I hear you like they might be testing it via xamarin or something like that. But I think that the question about dropping net four five, four six two target um is a slightly different question. uh You know I recall already, like all the all the most of the net libraries do ship a net 462 Target today um and so I guess the question would be why why are they doing that um versus doing what utkarsh is suggesting.

E

Let me paste in here their guidance because it specifically says to do the.net framework. It says like if you're doing that standard Duo. It is a good idea to add The NET Framework.

E

I, don't know if it explains it, but it's definitely on there. Let me see if I.

F

Can find that yeah? It would be a good reminder. I think I've seen what you're talking about before, but.

E

I didn't read through this to find it, but I think it's on that.

B

B

I I think I, remember seeing it somewhere here.

E

Specifically calls out there's some issues: with.net framework and netstand or two Oaths.

F

I was talking about net four six, one.

A

E

. see that range there so.net framework didn't actually support net standard 2-0 until 472 is anything before that. You're in this strange gray area of there may be issues.

F

Actually I think Andrew locks. This is where this is where I saw something about this I think Andrew Locke's, latest uh blog post about the history of net standard I, think he talks about this in a little more detail. I.

B

Mean that and paste it on the chat as well.

F

Yeah this um it's kind of a long post, but there's something about I.

B

Think um yeah I remember seeing that as well. I.

A

B

It's kind of like this this morning.

E

Want to say there are also performance benefits of using a bll would piled for an actual runtime, because the net standard ones they're, basically just a compatibility layer that, when you call them they call into stuff in their runtimes I, think you're actually going to like extra hops.

E

I, don't know if that's something to be concerned about, but.

F

Yeah, that's interesting.

B

Oh wait: Aaron was this the one that you're talking about so like if net462 might like? Technically it implements net standard 2.0, but you might get a platform, not support exception. If you use an API which was not meant for.

F

Yeah and that's the thing where we're speculating it's like is that is that something that's going to be told to you at compile time, maybe but worst case right. It could just be a runtime exception, which.

A

Case you know, hopefully our test would test it.

F

I guess you know like.

A

Like you're, suggesting.

F

F

B

So I I mean like for our main people. We want to keep net standard, but we're not testing it and we're either. So we either say that we're gonna keep it, but we are not testing it and we are fine with it. If somebody reports a bug for some platform, we will obviously fix it.

F

Well, so long as it's first, it's so long as they're running on a supported. You know that that's been our statement. It's it's a wonky! It's a wonky thing because, like right, metrics doesn't work on netcore, 3.1 anymore, yeah.

B

F

We decided we don't want to fix that because that's an unsupported thing, but.

B

So can we extend that same guidance to them? I I! Think we, if like we, can ask the Dortmund team. If there's a way to know this during compile time, if our library is using any of the apis, which would not be supported on that framework like if they're, using using any net standard, 2.0 API wouldn't work on a certain implementation. If it's, if it's something we can know beforehand, then I think we can be more confident in dropping net462 but otherwise yeah a.

A

B

Risk or or if we just want to like you, know the current state, if you just want to continue with supporting having that stand at hand at four six to both and our rational is just that if you come up with a if you report a bug which, on a supported platform uh which was using that standard, we will fix it, then maybe we extend the same thing to our contact, repo guidance and just tell the owners that you can add this. But it's okay to not test it using netcore, App 3.1, so click.

F

Yeah I think for now our guidance um should just be do what we do in the core repo um and if we want to further try to understand the ramifications of dropping the net462 target, we can pursue that, but I, don't think our guidance should change until we've done our homework. There.

A

F

And regarding testing you know we can write up that guidance. You know that idea that I have about well. If you're pre-compiler directives involved in that standard, then they should also involve some like a concrete runtime. In that way, at least you have the code coverage. Yeah unit tests aren't actually pulling the the net standard build binary, which is, you know, arguably, may still be a little dubious, but you at least have code coverage.

B

Yeah I think that's that's a good idea. We can update our Contour people contributing doc or, like just have a different section for this guidance.

B

I'll move to the next topic, then.

D

Oh I know this one, uh so I've been getting these requests lately. Just like people want to measure, they want to create activities like during the startup of their application, but they're using the extensions that hosting package like that. Just doesn't work for that flow. Is that right, like they would need to configure a uh provider using the SDK directly uh in order to accomplish that.

F

F

I think the answer is yes, um you're talking about like before you know, service collection has done resistant.

D

Yeah exactly like they're.

A

You know they're.

D

I, don't know they're doing something, weird, let's say, and it takes some time to do that thing and you know they want to. They want to be able to say that. Oh you know, the types of workloads I'm talking about here are like Eventing workloads where, like things spin up on demand and they live for some duration and then they kind of go away and they want to be able to say like oh, the startup was you know a significant portion of the execution time um and I just wanted to I thought.

D

The answer is yes, I just wanted to be like that's expected, I guess, I just wanted I guess conversation.

G

You you have, you have quite a few problems with that I've had quite a few customers asking the same things: There Is, No, Easy Way. Unfortunately,.

G

um You've got problems around if you've got duplicate providers. You've got two listeners, two activity, listeners running um you have to be really careful about which sources you are listening to. If you create a tracer provider outside of the hosting package, make sure that that's only listening to your startup things, because then you get two things listening to them and then they're all um going on. We've also had a um I can't remember where we ended up with with the multiple service providers in the same Apple.

G

um But we did have that problem where we were having two within the same service provider and within the same thing, so yeah.

D

A

D

Like simply said, like don't use the extensions package just just do it manually like then they wouldn't have those that duplication problem. It would would be maybe non-standard for that use case or something, but it would. That would be like the recommendation, I think, to kind of avoid all those pitfalls.

G

um Sorry log had a similar issue way early on um where you had to create two login providers: I think it was call 3.1, maybe 2.1 and before the emerge of the service providers, but yeah that was a very similar issue.

G

um I think you yeah, you can get around to doing it that way, but then you lose a lot of goodness yeah.

A

F

F

Cool, thank you regarding the activity. Listeners I want to say like if, like if you, if you started up your own providers, just for just for monitoring your startup code and say you instantiated them, and then you disposed of them after startup was complete.

F

Then I believe that any listeners also get disposed as part of that I I mean I'm, sure there's pitfalls there. If you don't, if you don't dispose of things correctly or something, but if assuming you've done things in that way, I want to say I think it should be safe. It should clean up.

D

As you were saying, I could try that thank.

G

You yeah I I hate problems with. When do you dispose um because you want to dispose just as the service provider gets built so that you don't miss things in between?

G

But when you want to try startup, one of the things you want to do is Trace to the point of first request, which, when does the service provider get built, and then my head got all meshed when I did that last time and I went it's fine, that's.

D

For like uh you're thinking of like a completely generalized solution like from if I know, specifically like I, do thing, X and I know when X completes right, it would be I think more straightforward to do what Alan is talking about.

F

Yeah I haven't worked through it myself, so there may be pitfalls.

D

Yeah but okay, maybe I'll, give it a shot. Thank you.

G

There's a plug in it there somewhere.

G

Because yeah I've had that quite a lot, so I'd be interested to uh to hear where you've landed with it.

D

Yeah sure I can let me explore and I'll I'll get back to you again think about something. If we want.

B

Okay, um next item on the agenda, so.

G

I added two things on there: um those two- those two are my things.

G

um So this one there was a comment about delaying the asp.net core, stable release until we have increased the performance or decrease the performance whatever you want to call it, um which I don't think, is the right approach, so I wanted to discuss that.

G

So yeah that comment from cgo there around um this is we can't release 1.1, oh until this is. This has been resolved.

G

Which I don't understand why we would block something that's being used by a lot of people in production?

G

Why can't we put that in at 1.1.

B

Well, I I mean I would say if it's already being used by a lot of people in production, then I think they can wait for a stable release, which is which is performing.

G

So we're both we're delaying this now that bear in mind they're using it. It works we're not proposing changing apis.

G

um Why would we have more unstable stuff from a user's perspective and delay until we've done the work on that, doesn't really make any sense to delay something like that.

G

We can release it and then we can make it better later and then customers have a 1.0 release, which is the same one they've already been using, but helps increase adoption because people are using non-pre-release packages unless somebody's working on this now- and you know it's going to be ready at the same time when the semantic conventions are signed off, which is that two weeks away, I think.

F

I think it's more than that I yeah I mean that was. That was going to be my comment so like really at the end of the day, um first and foremost, the semantic conventions are need to be stabilized before we can even talk about um what it would be to land.

F

This is stable, but I think that, because I've heard that the elastic common schema is going to be merged with the open Telemetry convention, somehow and I think that that is pushing out HTTP semantic convention instability a bit further to my knowledge, um I'm, not part of that working groups, I don't have like mortgages.

G

Yeah last I heard it was a couple of weeks away um because trust put a whole timeline against it.

F

G

F

I thought I thought I saw that he had bumped the timeline out further. Maybe maybe it's a different comment that I'm thinking of but.

G

I mean that's great because it means I, don't trust any beers, because I said, if he does it in the timeline, then I ordered him. A lot of beers.

F

Yeah absolutely validate my I think I saw something again, I, never know where I see things but I I think it's taken a little longer.

G

uh Was it under the was it under another anyway? What I'm saying is that the trigger for me for the 1.0 would be the semantic conventions, because that's the thing that's been blocking it and then, if obviously this is in first then no quarrel, but if the semantic convictions are there blocking it, because a performance doesn't feel like the right approach.

G

I'm trying to find the.

B

So we do intend to like release the stable version of asp.net core and HTTP instrumentation like we don't want to delay it, particularly for uh you don't want to keep it delayed uh like we as soon as semantic conventions get stable. I. Think that was the original plan like we don't we want to do it as soon as possible when semantic conventions are.

G

B

We would have we have a person dedicated working on this wishes going to be working on the on both these instrumentation packages.

B

So I can I, don't know. That's I wish CJ was here to like talk more about it. I hadn't looked into this issue as much and I.

G

Mean if that's, if that's what we're thinking then yeah I mean it makes sense. um It was just a comment that we can't release a 1.0 until the puff is acceptable.

B

Yeah in general, like that, like I, can only think of his rationale being, like you know, in the hot path you don't want to be doing. If, because right now, I, don't think it's optimized for like memory allocations and stuff, so it kind of feels a lot of people would have that expectation that, like of it, it will feel like I mean there are some ramifications of using a stable package which is not doing well in the hot path, and it's like open Telemetry is bringing my application down.

B

So we don't want that kind of image as well. Yeah.

G

But everybody's already using it is what I'm saying these people are using it, and these people want to use it in production. They're not bothered about the performance, and this is the people. I speak to they're, not that worried about those things.

G

What they are worried about is the security team saying they can't use it, because it's got a siphon pre on it um so and we can fix that we can do a a release of it, so those people can use it and then great, it sues our adoption issues that we've got because we've got a very, very decent path. There we'll have messaging soon, hopefully as well um that we can say yeah with our packages are stable.

G

But just because it's performance are we saying that people shouldn't be using this in production now, because it's not performant, because I don't think we are.

G

But I will look at this. uh Look at the uh where we're at with the um HTTP stuff, because yeah we can't do anything until that's done.

B

F

Also I might take that like CJ added this as a milestone, I, don't think, is a problem. I mean I think that at the end of the day, there's nothing like super concrete actionable that I'm, maybe I, haven't studied this closely enough, but I I'm not seeing anything super concrete and actionable um from this statement. Other than maybe you know adding a few more Benchmark tests, just just to have a record of what our our current perf is.

F

But I I suspect that, as we get closer to actually entertaining marking these as stable, because semantic conventions are stable, then you know we all we're. Ultimately, gonna have to come up with like concrete things that are really.

F

Would have deemed uh necessary for stability so until I see that list of of things like I, think it's kind of hard to talk about this in the in the uh abstract. I. Look at CJ's comment here is just more like yeah. These are considerations that we should.

F

That we need to think yeah.

G

I mean my my comment was more based on the fact that we've got I thought we had two weeks um and then we'd be able to release it so starting the conversations now rather than waiting for two weeks. But if we're not, then um obviously, we've got a little bit of time. But I can't find the thing at the moment, but I will continue. Looking.

A

B

And this other yeah I've gone to people yeah, so.

G

It's been an ongoing conversation um which was I think two weeks ago, were we on this call having a conversation about x-ray.

G

um And I thought we were talking about this particular one, um but I got the um guy who runs a lot of the technical stuff for AWS event driven stuff and that kind of stuff all of this area in.net to have a look at it and that's Jason on there. um I was a bit concerned about the approach for it, um which was if you've got two messages.

G

If they get batched up into one execution, the continuation of the message processing for Trace one for message, one is actually just child spans on Trace 2., and that was acceptable. Apparently.

G

um And I wanted to know what other people thought, because I yeah doesn't make any sense you scroll down to the bottom. There's an example.

G

um Yeah ignore the images.

G

There you go that one there.

G

So that, first one where sqs sends Trace one with span one and Trace two with Superman 2., the Lambda, gets triggered and everything ends up on the trace too. With links.

G

um That was what I was suggesting um if they can't do it with continuations for each message.

G

Probably not describing this as well as I thought. It was.

G

That does that make sense, because at the moment it was adding the parent. So if you've got a batch of messages, so you've got 10 messages in a batch. It was grabbing the trace context from the last message in the batch and using that as the parent context for all of the processing of that batch.

G

So it's setting that as the active span and then all child spans come off that so all 10 messages as they process in a loop, um then go off that that doesn't feel like it's. The right approach, um I'm, not hearing many thoughts on whether that's a um good thing or a bad thing.

G

Foreign opinionated about this stuff with the messaging because I'm in that space at the moment.

F

Yeah I, just have not been uh would you have describe, sounds not ideal, but I I just have not been had my head in this space at all, though I know that the messaging working group has been active for a while now as well as I, think there's a Lambda working group as well so I I.

F

Suspect they're.

G

F

G

Talking to Lou Miller about the um the messaging group, because um she's pushing that one forward um and service boss are making it optional. Basically, um you can either link it or you can make it parentage or never to um dump the messages from the whole execution in one Trace, that's parented by another message that was created.

G

But yeah I, don't think that's ready, I think uh I, don't think Oberon who's on the call, um but yeah I said I wouldn't support it in its current format because it would be confusing to users.

G

um The example would be, if you've got I, don't know, um say your message: sending is for emails and you've got a whole email, send process that picks up messages that have been generated by your website, so account signups and you get 100 account signups.

G

Each of those needs an email to be sent and they've got a message that needs to be processed process that sends the email.

G

If you process that in a batch of 100, you've got your Trace from the the account created that says. I've sent I've created a message um to go and send the email, and one of those then includes the email sending for the other 99.

G

Because the batch has come in, it's taken the last one of those parent contacts and then it's used that as the trace for all of the email sending.

G

So that's, then, a continuation of the trace of the last account created, and it just it doesn't feel right that that's the way it should work.

G

There's no great way to do this in a lot of libraries, because you'd have to hook into the the loop and that Loops through the batch and reset the um restart a um a span on each one of them and the libraries just don't allow those extension points. So there's no good way of doing it.

G

But even linking that the message processing for each of them doesn't really make sense.

G

But I wrote an entire blog post around spam links and async processing and all of this kind of stuff the. Maybe you want them to be part of a trace. Maybe you don't.

G

But I don't know a way forward and it feels wrong to just leave it and just go yeah I, don't know, don't do it, but it also doesn't feel right to say go with the approach. That's there because that feels like it would be really confusing.

G

Like more confusing than not having traces.

F

I just noticed at the very bottom of that period that there is a link to an Otep. That's uh I think I've looked over this before in a while about the structure of traces for messaging scenarios. Needless to say, I think it's complicated and I. Don't think that there's a one size fits all. At least that's been my impression yep, but also I'm, not an expert in the space. So oh.

G

Yeah I mean the. The extreme example is, you think about say, monzo, um which has 1500 micro services that are built on a messaging structure where one transaction can trigger up to 150 different services, and each of those can then trigger some more services where you've got one Trace.

G

That includes the interaction of 150, different services and you've got thousands and thousands of spans in one Trace and that's Trace would last a month because some of the things that happen off the back of a transaction happen a month later, which is when you move into the oh. Maybe we should have links and treat these as individual actions versus doing it. The other way and allow people to make that judgment call.

G

F

It looks like Christian um the who's Oberon has a comment on that Otep again, I'm just digesting this stuff now so I think it's on point with what you're after, but he commented yesterday on that Otep about this batching receive kind of use. Case scenario um you might chime in there with your opinion, since you have been thinking about this.

G

Yeah I can take it on there or just you know, didn't want somebody merging it or you know, there's a there's a lot of problems with that PR um and I'm, not a maintainer on there, obviously, but just yeah I'm open to discussing it, and what a good way is, but that way should not be the way I can understand why they got there, though,.

F

This instrumentation is not stable, are in.

G

Oh well, I said come trip on so yeah can contribs be stable if there's semantic conventions.

B

um Aws diabetes, a lot of them have been not stupid. This one.

G

It's the sqs one, which is a bit further down, I, think.

B

This one has been stable, the Lambda one has not been.

B

G

Well, this one adds the sqs stuff that wasn't in there before.

G

I think it just touches the sqs one. Doesn't it.

B

What's the sqs one I mean like this: the.

G

Instrumentation AWS yeah so yeah. It touches that um and adds a few different things. I think.

G

But yeah I don't know a way forward um other than you know. Semantic conventions and project approach hasn't been signed off, so we shouldn't merge it, which just feels wrong, because people need these things.

F

C

G

F

Yeah I spent zeros I'm looking at this instrumentation uh I guess. My first question would be is the is the plan that the next release would also be a stable release, or would it be a would it be a pre-release thing, while maybe the conventions for whatever sqs is stabilized I, think there's conventions out here, but I country I, guess they're not stable, always.

G

Messaging in general, so yeah messaging, isn't the the I think the only thing that stable is runtime? Isn't it.

F

G

Net yeah um I mean for semantic conventions. The runtime is the only one that actually has enough stable names.

F

Yeah, those were stabilized because um we, as the.net community, um are the spokespeople for the stability of those that is they're not owned. By that specification.

G

I mean I can put a note on saying: we discussed it and nothing conclusive came out of it, but we don't think we should be merging it. Yet, just so Christine's got at least a you know: we're not ignoring it.

B

G

I think as Alan.

B

Suggested maybe you can also put.

G

You on I mean yeah I can I can do some stuff on the other things I'm just more I know people who are watching that particular PR I have a very large customer that is watching that PR right now and pinging me on a regular basis, saying when is it going to be merged, um to which my response at the moment is I will build you a package dedicated for it. You are big enough. It's fine um and I will support it for you and we will do it as honeycomb.

A

G

um But I have people who are watching that.

G

So putting something on there to say what we're doing with it is useful I think I mean I can put it on, but it probably have more weight coming from from you guys really.

F

Well, I think, Christian and uh I don't know the guy's name. The guy who opened his PR are the code owners for this package. So you know it would be good to I mean I write that's effectively like they're the maintainers of it.

F

um It might be good to just kind of get a sense from them about what their plan was for. Releasing this um stable, not stable, um dependent on semantic inventions not dependent on semantic conventions, and it's just like you know, foundational context, I, don't think anybody on this call. It currently has but I think our good questions to kind of um know the answers to so that you can get a better sense like if this is going to be shipped right and it's going to go into a non-stable release.

F

um Then maybe there's less concern, but you know.

G

Well like, and here relies the problem, we've kind of conditioned the.net community that pre-release isn't a thing, and these things are basically stable, so releasing pre-releases is a bit of an issue because people would take it thinking. Well, it's just the new. The new version of it they're just being slow, um so I, yeah I can I can ask some foundational questions so that we've got some context.

G

A

A

G

um Anybody else going to be at cubecon next week, a few weeks time.

F

No in Europe.

A

F

G

There, yes, where the cool kids, that's where the Cool Kids Go.

F

Oh well, it's right in your backyard right I mean it is.

G

It's a 50-minute flight, oh another, one been added, sorry I won't fill time. Then six minutes.

E

That's just me reminding or asking people to go. Look at this. Please.

F

Oh okay, this is.

A

Ready now, okay.

F

Sorry, yep I can take a look.

E

B

I did take some like I reviewed a little bit and I have a few questions.

B

Hello, yeah I mean I. Think.

C

That'll continue to say, I.

B

Saw a few things and then I had a question: I asked I'll go through it in more detail.

B

Cool I think uh that's all, then we can end.

G

um Punch, do you think it's worth with that one to look at I think we discussed it when you weren't here um a few weeks back the console logging exporter.

G

um Is a separate package at the moment and it's pre-release if we're gonna, do some stuff around more consistent handling and stuff in logging. Do you think it's worth bundling that and getting the other thing in and merging it, because the log data model is stable?

G

Therefore, the exporter should be able to be stable.

E

I'm not opposed to that I mean I, don't want to tie it to this PR. No.

A

E

Basically, asking can we do a stable console in one five or one six I, don't see? Why not? It's not something I put a lot of thought into. Do you have customers that want to use the console exporter in like production scenario,.

G

Oh yeah yeah I mean that I have people that are using it, but trying to get that out of pre-release, and you know I know I'm a broken record. I want to get everything out of pre-release as soon as we possibly can. So, um if the stuff that's within our control to do, then I I would really like us to do it because it just gives a sense of stability.

E

Are your customers, like we don't, have a really machine, parsable output from that thing, I think like Json would probably be nicer for, like a production scenario, do you know what your.

G

Customer not the console exporter. This is the um the logs exporter, the otlp logs exporter. Yes,.

E

We are planning to do that like in the next few months. That's that's one of the items we have like on our plan, so someone on the Microsoft team will either take it on or if they can find someone in the in the community to take it on we'll work with them. But that is definitely like.

E

A short-term thing we want to do is get a stable, we'll, probably just drop that package that we have today and just move it all into the existing otlp exporter package, because the only reason we have that package is so we could have some of it stable and some of it pre-release so I think the plan is just to move it all in and have just a stable log exporter.

G

Yeah I wasn't aware that was on the romance. I know, I think it was me and you and Allen that we're discussing I think there's only a couple of us on the call at the time. um I started, wait and bring it up later.

F

Yeah sorry I was confused by it when you were bringing up the console expert, but.

G

F

Hotel P exporter, as Mike said we plan to fold it in also I mean I. Think I've said this numerous times, but the logs back is effectively like right around the corner, um there's just mostly cleanup proofreading kind of validation, which unlocks a whole bunch of uh log work that we have or Mike has, namely um enables us to land that.

G

Yeah, like I, said the the exports are part of it, though, um is kind of decoupled from that I think.

E

Yeah I agree with that: yep.

G

I mean honestly I would prefer that we don't do anything with logging and we don't spot the ilogger API and position Microsoft to get it removed completely and everybody should choose tracing. But that's a completely separate debate through.

G

But yeah people are using it the um otlp, export um and again questions around stability.

E

I, don't know if there's any reason why it's been pre-released this long other than just nobody focused in and pushed it over the hill to stability.

G

I mean the look: data model's only been because we wouldn't have been able to do anything without the log data model being ratified anyway. I think that was only January. Wasn't it.

F

Yeah that package was created career prior prior to the uh data model being stable, so yeah.

G

Yeah, so it's only been pre-release for three months that he didn't need to be. um Did anything.

E

Change in the data model between like experimental, stable, whatever.

F

uh Yeah there were some minor things like you know. There used to be a top level name, field, I think was probably the bigger thing, the biggest thing that we actually were using um at one point trying to do this, um but I mean in comparison to the other data models for like metrics and traces I mean the log data model is quite a bit simpler, so.

E

There are some eye logger things that made their way into our otlp exporter. Like category name, did we like prefix it with net or anything like that?.

F

I believe so uh and adding them as attributes, rather than the top level field. I think that was the change we made.

E

That would be the only thing. I would want to look at number two going stable.

F

I mean technically, you know the the the exporter is.

F

You know you gotta, have a You, Gotta, Have A bash processor uh associated with it I, wouldn't expect the specification, the SDK specification for logs to to change in any substantial way.

F

um But you know from like a real technical perspective that should block stability right, because if the SDK is not stable, then that means that the exporter interface and the processor interfaces for logs could change between now and stability.

F

Yeah risk is probably low, but I think that that would be the uh the reason to wait for the spec on this stuff.

F

A

F

At a time uh the good cars dropped off.

G

Yeah I'll drop some things on that um particular ticket and I'll see if I can find some more clarity on where the HTTP stuff's at the next week.

F

Sounds good talk to y'all soon adios.