Open Telemetry Uncategorized, 22 Jun 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: 2022-06-22 meeting

Description

OpenTelemetry PHP SIG Meeting

A

A

B

Hello aj welcome.

C

B

All right I'll take the minutes today.

B

uh We'll just give it another, we usually wait till five past asia. If you're wondering why we're not saying anything just for some light cameras.

C

So I'm not sure normally some of my team members and they join probably let's give a minute or two for them to join or you guys can continue. I don't have any specific topic to discuss, but definitely wanted to accompany and then be part of this meeting.

B

Okay sure uh you're quite welcome to just look and listen.

C

Yeah, definitely for time being, it will be more listening more. There are some of the discussions. Some of the uh topics which we are discussing internally within cisco dynamics breadth. uh Those are specific to the php.

C

uh The contribution with some of my team members are doing so, I'm part of those thing, but I am not directly contributing or doing any any specific coding essays on the php game.

B

Excellent, not a problem all right. Let's keep this meeting off um hello. Everyone welcome uh bob's, not here today, so I'll run. The meeting um I just want to quickly go through the open pr's. I don't think there's been a great deal of movement since uh last weeks, except perhaps it has.

D

Start talking me um well just go over the prs, then you will see the two at least a new one.

A

B

Yep, so we've got uh the oltp grpc exporters just been.

B

Put in yesterday uh sorry that one's still a draft, I think we'll skip over that.

A

D

Give me one second.

D

Oh okay, yeah, I was confused, was a different yeah. I was thinking of okay. Go ahead.

B

uh I've got one um uh trade for getting and setting the current span, which I haven't uh really uh really looked at yet uh so that was this is yours. I think.

E

Oh yeah um yeah. I think that was mostly. I was just curious to get yeah you're all kind of feedback and and take on it um yeah. I couldn't really see like a consistent story for how the other languages were were doing this and and then yeah. When I was thinking about it it just it seemed kind of like awkward to throw it on like any of the existing classes that were out there.

D

Yeah and because the abstract spam is overall.

D

Well, that's just my opinion, but very firm one um yeah, so you want to get the basically it's in convenience or an api to get the uh current spend stuff like this correct.

F

D

At the moment, a little bit.

D

Yeah, so where did you actually plan to use this trade, though.

E

uh I wasn't planning on using it right now and I think it was just like part of the the specs that I think you like should have something like this. If there's the implicit context and so yeah, I I didn't really have a super concrete use case and.

D

Okay, well, I um I understand the problem, or um what do you want to tackle with it, um since I still have a problem with this abstract spam thing, because it does three things uh at the same.

C

Time and none.

D

Of it are really well there's no single responsibility to anything in it. So basically there are some factory methods. There are some lookup methods which would be kind of a registry or a manager, whatever you call it, and then there are the two methods which are basically the base for the the other span, implementation so which could be basically put be put in a trace.

D

Sorry in a trade as well, so um so yeah. What should we do with the pr? So.

E

Yeah yeah, that's good. I didn't yeah, I didn't really. I think I went for the abstract span just because I was like looking for that, like from context method, not in the sdk. I think that was like the first place I found um so yeah. I can maybe look at that and see if there's alternative ways to do that, but I guess overall, does it like feel appropriate to have.

F

E

Right for this, um it.

D

B

Kind of implies, reuse, and you know it can be attached to multiple classes, which I think we're aiming for. One convenience entry point.

D

Well, yeah, yes, and no, but so what what I would suggest is that I can create articulator for that um that we do a little refactoring of all this abstract span, so move the factory parts and whatever factory and the others, and manage our class, it's always ugly to have a manner something called a manager. But sometimes you know things manage things um and then the two methods which are you know the base methods for the record. Non-Recordable spend the real, spend implementation and move it into a trade.

D

So you could move then this methods in kind of a you know, manager class where we can handle all these lookups and stuff like this.

D

So in this way it's a little bit. You know the concerns. uh It's not separate or really separate the concerns a little bit with at the moment yeah. They are simply not.

E

Right: okay, yeah: I think that makes sense so just having yeah like kind of a new new manager, style, class, yeah.

D

E

G

D

Better name then be my guest yeah.

E

Yeah, the name that was really hard.

D

Well, I mean we can just call it manager, so sometimes there are many levels and if we come up with a better suitable name, maybe change the future.

B

E

We've also talked about having.

B

An sdk object or class: um could that be a? Could that be a good place? To put it does it? Is it okay to live in the sdk, or is this an api level.

E

Oh yeah go ahead.

D

Well, at the end of the day, it just depends on the context which is already also available in the api, so it would be.

B

Yeah but yeah probably is an api thing now that I think about it.

D

Well, we so the how I already worked on this api thing and sdk stuff, and things like that. So in the most case it will be more like wrappers for existing functionality, not putting anything too much in there. It will be just you know, easier access to certain objects and stuff like this, and it will reduce the context as well, so we um well, we can still create this manager class or whatever it's called, and then you know create a convenience, ap or a function method whatever on the api or.

C

D

Access it, but it should be uh separated as well as because this api thing shouldn't be like a god classes. 12 months should basically just translate or call other apis or internal stuff things like that. So so I would just go with you know: putting a standalone something like a manager api which is static, and then we can um make sure that if we want to exit it differently or we may create convenience methods on this api object and stuff like this.

E

Yeah for sure yeah I can go ahead and yeah draft up yeah new version and yeah take a take a stab at the name.

D

E

It can meditate.

D

Over a few you're, a native english speaker, so your vocabulary, yeah.

E

Maybe yeah probably.

D

A little bit broader than mine, so.

E

D

E

Can write? Sorry? Oh no yeah! I think that yeah. That sounds good yeah. I think that's the kind of feedback.

H

Yeah that's important.

D

I will just write a little uh ticket later on. You know just what to do and just broadly and then you can take care of the income yeah yep.

B

Pr is my one which was adding an event dispatcher uh that has had some had some review and feedback um uh which I've actions. So it's just still going through the review process, um still open to changes and improvements.

D

Yeah I have some remarks on that yeah. I will add some um some specific comments to some. You know nitpicking stuff from me, um but you asked me for like more like a general um thing about, um and we talked a little bit about it. So um one thing.

D

Well, we talked about this api stuff, and so it's the um the event listener should basically, I think, sit on this one and.

D

I think it should be good if there would be also um well. I would you know we talked about the psr13, which is the.

D

um uh Dispatcher, yes, it's patcher um interface and I don't think we should rely on it because you're correct, we cannot rely on there being you know, listener or anything. There's no api defined on how to actually configure a listener or whatever um you have. So we have to come up with our own implementation to make it sure anyway, and then we don't need this piece. R14.

A

Implementation.

B

With that yeah yeah psr 14 is not not useful in this. Yes,.

D

And there's also one thing: it comes with this um stoppable event, stuff, which is comes from symfony, and it's a really bad idea, because it will um that's not how events should work, that you can just stop them from bubbling or something. That's, maybe you're something between a dom object or, I think that's where they got from, and I know how symphony use it is, but usually you should have something in between which takes care of it.

D

If you don't want to handle an event anymore, then you don't propagate it to the place with another place. You know, um that's not something event to itself. You know know if it's stopped or um or things like that, so um I never liked this part of this api um and yeah.

D

Then I think we should have like a new uh event listener, which you know um we can return when basically there's no one set and then if we set the um the event listener, then basically it works so and from and then you will be able to access this from this api object and or the sdk object, and from what how I thought of designing as well, you can can have different event, listeners or none or one in different signals, so, for example, unlocks or in the um tracing and then the sdk as well.

D

So um in this way we can just turn this functionality on and off, and I'm not quite sure about having everything in the api. So you moved a lot of stuff in the api.

A

B

uh Yes, I did all of the event stuff and logging as well, because that was a dependency of our event, handling, which is our default event. Yeah.

D

While we moved to logging stuff something yeah well, I mean.

D

And I'm not so sure about at the moment the these um events or the logging handlers will be. um Her default will be activated right.

B

uh Activated yes, but won't do anything until a uh a logger is provided. Okay,.

D

Well, what I'm always concerned a little bit with an event implementation, this event spamming, so that's, um basically, events are created and nobody's listening for them. You know that's the notion of um of uh event um or event based patterns, but.

D

It can be a problem um and give me, because I just want to talk about a few things, because I don't want to write so much world of text there and at the moment the events are classes right, yes, okay, and how do you create them again?.

B

uh How do you create them? Yes,.

A

B

You knew them at the time of emitting, creating an event to admit.

D

Everything we have, there are basically um login based events right, that's correct because it would be suitable. If you have to swear um to. You know, extend the functionality for other events which might be useful to not, for example, you know plug-ins or stuff like this or not not just um having the um debug events, but I don't know it could be adding a plug-in or trading spam or whatever. So.

B

Yeah so I mean the event's, probably more useful for future extension than you know, using it for logging at the moments is interesting, but not not a great deal better than what we. What we already had.

G

um That's not a point, I think we should study if there's a free for logging, because that's the solution, most users we already use instead of configuring, our own logging system.

G

What do you mean um it's easy to it's easier to configure the logger instead of an event listener to handle the logs.

D

Well, yeah sure, but there will be nothing to configure for the user, because that's just the uh indirection we use I mean, and so the events could be used for uh other stuff as well and that's something which we have to. um We have to provide callbacks and stuff like this for um for debug events, so that's part of the specification. That's why we actually use it and the logger will be set up as before, or actually it's already even easier. So um it really doesn't matter.

D

We can move, still have the logger at um at where the events are produced, but there will be them kind of an overhead, so I'm not set on any of that other than.

B

E

B

Don't definitely take your your point to bias because uh you know we can configure a psr3 logger to you know not listen to debug. You know you can set your minimum levels and uh certainly with you know, I suspect, with monologue.

B

You could, um you know, write a plug-in or a filter or something for it if you, um if you did, need to filter out certain types of errors, so I think yes, I think that everything that the spec asks for with respect to sort of errors and warnings and whatever can be done just by psr3.

B

um Yes, so the the only reason and I'm happy to undo that bit, but um we when talking about it, realize that we probably do want an event system at some point for other other things that are happening in the library you know for sdk internal stuff. Mostly, I guess.

G

D

Yes um also for the apis, because um it's part of the fact that the api should also be able to emit useful, it's not really super um defined. What actually? That is, but um there should be a way. um Do you have the ticket at hand.

D

Well, there should be a way in the api to expose um quote unquote, useful data or whatever himself um reporting stuff like this, so it should be um yeah on the ipi level. That's basically what we're trying to implement and the logging is basically just hooking into that. So if we use the events, so I'm not really super set on that. So.

D

Okay, and so how should we proceed uh proceed with the um pr threats? um I have some little things I would like to change, and otherwise I would rather merge it first and then we can iterate on the stuff. We have there because in a pr it's always, you know with a lot that many files is always a bit hard to see how it works out. At the moment I mean I can check out your branch, but you know what I mean.

D

B

uh Yeah, I'm certainly happy to merge it as is, but do we want to at least come to a decision on whether logging is logging, is logging of errors and warnings etc?

B

Different, and does that just straight up use, you know psr3 um as it did and then the event system is there for it's basically sitting there and unused, because we don't currently have any events, but we do want to have all internal events from you know from the api and the sdk or whatever um that it's there ready for that.

D

um Yeah, so maybe it would be possible to that. You just um create a reduced pr which you know just has the basic implementation for the um api. So just the um event, uh basically just the events system without any implementation of an event or something like that.

B

uh Yeah yeah or I can pick something like a um let's say: exporter export has happened, type event or something. um Yes, it does um I'll invent an event that we think might be useful.

D

um No well, what I mean is: um can you just create a pr with basically just the um subscribe system? So um so the uh the um event dispatcher implementation, or something like that, so that we have that in the api, because um so basically just the um barebone um stuff. We need to have the event system there and maybe uh for the dispatcher that you can create a null dispatcher which basically does nothing and the concrete one uh yep yes and then yeah an inter in interface for it.

D

So we can rely on the interface and the api and then.

D

Yeah, I think it's easier to reason about it. If you know um go in that direction and then we can um build upon of what we have there. You know.

B

uh Yep, I can do that. Okay,.

D

Because at the moment um you know how it is, if there's such a big pr, it's really hard to you know, decide and really review everything you should know, and so that would be great so that we have line and just the dispatcher and api and then I will create a little pr which just has a barebone api implementation that you can rely on the logger stuff and then we can work from there.

D

So I don't want to close the um your pr, but maybe create um yeah extract just the basic stuff from dpr and create another one which we can match first and then um go from that and you can adjust this pr. Then.

B

Yeah yep: that's fine I'll either reduce the scope of this one or create a new one. Whichever you'll see.

D

I would just suggest you create a new one which and then rebase the other one, this branch on the new one and so um yeah. So this will be more the implementation, and then we have something on the api level, something barebones. So that would be great, okay, okay and then, and then there are other ones there, where some little nitpicks on this, I can write it like because you were exposing a generator and stuff like this, which is not always a good idea, um but yeah.

D

That's just some need to picky stuff, but I can um add it to this one and then we can, um you know, get a decent traction in this regard. So, okay, okay, cool, um good, anything else to this full request uh to that one. No, not for.

A

D

Okay, then, we have still the good.

I

um Can you share the screen, I mean so just get just to get the idea what we're discussing about sometimes it's uh very easy to lose focus on.

D

Yeah brett, can you share your screen and I'll show you a screen.

B

We'll find out now I've got so many tabs open. You can't read them anyway. Well, that's not many tips.

D

A

B

D

That's nothing.

B

B

This is the one that you want to talk about suck it.

I

Yeah, yes, yes, so previously we would we dis. We were discussing that we should implement the fiber or put a retriable span uh into a separate cube, but I check with the grpc default implementation, so it works in a synchronous way. Only so jrpc will wait till all the all the data has been exported properly or the retry is times out, I'm down. So it's so it's a simple blocker way. So that's why I thought it's.

I

uh Let's keep it that way, and another problem with the fiber approach is that it does not support 7.4 and 8.0 yeah.

D

I

Php module does support it right, yeah.

D

We're aware of that, so that's a problem. If we um move away from 7.4, which we probably do in half a year when it's um end of life, then we can do all this uh php8 stuff, but for now.

I

Still not, but 8.0 is still there, which does not support fiber.

D

Oh well, there's yeah there's an extension you can use to on support file on if people really want to, but it doesn't work for php 74.

D

So we could, um you know then make this extension requirement or make it work. Only you know have an exception for stuff like this, but at the moment we cannot depend on fibers being there so um yeah. So the gist of it is um that we can. The only thing for grpc at the moment is well, it still blocks and there's nothing. We can do about the driving.

F

D

Yo, um okay, then wait a second.

B

I might just add a comment that perhaps we could have a way to turn retries off um just because I have been before in production of um uh a collector effectively. um You know going down and being very, very slow to fail, and then uh you know apache or nginx or whatever. um You know, using up all of its available connections, because everything's waiting, 10 20 30 seconds to time out multiple times to to send um scent traces, um and I suppose my personal opinion there is that it would be.

B

um It would be actually preferable to just have logging. Not work then have my application not work um if there's something wrong with with sending traces. So um if we were to.

A

What do you mean by logging? You mean um sorry, I mean tracing yeah, a lot of.

D

Traces, it should be it's a it's a cross-cutting concern. It should never impact any application. If it does, it's really a problem because other than tracing back and no applications main concerns.

D

And if it's making, you know money, well, it just shouldn't bring it down. So I I'm um well. We I have another look into it and well, but I agree, but I think you already implemented that right so that you can say yeah so so, basically the uh default would be zero, then, for three.

I

Times no default, if you, if you implement, if you uh set the retrace policy, then default will be five, but if you don't say that set the return policy by default, which is disabled so at that time retire is zero.

A

Oh okay! Well, that's! Basically what I recommend that's.

B

Fine, that's exactly what I was asking for. Yeah.

A

D

No, I think we already talked about that when you haven't been meeting with someone.

I

Yeah yeah, so the thing is that I don't have a specific, enable disable parameter. But if you want to implement, I mean uh enable the retry policy. You have to set the retry policy. If you do not set it, then then it consider disable.

D

Okay, that's fine because yeah! Well, we talked about this. We have to make sure that it works in all. um Yes all run times so old ones as apache, and you know they cannot time out because okay, then we have a look and then everything. Finally, I see no problem cool, so we I just I guess we three maintainers didn't have much time in the last weeks, because we are persons as well and sometimes we have private life and things like that should happen.

D

Yeah, okay, but um it's fine! You can remind us all the time, so don't hesitate on doing that, because we have to a lot of things to have in our heads or some stuff, which you know usually don't see. We have to work on. So it's could be that things just get out of our minds right right. So no problem reminding us on any things.

B

All right um is there anything new here.

A

Did you do we need to talk about this or have it reviewed or? Oh, that's.

D

Just an um well, that's just one change of code. You can actually it's basically um there's a. I made a mistake in the dependency and actually I found a bug in the staff tool on.

D

You can write an essay about it, but don't um um yeah. So this, maybe I can say something to us, so um we have finally finished more or less the implementation of the separate packages which we have so this is basically was a part of it. um So now on every pull request on the main repository and the contributors repository and the packages are distributed as separate separate packages. Maybe you can open the main or readme.

A

Yes, I can well, you can just open.

D

So now you see the um at the top of the page, which are the packages we just reviewed. They are distributed in the additional repository which we have, which is called telemetry php, and they are split from mono repository ones, on every pull, request and and just reboot. Is there also the generated code which we may thought about hosting somewhere else? That's very separate there, um and the packages are also at the now on every um the ci process actually checks.

D

If the package are installable, if they're valid and so on, so they should be um installable um and that's basically one thing: it fixes so I've written like a command for it. It's a little bit tricky to do this, but I don't want to go into any detail, and the next thing we will have sometime in the future is basically testing the main repository testing, but the contract. Repository, though that we don't break anything there.

D

So, basically, um it's a check um which uh executes the tests of the contract, repository against the um actually the main branch of the main repository, and it won't be a checked which denies merging, but it will make sure that if we break something and the control repositories were at least aware of it, we can create a trigger to do something there and otherwise, or actually it should um should be.

D

We should implement some um backside compatibility uh stuff, which we have in the package at the moment, so to upgrade anything but- and that's said and done so now we have the packages and that's why I will we probably uh well we talked about this. We will make the main package which at the moment is open, timer to php. um Well, the mono was in make it a one-stop shop which comes with you know, just for testing stuff out and getting started, which also already comes with psr implementation and stuff like this.

D

So because people should be encouraged to use the separate packages now if they have any dependency on our library and the main packages. Basically, just you know for trying stuff out and yeah having a one-stop package, basically for um for working with open television right right right, okay, good! So then we got this from the table.

B

All right, uh the only other thing was uh new issues, so there were a couple that um tobias put together uh sorry submitted um last week.

B

I think that they're fairly self-explanatory, uh just things first fix. Let's move towards uh beta.

D

D

I also added one: this is a very minor thing. This is a depth track baseline and so that track is or on dependency validator. So it basically takes care that um different signals or packages don't have a dependency on anything which could be a problem so um so, for example, the api having the dependency on something in the sdk and stuff like this, because otherwise we couldn't create packages from it and there was some error which shouldn't really occur. That's now in the there's, a baseline file um and the repository when we can.

D

So, basically, just so one exception on complain that the sdk was having a dependency on something in the api, which is totally fine, and I don't really know. Maybe it's a bug in that trick or it shouldn't really be an error and because that's allowed so that's nice to have for someone you want to look into actually the problem I didn't want to take any time.

B

Okay, so that's just the first thing that made the the error from dead track. Yeah.

D

There was only this one error, which is, I think, it's a false, positive and yeah the class.

G

Is in turner, like, I think, that's the course just oh, I could use uh episodes or something like that.

D

It's internal. Is it okay? I didn't really look into that. I just you know. I just went ahead. Okay, that could be an issue. Then I don't know if it actually um checks. um Well, probably then um that track checks, the uh internal attacks and stuff like this, but okay, that's good to know, then um thank you good, um but that's just a minor issue. That's really um nice to have it's not really a problem because well, I think we regard the internal as being the whole package.

D

I mean it is an interpretation. You know, what's what's internal, if it's internal to the api to okay, anyway, um anything else, we have to talk about. Oh yeah, we have the our friends.

B

uh Yeah, yes, there's some some aws people showed up and uh there's a bit of a thread on on um yeah.

A

D

um Yeah so first the first issue I have with it: what do they actually want to instrument them, so um the aws sdk is making calls to the aws api so um and it usually does this well, it has a heart dependency on guzzle, which is bad, but that's how it is, and I don't really understand what they really want to instrument there so the time or what has to be so. They want to trade traces for um for requests to the aws, endpoint and.

B

So it sounds like they have, they have a library or a package, and they want to instrument it well.

D

B

D

Sdk, it's a really monster of a package if you've I've used it in the past, so it basically it has a separate client for every aws product. There is, um and then you know it just it's basically just a wrapper around and does a lot of stuff like this and like it said like I said it has a heart dependency on guzzles. So there's no!

D

um You cannot choose your own implementation, so um I think it uses brother five assists or both, and so my question would be first: um do they want to actually propagate traces to send um with guzzle with the requests traces to the aws endpoint? Then? Why so will it does the aws endpoint send anything back regarding traces?

D

Does that at its own traces or stuff like this, um and I don't know well if they expose something or if people actually want, you know something back and then the other point is then you can just create a rapid repertoire span around the requests, so that wouldn't need any propagation because it doesn't transport anything. But um so this was would be my questions in the first first place, but the other point, of course, was that we are at the moment.

D

We have no extension point for um for well instrumentation and stuff like this and that's correct and I've looked into the implementation of javascript and python. I don't really like them too much and especially the.

D

Calling some instrument function.

D

D

The only thing is, um since we have the api we could. um I already thought about ending extension points for instrumentation and plug-ins. So plugins are the intern um internal stuff like spam, processors and exporters and stuff like this. It's called plugins in the specification and the other thing is basically instrumentations, and so the only thing the instrumentations need basically is an access to the um providers so to tracer provider and things like that because and I've seen in javascript, they get access to the tracer, which I don't think is ideal because they need to.

D

We need to use the um the what is called now the scope um uh right. You changed it uh instrumentation.

A

Instrumentation.

D

Scope or library, um because that's actually the point why this exists so to create different traces for different light, instrumental lighters and stuff like this, and if you just pass the tracer and it's just the same tracer, which is used everywhere and then there's there's no use for this instrumentation scope in the first place. So I think, for my understanding, instrumentation should be handed the um the providers for specific signals and not the complete implementations.

D

Does anybody have any other ideas.

E

um uh Yeah, so I um I looked into this a little bit for the aws sda recently um and yeah. I think they, I think they do. Let you bring your own http client, I remember correctly, and so, if you don't want to use the the hard-coded bezel but yeah, I think the issue I was running into is yeah. We don't really have a pattern right now for, like instrumenting yeah.

D

That's okay. um I've already have this inventory. I can implement this just as an interface, so we can hook into this and then we can see what we can do later.

C

D

So we um the only thing there should be some extension point that they can access and have access to the tracers, the tracer provider, whatever an instrumentation needs. It could be also the propagators and things like that, and then we can create an interface and um I've seen. Javascript has like a base. I don't want to create a base, a class, because uh I never.

B

Want to create a base.

D

Class and other rare exceptions, but you can create and trade in an interface and then people can use this. It should be rather straightforward and then you can see how to work with that. So um I can create a draft for that. That should be very straightforward and because, since I'm working on this api stuff, I can you know just create an interface when, where this can basically be accessed um yeah the only thing and um I can create a pull request, if anything, everybody anybody has any regards or remarks to.

D

If I did something wrong or there should be something important to them, can of course feel free to change it or we can change it um later as well. So, but this is how the thing I think we should add and then other than that there should be no yeah from the interfaces. The instrumentation should just rely on the api, and then you know the api. Just should just have an access uh to get the trace whatever there is.

D

If it's just the api, then of course it's important or the remote implementation switch or the null implementation we have there, and otherwise it would be, of course, a tracer provider or a global one or.

E

um Yeah for sure yeah, I think that'll, I'm I'm assuming that'll get them most of the way there. I think I'm I'm not super clear on how they're like how they're thinking their instrumenter will actually like modify the aws sdk, and I know.

D

Yeah, I don't know how they they want to bring it in so from yeah. That.

E

Might end up being another conversation, maybe.

D

Yeah, if I would be aws, which I thankfully or not, um I would just move a little bit into the main library and then.

E

D

Otherwise, you have still either had a look yesterday into the sdk as well. It creates clients for every different product and it's kind.

C

D

Very complicated, it is how it is, but um I'm not sure how well maybe they know better how you can create like a record class or something which then hooks into this.

B

D

The aws sdk and this um to because basically um not super complicated, so you have to wrap every of the calls um of the sdk calls or client calls which do something which do a request or the outside into a spam right. So that's not super, so um you could create just a wrapper around it, um but this is still something um still something. If people you cannot just implement it, because people will use the concrete implementation of the sdk and we cannot just.

C

We cannot just replace it.

D

Other than with um some extensions which we may use for which you know, can manipulate classes or stuff like this or a monkey patch. So we have talked about this a while ago.

D

So I don't know how they want to do it, but we can provide an extension point to add instrumentation, so they get all the stuff they need so access to all the basically the public api which we provide to create metrics and yeah. Okay. So that's the only thing we can do and for other instrumentations yeah. Then we can see but um yeah, I think for now. That's the only thing we can do in this regard and then they have to take care of what they I mean it's kind of opinionated.

D

Anyway, always you know, what's your instrument and what you try to stand for.

D

And the best case instrumentation will be configurable but yeah, I think that's. um I will take care to um create a draft for, from extension, points from plug-in point. What javascript is calling is again a plug-in but yeah. I would rather stick to plug-in to something with the specification called struggling, which are spam, processors and so on, and then have the other things. You know just call instrumentations and then yeah they can have in the api and the methods at instrumentation, which basically would be the same activates. Anything.

E

All right cool, yeah I'll I can give them a quick update on the slack thread after this then yeah, and then they can, I think, watch out for for your drafts. Pr, probably.

E

D

It's not like. I have my personal opinions, the opinion of us maintainers. Of course we want to have instrumentation for everything on possibly so yeah um and but yeah. At the moment we don't have many instrumentations, because we're still working on the main library and then all right.

H

Doing all the instrumentations.

D

And then updating everything we break stuff, so um I already had to fix a lot of aws stuff. We have at the moment which wasn't really my biggest pleasure um and yeah. So that's basically um button when we provide an extension point which you shoot for the data, then all the things.

E

F

B

Okie doke um all right, that's everything off the agenda uh uh quick go around. Does anyone have anything that they wanted to raise? That hasn't already been covered.

A

Remarks complaints, confessions.

D

No okay! Well, I mean we're due with our time. Usually we.

D

Well, we already talked for nearly an hour um and I think, if anything comes up, then feel free to contact us on slack and we try to answer or like we said we already sometimes have a private life as well. Otherwise um you can, of course, create tickets and use all the other methods to open issues, remarks and clients.

J

Yeah sorry amber here I was working on one ticket 704, that is on creating attributes during span creation, so going to the ticket and going to the documents yeah. You can open this one, it's not there in the pull request.

J

Actually yet so, actually there are many many attributes defined in the documents, so like uh 25 attributes are there in the general attributes only and then there are http attributes and many more so for this ticket uh uh do I need to uh define all of those attributes or should I give preference because in the attribute remarks requirements some are recommended and some are required also so at this point of time, do I need to define all those attributes, or should I give preference and some of the attributes? Now you got my question.

D

Well, I think we made it easy and just pointed to the spec: did we create this ticket in our meeting brett.

B

D

I cannot really remember so, maybe if you um it's a little yeah we can. I think that was something that came up with or.

B

Yeah, we were just going through the uh the spec compliance matrix and looking at what we hadn't.

A

D

Okay, okay, um yeah, then maybe you can look into this or I would walk on.

G

Well, I think uh yeah it was more about that which should be defined at creation time rather than set in the span, so that samplers can utilize. These attributes.

D

Not in this pen itself.

D

Well, I think then yeah it's rather simple yeah. If at the moment the attributes are set in this band, and so we will probably just move it to the spam builder and then it's the all the attributes we um pollute to populate um at the moment.

D

But brett can you just asking.

J

B

J

Yeah, can you click on here, yeah.

J

Please go to sampling description.

J

This attributes, column iii.

B

B

Yeah all right does this looks like I I think it's I think it's just asking for it just to document that you can do it this way, but it's preferred to do it this way and that's that's all.

J

I just send the link.

J

Yes, yes, so these are the general attributes. I think.

B

Yes, but we're not asking you to implement all of these.

J

uh So exactly uh what should be uh the in that in this ticket what we have to exactly do requirement.

B

uh Find somewhere to document that the preferred way of setting attributes is in the span builder.

B

I believe, that's all all that it's asking.

G

Yeah, if you can go back to spank creation, there's a bit more. If, if you click on the link, it should better yeah. That's not a point attribute boots.

G

It's because the samplers only consider information that is already present. That's all we have to document. I think.

B

So we think it's just so just this point here so literally just a documentation um and it could even be confirming that our documentation uh already says this, but if it doesn't, then then we need to document it somewhere so that we can check it off the spec compliance metrics.

A

Oh yeah, it wasn't the matrix right, yep yeah,.

D

B

So it could be that we already do this like there's things in the spec compliance matrix, that we've done, that someone's forgotten to check off, or um so we just.

A

Want to verify there are also.

D

Things in there, which really are not defined what they actually meant. So sometimes, yes, you have to actually figure out or what's actually meant with um what has to be implemented there, because oftentimes there's no link to any specification apart and it's just mentioning something and.

B

Yeah, so probably for you that's some direction for you amber. I would, I would say the even just the php docs, for uh that um spans. A span at attributes method should just comment um just almost exactly what this is. um It is prepared to add attributes, span creation.

D

Yeah, that's kind of awkward because it's just documentation and there's no reference to any api documentation. First so and it doesn't really say which api documentation so probably is meant api documentation for the implementation or for a library, but as often in the spec it doesn't there's no context given. So it could be any api documentation or is it.

D

Tracy yeah, it could also be the api documentation we're looking at, um but my educated guess is that it means we have to have a documentation for the api which mentions this point, because otherwise it's already mentioned well, that's this recipe, yeah.

B

Yeah and the php docs on the method is probably fine for now, because we have very little documentation on how to use the api, um but we need it.

A

At some stage, so the ticket would be more creative documentation for the api.

A

D

Yeah anyway, we know about it and that's another point, because we're just still moving things around so and we don't want to create lots of text which we have to change other week. So um that's just an excuse, but uh it makes me feel better.

B

Yeah, the truth is we just don't whatever I need documentation, yeah.

D

Developers don't want to write documentation, oh surprising,.

B

I will write some documentation one day, yeah.

D

One day um well, we have to, but um it's rather it's better easier. If we have a better state than we can actually don't have to change things around so much potential.

D

Okay, um are we good with this or do we know more investigation about what's named through this statement in the matrix or.

B

uh Have we helped you at all amber.

J

uh What I got from the discussion is: it's mainly uh for the documentation right.

B

Yes, only document.

D

Yes, but you can put ask the founding fathers of the uh whoever put this comment in there and what he or she actually, because.

J

I went through the open, tele telemetry python uh repository also and there I could see some of those attributes defined uh during span creation, so I thought we have to define those attributes also.

D

Directed to users when they should add additional attributes right, I can honestly I can only interpret which is there. So, um of course, I didn't write this part of the specification.

D

Well, yeah, it's basically just guesswork, so your guess is as good as ours. I guess so.

D

We can find out who wrote this and you know, check him or her down and ask this person what he or she actually remembers.

J

Okay, okay and so can you.

I

J

The ticket also in the comments that what exactly is required defining attributes sure we can. Let's, we just wrote this very.

D

It's kind of little bits strange that a small point in the documentation is required in the matrix.

D

D

Okay um from anything else, we have to talk about.

D

Okay, when brett, we will listen to your closing arguments.

B

uh I think meeting adjourned. This is this is the longest meeting we've ever had, which.

C

B

Thank you for hanging in there.

E

Yep catch y'all later.

D

Yeah have a nice week, everybody thanks very much.