Open Telemetry Uncategorized, 11 Aug 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: 2022-08-11 meeting

Description

Instrumentation: Messaging

A

B

Hello, how are you hi, hello.

A

I'm good, how are you very good.

B

Oh good, as well.

B

All right, let's give it some more two minutes, maybe and then.

B

We can start.

C

Hello good morning.

B

All right, don't forget, to add your names. I put put the posted a link on the other chat I'll start.

C

Sharing my screen.

B

B

B

All right so from last week, um I I'm not sure if I did last week about the other before, but just wanted to circle back on the attributes there. I would push some changes for the what we discussed for the temp destination and the anonymous destination. So I marked them as boolean. I change the type and I also slightly change the the text around it to say that this is supposed to be filled only when it's it's temporary or or anonymous.

B

So the requirement level is fixed. Now that was pending.

B

So that happened and yeah apart from this uh there was the issue opened by ludimila, uh thanks for that and about the discussion that we have been having about what to do with the context or or what the context should be. um Yes, so I think if nobody has any other topic, then we probably should uh continue with that. I guess uh either that or we go through the attributes, um the I don't know if any uh any anybody other than ludmila that was um that was answering here, took a look at this um yeah.

C

Yeah I actually suggest that we park this conversation and I think it changes a lot right and we don't have an answer. I think what can change things if we get more information like if somebody implements it on the backhand and says: okay, this option is definitely better than the other right. um Otherwise it feels to me that we will have this conversation once the spec is out right.

C

The pr is back and then we will have to have this conversation with christian, and this I don't know, maybe bogdan will wake up and decide to participate, but for now it's not up to us to decide and we can just stick with one option but keep it up and- and um I actually I don't- have a strong preference here so and until it's not productive, to go and discuss it more and more.

B

Yes, no, I I agree. Yes, that makes sense um yeah.

B

So there was this uh here and we we uh ludwina brought in the spec call this week and yeah, let's see if, if others join on the discussion on the discussion here as well yeah, but I think the way uh one way or the other uh would not affect too much um on on what we're currently doing so it will affect whoever writes the instrumentation and so on and but for now I think it doesn't affect us too much, but I think it was a good progress that we opened this now and it's there at the broader group and folks are somewhat aware of it because yeah you presented it during the call right so.

C

Yeah, it takes some time for people to learn about what we are doing. We feel sometimes that we went too far from the general stack and it will be very hard to return. So maybe we should keep doing things like that, bringing it up to some controversial stuff.

B

Yeah yeah. Definitely I already did my my share with my uh dlp pr uh recently. uh Yes right so, but uh yeah I'll keep vlogging, and I will I will definitely uh already. This is have a vacation heavily seasoned right now here, so um I will definitely bring this up internally here uh to to gauge what they what they say about it. um Yes, so then, let's yeah- let's uh I will add here that we will park this for now.

B

B

B

It sounds good, I guess I just we recorded the decision and what would be what we want you want to discuss today we have the destination that we parked as well. uh I think there was new comments on this recently, so we could take a look at it from christian.

B

Let's see last time that we discussed, I think I I wrote there in the comments that maybe we should step back and and make this required and leave the give. Some suggestions, of course, don't leave it completely um random but give some suggestions, but ultimately leave how this is um combined and and and structured by the each uh each it each matches his system uh area yeah. But christian christian made some points here, which also also makes something.

B

So that's what I wrote here that we can could make it require, because this was something that johannes was uh was. I remember that he was concerned or trying to to get it to this point that that we could could make that we can make it require, because there is always something that we can put there, uh but the problem that we have now is that we it's a lot of combinations and tricky to to to find out how and and which system is different and so on. um Yeah. So that's what I wrote here.

B

Maybe we can make it required uh and then give some hints how you should populate this, but not go extra mile and try to spec out every single detail of every single messaging system, uh but that that was um that's. What uh christian here says that kind of opposed to it and and that we definitely need to do some definitions for pure system, um uh because it doesn't it's a good. It's a fair point right that doesn't want to leave the the instrumentation to decide on your own.

B

How to do this, but I don't know how much work it would be for us to decide to define, uh because if you remember we have this list here and probably it's not an extensive. Probably there is some other messaging library, messaging, abstraction or system that we didn't cover here here so yeah this. This is.

C

About the destination.name right.

B

Destination name exactly yes,.

C

Yeah and we can not really make it required well unless we change its meaning, because it's in some cases, which is rare, but still it's from massachusetts,.

B

um Yeah, we know a case already that this, that is, pyramid such as the kafka, one, that we saw yes.

C

So if we need to have messaging destination name- and we need something to be required, then we cannot put topic or q name there and make it required right. So I assume that, like overwhelming majority of cases, even though it's per message, it will be the same.

A

C

ah So but then it means that it it's conditionally required. So if it's per per batch or if all the messages in batch of the same destination, then it should be in the published span right.

C

But then there is this bot. uh If, if otherwise it should be in links and then it cannot be truly required and do do, we need it to be this strictly required.

B

um I don't think we need, but it's just because today it is, I don't know yeah we can change it. Definitely I guess, because that's not stable anyway, but I just think that, uh like you said, I think most maybe maybe I'm wrong, but most of the case probably would there would be a destination clear like topic or q name right and it would. It would be beneficial that you have that there, but I just think if you make it not required and um if it's gonna open up for this not being there because yeah.

B

um But I guess if we uh specify in a way that is clear, then most of the case will be there and it will be populated. So we should be fine. uh We do have conditionally or conditionally required right in the requirement levels. Okay, but we don't have conditionally recommended.

C

Oh, the the recommended is something that you freely use. It's just the conditionally required special case. You can specify conditions for recommended, but since it's recommended the conditions are recommended. So it's just.

B

C

B

Yeah sure, okay uh right, so what we could do is we could make it. I think I agree that required is not probably and we can make it conditionally required. um I think that that sounds good um unless anybody else has opposed to it, but we could make it conditionally required, but then how do we specify all the details.

C

B

C

B

Let's try to write this down otherwise, so.

B

So we we have it conditionally required right, maybe I'll put on the word here, because otherwise I can press enter.

B

Right, so, if we have it conditionally required, that means that we need to specify like some sort of conditions that has to be meant in order to to to be added right and that and that interchange between systems.

C

Yeah, let me actually try to make a stop on creating this yaml file for or messaging but next week, and I can start data to this or tab and we can explore it. I think like providing this yaml file, will keep it very clear what what we didn't define and all the all the conditions that we need to provide.

B

What dml file you mean, I I didn't. I didn't get that.

C

Oh, you know that the each uh semantic convention has a yaml file. You created one for.

B

ah Sure sure, okay uh-huh I mean you mean define that already or.

C

B

You mean put the put the the the the conditions there already in the mfi or.

C

I mean like create yaml file for our proposal.

B

To help us understand.

C

B

C

To specify something- and we will have a distilled um thing with everything.

B

Sure sure yeah, that that is good um yeah, but uh I yeah okay, the the game of five, will help uh create a model. um My mind model. I guess how things will be structured, yes, but I just I just yeah like do we write in the in the current semantic conventions like that this is conditioned, then we link to some other place where all the per messaging system definition, because that's what uh christian mentioned here, I think the the fast id symmetrical mentions has something like that.

C

Well, in in theory, you can link from one yaml file to another, so you can reference attributes across specifications.

C

So if we decide to reuse something, then we can definitely do it. I think they are the yml files they are in there. If you go to the root folder.

B

C

And then they are in semantic conventions here.

B

Yeah you, you can generate the table in multiple places right, so it's just referencing the the name of the the file.

C

Yeah, so what I found useful about this that I should specify that all everything here and it's hard to forget something and then uh it's just. We will have this table it's hard to read, but it's it's great to write. So we are sure that spec works together yeah. It's.

B

C

B

Yeah, I don't I'm not a fan of this right now actually um uh of these things here, the way they are here in the darkness. I think the yama uh it's it's. It will be probably uh better to go through them.

B

um Okay, but I think then the somewhat agreement is that uh we can't make it can cannot make it require, because of all the uh uh problems that we have right.

C

It's actually the case for for the name right, but it could be that understanding, sun messaging destination could be.

B

C

B

You mean here or.

C

The messaging destiny we're talking about messaging destination.name, but.

B

C

Have kind- and I assume this is always there and always the same- you probably cannot mix cues and topics in the same place.

B

Yeah, I know I think I think this is kind. I think it's almost fine. I looked at the discussion last week. I think the most problematic is the destination name. I think yeah here I just I just did this as well, because we renamed some of the attributes and if you look at the current that the author, that we're writing and then the existing one they don't match. So I just did like like a mapping like this, so we know that that's the new thing now. Oh.

C

I see yeah okay, yeah.

B

So it was messing destination. Then I did this arrow thing to say: okay, now it's necessary.name and for the ones that we renamed. I did this now like I like this.

B

uh Yeah, so we can make a required because we have the per message uh thing uh requirement and sometimes the destination name.

B

For example, kafka.

B

Okay, so perhaps this will give give us an idea of how to start modeling them and how we would define the the condition for when they are required and so on. That's really that's your idea. Right.

C

Yeah, it's just it will. I hope it will help us yeah with our discussions and see in that way.

B

Yes, okay, all right! Okay, so should we move on to another attribute, then.

C

And I think that the discussion about the name is just part of the discussion and the other half of it was about the uh network name and the euro.

B

C

It just feels that the the things we have below or uh like the temp destination and things like that are less controversial and it's maybe you will be easier to cover than the host theme.

B

uh So you want so you you, you mean to tackle the net view name and url, to discuss it now or or go to the easy ones all right. What did you mean.

C

If you prefer to start with, you aren't supposed to do easy.

B

No, I don't no, I don't I don't. I don't prefer. I don't have any preference. It's fine just want to make sure that I understood.

C

Oh yeah yeah, it's just because we had this discussion about all three of them. I think then, url actually yes started this uh conversation, so I guess we took this detour into uh context. There was span, but the the initial issue was okay. We have the name per topic and then what is the host name like in case of a w s?.

C

uh It's the resource name.

B

B

It's here, I guess um I think we didn't map, but.

C

Yeah, so I think for for amazon uh there there is.

C

They have this resource name and probably amir you're, familiar with it right. You work this sns in s class.

A

Yeah, can you repeat the question.

C

Yeah, so the question is what identifies broker like sqs or sms and aws. What would be a good identifier.

A

It's the url file for the keyword topic.

C

Do you always have the url.

A

Yeah yeah, it's in the console you have to like copy the url, they give you the url and you just need to paste it in your code.

A

C

And they have this identifiers as well, which were not url, was region and account id and things like that. They don't look like url. uh What does the relationship.

A

Yes, so so it's part of the url, the region and the account id, but actually you don't have to walk like they have a local stock, which is like a local installation of of aws which you can use, and then it's working also with the url. But it doesn't have the legend of the account id.

C

Uh-Huh: okay, oh yeah joe, can you please open this uh link? There is aws lambda samples for queues and a huge link. Let me close up this one.

C

And can you scroll down to the example yeah? Can you stop right here, sorry, just above where the they have a table yeah this.

B

C

So, for example, here uh they have this uh examples of attributes, the era resource name or identifier of some sort, and it's foreign.

C

Anyway, so the this, the third column and the examples.

B

C

Is the other the.

B

C

B

They are in the column at the plus.

C

Yeah, I got an impression from this document that at least for alonda, they use this kind of identifiers for the resources and you, if you scroll down there, is more uh examples with this. I think there is a few sample there.

C

B

Yeah, so I think this is what uh also christian said that the destination name should be. We should look at the fast id, because this will be the destination. I guess.

C

I think that what we discussed before the destination name is one that identifiers think within a broker.

B

Right, yes, I.

C

Think that it will be the last thing might function well, in this case it's columbus. So it's a function right, but it will be the last thing and.

B

C

The the thing before uh with the cloud, uh claudia conte d and with the region and with whatever identifiers they have, it should be something else, and it should be not pure name. Yes, um but then from what the mirror says. They they always have a url.

C

um So then there is a question: do we specify their um account like their resources like this or is the part of euro? And then it's the question? How do we do it across uh different specs right? It's not specific to messaging.

A

So I think that aws have like aln for everything that it's like an internal idea that they use, but at least for sqs, then the api to use it is to use the url like. Maybe if you dig enough, you can find some aln for sqs, but but the url is what people are actually using, and this is what they're interesting.

C

Okay, yeah, it's a good point. um Then there are two two questions right uh for messaging: it's like this, but for databases it could be different, maybe it's the same and then, if mass, if databases will use format like this and messagings will use url, it would not be the end of the world, but it would not be great.

C

So I think we maybe need someone from aws to help us decide um or maybe christian who works. A lot with aws can help us. But I remember there was a guy coming from from london's right and he could probably have some opinions on it or we can find someone working on aws as the case and ask.

B

um But you're you're, so so let me just understand, so uh we always so there's uh like when interacting with with uh with amazon messaging, uh there's, always always a url right, and the discussion is that if we always put that url in the uh url attribute that we have in messaging like messaging url, or do we split it and put in in different parts, uh so it can be reused. Some or the same conventions can be reused across different different things.

B

Is that what what? What we're trying or or do they.

C

Get it wrong yeah and besides your role right in this case, it's http europe, so it has more than you need for cues.

C

I assume it will be the identifier of q, but if we do url, which is an option, then we would still need a host part of it to come to uh for metrics right for like if we want to metrics and traces use more or less the same attributes as we do for http, then take a host and port if it makes sense and put it and and put it on attributes, and then we need to specify not clear name and network for it anyway.

C

So that's like it's a question. Should we do both the url and network name or just not, for name.

B

B

Because if we do the, if we do both, they could be duplicated.

B

C

B

Like not in this case, for example, in this case, it's not duplicated right because they have. uh The url here contains the the I guess, the topic or the queue name here um or whatever. This is.

C

There is some redundancy, but if we believe that url is very important, then we can take a url.

B

uh What does the current one says.

C

The current states that there is a url and it's a connection stream, which is.

B

Yeah, okay, I remember that yes,.

B

Url: okay connection string.

C

B

Is pretty much which is pretty much what amir said right like? If you go to the console, they give you the connection string, which you add to your app, uh which is yeah it's essentially, the connection string right in the in azure is pretty much similar right. You get this um this uh string from from from azure.

B

uh That is not really a neural right. It's some sort of.

C

No, it's it's not, and we would not be able to put the whole connection string and.

C

It's below yes, so we could do the same. We could say that, uh and it's currently it's conditionally required right. Okay, so we can do the same. We can say: okay, you need to have your name um and you need to have. uh You can have your also network name becomes additionally required or maybe required, I'm not sure if it's when it's not available.

B

And I guess this would be always available, though I mean.

C

I think so, even if you do some, I don't know local queue or versus unix domain circuits and you should have a and oh you don't have a name.

C

If you, oh, I see so you don't have a name. If you connect to an ap address, then it's just the limitation of the network specification and that's your name attribute definition.

C

So if you don't know the hostname and you only have an ap address, then what would you put there? An ap address would not bring much value.

C

So but I assume again, this is an overwhelming number of cases, at least for all cloud providers. You would have a name.

B

Yes, I'd assume so yes yeah, I mean even locally I'd, say you have a name right, but it's debatable. Probably.

C

And I mean: is this? The local case um and connecting to an ap address is truly the problem we are trying to solve.

B

But uh but we do have a place to put the ip with uh not being the peer name right, don't don't we have that in the uh command.

C

Yeah, it's not stock, pier audrey, it's the.

B

uh This is already reflecting the new uh yeah. Okay, all right.

B

But then we can make it conditionally required right and specify this other condition. Then, um because.

C

B

You have to have either of those right.

C

Yeah, either of those would be yeah.

B

Like if you have, if you have a uh uh a host name, then you need to add uh then yeah, then peer name that view name became, becomes required if you're available and then maybe up the port as well right and then. But if you don't have, then you must have something else, which is the uh the address that peer address.

C

Yeah so like we don't do any changes to the last five attributes. They are just referenced from the general spec and I don't think there is any additional context on them. We just keep them and we get like this basic network. Part of the instrumentation.

B

And is this in the jail, how it's already working or because it's the same problem? No, there.

C

Oh, what what problem.

B

Like like this problem, if you, if you have, if you don't have a net, if you like, if you don't, have a host name right uh uh like in http, do we also get have the same like recommendations that you, because this is recommended right, um but they are? They are all recommended.

C

Yeah, so it's like it's the network stack, it does not provide layers. Oh sorry, the recommendation levels per se because you're afraid to take this attribute or not, and you override the level and the stack so yeah the levels we need to override uh the yeah so for http, any backend should be ready to have if it could be that there is no net pure knee.

C

But then there is a nexo host address, so net.

C

It's for server instrumentation.

B

But do we do we have to override the current level even.

B

Because I mean because if we just reference the the common one, because what do the http one does, does it also override this? No yeah.

C

B

C

It requires, I think it requires net peer name, but don't ask me, ask me how sure.

B

That that was probably uh a long road as well for you, okay,.

B

All right, but so how do we move forward? Do we have a way of finding out, for example, is it something that we can research and find out how each messaging system deals with this, or is it more on the instrumentation library to to be able to have this available.

C

I I I think, for the last five attributes this fact that they're already in the stack- and it's probably not controversial- that instrumentation can find the peer name and port if applicable, is probably true.

C

Then we can also say that, okay, beyond this combination of network attributes, messaging systems could have url.

B

C

B

Think trl, we can still keep it right because if you do have this long connection, string and- and maybe you want to have- did that there- you would put in the url right, but you can still have this separate one with the individual parts. uh I guess that's more metadata right. It's just.

C

Right, it will be hard for you to aggregate by the url if you want to right um but easy using those attributes, um but I I think if we keep url, which I'm fine with especially if it's recommended right, then it should not be connection string, because connection string usually implies secrets. We can just.

B

B

That name is horrible. Yes, no.

B

uh Yeah, but you can put the connection string, uh the connections, that's not called connections in the url um and then have it in the in the url field. Right, but still I don't know if fox does like do aggregation on on the url, but if it's always the same, then it could do aggregation. I guess right.

C

All right, that's not generic right, because most of the systems have multi-tenant architecture. They have one broker and multiple topics.

B

B

And so what do we, I think, the net ones? I think we can. We can knock them off without much controversy or uh like either. We say that we that they are conditionally required either the peer name or the the sock peer name is so if you don't have this, is there one other one, and that should be good enough. I guess, but maybe you should not have both of them at the same time or.

C

Also, the way it works, it's if you are interested so in case you connect to your queue using proxy. Then your immediate information goes to some peer things, but your final destination, the logical one, goes to net peer things, so we have, uh we can have both of them, but.

B

Okay, so they're just conditionally required if they are available.

C

Yeah- and they are everything except not pure names- is conditionally required, because this well, the assumption is that even if you connect to proxy, it's not that essential to know so it's up to instrumentation and it's also not possible it's it's very unreliable to know who you're directly connected to. So that's why they are recommended.

B

Yeah, okay, but uh from what we have today in the document that johannes put, do we? Let's? Let's take a look, I don't know which I remember which um in which, as it is now.

B

Not even sure, if.

C

Oh, we have the old part of the lampere ip and that periphery was renamed to that salk pyramid.

B

Yeah, it's still in the old format, that's true yeah, so we need to change it.

B

Yeah and then they're all uh not required, so I guess aligned.

C

It's it used to be like when johannes put up this table, there were no requirement levels defined. There were like binary, which required.

B

Yeah yeah, I remember yeah, that's what you add all your suggestions. There is okay, but so now they are. I missed it where I had now.

B

Where I had attributes now.

B

I guess here yes, so we're talking about netbear name now and that we report right. um So we could do.

C

I'll mark them as good already.

B

Yeah, I I think this is wrong right.

B

So we had that pure name and appear part, so this didn't change the name, so we had.

B

And then we net.

C

B

C

Here it's above.

C

It's under the protocol version yeah.

B

B

All right we have this.

C

Let's remove the address.

B

Yes, all right so this so these two here we can add to the new to the table and.

B

Conditionally required, so this is clear right for both of them.

C

um Yeah, so if you have them sorry for stock things, it's recommended for your name is conditionally required.

C

B

What did I have know? What type where you want to bias.

B

Yes and this one is conditionally required.

B

Okay, so this so this we are uh this. We are able already to uh modify the table and add them there right, because we don't have them here today that we still have the old ones um and then we can knock them here and then, when once we move to the proper yemo table, we can add the text, the recommendation, I guess.

B

Okay, so this I can do.

B

Okay and what else.

C

Then we have url and url then would be recommended and.

B

B

So the url will be recommended and what would we um as well so we can do the the definition of the terms or what it is there later on. But is it also not here as well.

C

Oh, it's, it's not. We didn't add it because we we thought that pure name would be enough.

B

C

Could be enough in theory, so I think we can get more feedback like what people think should be put just your role. Oh sorry, should we put just that pyramid or you know, would work as well, so my motivation to just keep it because I don't know how to.

B

Argue against not having yes, but amir. Do you think uh so uh you guys do a lot of messaging there right. um Do you think that this combination would make sense or for for instrumentation and uh like would would would they have a url and then also have the other two or I don't.

A

B

A

For a sqs, like nobody.

C

A

The host name of the port of the other.

C

A

It's not useful for anything.

A

It's like if you're communicating with kafka that is running in your cluster, then maybe you care about the ibs or the host names, but for sqs they always the only thing that matters and also.

C

A

Usually, you will have like another span for the http if you were communicating with http, and it will contain all the all this information right, so you will have like the sqs pen and then an http underneath it that records the http um interaction.

B

Yeah um yeah, this is true so, um but I don't know what we will do with the so like. If we, if we have, for example, the published expanse, um the url would go there, but maybe this other information would go to another span, maybe a lower another lower level. um That happens.

B

The actual protocol, I guess, span, but we're not modeling that span now, but yeah.

A

B

A

Yeah there you.

B

Go no! No, I don't just say that having the attributes defined at least um uh makes sense. I guess.

A

Yeah, I think we have to make like a common sense, like instrumentation writer will have to apply common sense when he captures attributes to decipher decide if it's interesting or not, if it makes sense or not, because we don't want people to capture something just because it's required.

B

Yeah yeah, it doesn't make it yeah, but yeah. No, that makes sense, but I I yeah, but I guess people the people that write uh are writing instrumentation. They would probably rely on the table to tell them what is interesting or what is common sense because it could be really. It could be really like changing from person to person right.

B

Maybe I'm dealing with a lot of low-level stuff, so I think the the ip address is important, so I will try to do it, but maybe another instrumentation author goes and say: no, I don't care about this, and then it doesn't put it. So um I think it's on us to make clear the table that what is like what what will produce a let's say, a common sense, like you said common sense, good enough um experience right.

A

Yeah, like, unfortunately, there's not like a good answer that will cover everything.

B

C

Regarding this discussion that the the published plan would have net peer attributes and http span underneath the top net peer attributes, this is true, and this this is a redundancy.

B

Yeah, so we don't, we don't probably don't need to put this uh there right that there actually is a good point.

C

Oh well, it is but then uh like, for example, in our case um in england, helper service bus. We do allow http apis, we have them, but they're configurable. You can have http api or you can have a target-based api uh course and then the the introducing this knowledge into the higher level right, like the public api surface, about what's configured, how should I instrument, depending on what it's very difficult gms, doesn't know what the practical underneath right. So it's an abstraction, multiple tools that do this.

C

um I don't know hiding stretching away the messaging system. They have this uh problem and I don't think we can really rely that instrumentation authors can make it conditional right.

B

You mean the pure name being conditionally required is not a good idea. I am that's true. No.

C

No, I mean that if, if there are two layers right like when you create this stand, you don't necessarily know what protocol will be used underneath and then you don't know there will be a duplication. Also. I think java provides this way to suppress and say. Okay, I only care about uh first client spam and I'm going to suppress in between underneath.

B

Yes or suppress this a specific instrumentation, for example,.

C

Right so then we cannot rely basically on that the duplication exists and we still need to have this information.

C

Then the question is: do we have the network attributes where we have url, because urls, um presumably there and still still, europe could not be available for gms, where you don't know what you're working with and you get the connection into the gms obstruction, not the the the the url to connect to so I think euros, just it.

C

It's not always available um while yeah and when you, for example, um configure kafka, you don't specify url, you specify hosts right and then we cannot say that url is required and we cannot always use it, but we can pick something more common, which is network attributes.

A

I think it depends on the user, like I think, most users care mostly about the logical part of the messaging. They.

C

A

Know the destination, the topic name or the queue name and which messages are involved. They don't really care about. The network, like some users, do care about the network attributes, but then they have the choice to instrument the underlying level right. They can choose not to suppress the http or whatever protocol is involved if it means something to them.

C

True, but it implies that users will do something and I think auto instrumentation default experience should be users, don't do anything and it makes sense and then, if, like all the the things that they can do and situations they can have.

A

Yeah so like auto instrumentation, it's a question if it should like capture everything possible to cover all cases or which, if it should capture like common things,.

C

One thing we can do: we can say that that we actually do initiate this back. We can say that this is a default experience and which would the url is recommended um network attributes or recommended sources conditionally required, and then we don't specify how this is. What http specs does but say that you can turn off network attributes. If you don't care about them, and instrumentations may provide a way to do so.

B

I guess it will be fair.

B

Yeah um yeah, I I do like that uh the http instrumentation is, is it's quite consistent but consistently uh consistent between like uh languages and libraries, because you pretty much get the same attributes out of the box. You you, you know if you're dealing with, go and and then java, http clients and so on.

B

So if we can achieve the same thing, I think that will be greater actually like yeah the same like out of the box thing experience.

C

And then you can tune it.

B

C

B

Then somehow it's able to tune it. Yes um with uh just just a curiosity. We are almost done anyway, so I would uh we we don't have a way. So is there any way in the spect to tell about the optional attributes how to turn them on uh no right? That's up to.

C

Yeah- and I think it's intentionally not specified because it's too much work and I think there will be some big configuration seek. That's well decided.

B

C

And for http, it's like they and for its language specific and in java, I think they have sometimes groups of they say: okay, enable this kind of attributes or enable this specific header. um So it's very inconsistent and we don't have to specify it. We probably shouldn't.

C

Unless we want to meet for an extra five years.

B

Okay, so what do you think it's a good idea to move forward these attributes? Do you think this? uh What we discussed is enough, for example, laying out that um stockpile does is recommended. Net pure name is conditionally required if available, or should also this be recommended, because maybe we don't want to create uh duplication, for example,.

C

So it's like either or so either you have url or this attributes.

B

um Yeah something like that. I was thinking or even not not that, because you need to have something right: it's either this or it is right or or that one.

C

Well, so something is not great, because then how would you have metrics right, for example, somebody would create a messaging dashboard.

C

How would you reuse this dashboard between aws and azure? It would be nice to reuse it right. This would be good to have something common, at least out of the box, and um if I'm a ops person, I know not. Your name attribute it's everywhere on every step.

C

Why don't I have it on messaging, right and so having this baseline would be great.

B

Yeah but for example, if you found the suit correctly, uh if you connect with sqs, then you always have this this, uh uh this rna, r, a r n, uh and that is pretty much immutable right. It doesn't change right.

B

So it's it's like a global thing. You always use that um so that that that will be the thing that you create the dashboard right, the url.

C

Would be, you would have it in net per name as well.

B

Yeah, I don't know they seem like it seems that if they are always the defector thing that people use, for example, in amazon, to connect to things, uh then I guess it will make sense to create a dashboard with that right. And then, if I need another thing, then I yeah it's another filter. Another criteria to create the.

C

B

C

Are plugins for graphing? You can install dashboards from grifana. Sorry.

B

C

Funnel that are provided.

B

By the community.

C

Right and then the community may create a messaging um dashboard based on the things we define here right yeah. If there is a this poor funding, it's not the end of the world. People can deal with it, but in case of http we have both for clients. You have you. We have your will and network attributes for the sole reason of efficient metric calculation.

B

Yeah, but even if we, if we put okay, if we, if we keep leave it, we'll still leave it, the condition required- and there is some like there- is some uh good value that could be used for a game for this kid to create, because there is either one of these or the other right.

B

So that could be, maybe that that is enough to cover this basic experience scenario. I guess.

B

So leaving or all of them probably is not a good idea right so.

C

Well, I don't agree because at least this is what http and to be fair. Until recently, http spec provided a lot of redundancy like people specified everything and duplicated, and at least from what I heard there were very little complaints about it.

B

You mean having uh a lot of attributes duplicate like this.

C

Yeah so there was url and target and host yeah.

B

C

Port and toast expressed multiple different ways.

C

And I I personally don't like this, but um it's it doesn't seem like it's a big deal for users.

B

B

Yeah, um but anyway in removing this, uh so we just conclude we already passed but just to conclude so removing this we're done. It does the same thing. um If we leave the url as uh recommended, I guess it would be because um or you would you would see the url as as required. No right.

C

It cannot be required because it's not always available or.

B

Exactly this makes.

C

Sense, especially for cases like I think, as well and kafka.

B

Exactly so so they they have to be, they have to be recommended, and I think this as far as I understood this is the only one that we can make a condition required.

C

Yeah and we can say that it's conditionally required, but you can give users an ability to not populate them in favor of euro.

B

Yeah, I think, that's a good compromise. I will try to type this down and um and update the document to put this. That is not there.

C

So maybe I can we can do this with the yammer file right. I will create it and then we'll see if they can populate the markdown table using it, and uh we can probably do it by the next meeting, but not early enough. So we can review it offline and uh to confirm if I captured everything correctly um yeah.

B

I mean, I think he would, I think he would be able to do to because the generator works towards this spec. I know no, don't forget about it. You can just place the yamo anywhere and just pass the source.

C

B

Yeah all right, okay, then uh yeah, let's, let's sync during the week, maybe to a line, but I think this good progress on these things. Finally, on the url or things so at least we knock some of them out. I think there's the most controversial ones left, plus the name.

C

Right, yeah and the tooling, by the way, doesn't have an ability to specify um links, attributes and I don't find one.

B

What what do you mean now I didn't get it.

C

So some attributes will go on links right.

B

C

And there is no uh way to standard way to do it like the message id or something, and we will probably need another group in the yaml file and another table to specify attributes on links.

B

uh On at the spin at the link level, you mean yeah yeah, no, but I think this we can just uh add another section in the ammo like spam links.

C

Right link, attributes.

B

And then just generate the table. I think that should work all right. If you don't, then we can adapt. The tool should be uh should be possible. I guess yeah.

A

I think most of the attributes can be sometimes on the link and sometimes on the spam. Like message id can be on the link, but you know send.

C

A

Actually need to spam out of it.

C

Yeah- and this is where the cmo files will be useful, we'll have to specify okay, this thing will go on the uh on the stand when possible right when it's the same for all messages in the badger there is no battery or- and this is things that can go online unless they are common for everything and some of them like message id will be unique per message.

B

Maybe we need another column in the table saying uh where to edit and then it can can be like span or link or something like that.

C

Let's yeah, I think we will need something like this. Let's start without it, because modifying this tool is.

B

Sure yeah all right, then then, uh thanks a lot and yeah we'll see each other next week see you.

C

B

uh Just forgot about this something quickly. I will probably open the vr on the spec moving the old tab text this week. So just let me know this is coming we'll see how people react to it. Yes, I'll do it this week, oh upcoming week, cool then see you next week.