 Welcome to another lovely SMI community meeting. I take it Phil is going to subscribe, is that right? Yeah, that's good. Awesome. So let's have a look at the agenda of 14. So I had an agenda item there around the question that kind of my race, I just have a look around, otherwise we might postpone. Background here is question was if there is a similar, if there are any plans really to have something similar to what the conformance suite that Lee is working on. And yeah, I'll just throw it out there. I don't expect anyone to actually answer it, unless you know of something. It was probably more of interested in the same way that the control plane conformance could be tested more or less on the probably on the on-wire level, like I guess. But given that my colleague is not here, not entirely positive, it makes sense. But if someone knows something, then please feel free to share. I don't know of anything. That's an interesting question. I would be curious to know what the goal of conformance for the data plane would be? Right, right. And also, I mean, it kind of assumes, I guess, that we already have a standard, which on-wire tools, I think, extend might be considered. Because if the data plane is not, there's not a standard, then it's kind of like hard to buy the conformance right. But yeah, I would definitely suggest that we visit that once my colleague explains the motivation. But I'm not sure I understand the question. When it says conformance to the data plane would be the goal to have two meshes with two data planes that can interoperate at run time? I can give you one, given that I didn't drink, like I'm more like no pun intended proxy for that question. A colleague of mine asked me that. And I said, I don't know. I don't know of anything. But I happily asked the big brains in the SMI call. I can think of one thing. So if you, again, this is not saying Envoy is the standard, but it is de facto very widely used. So if you think of implementing, actually, we raised a relevant issue on the NPA working group as well. If you think of the Envoy API, implemented in, say, EBBF. So it has the same API, but it's not the Envoy proxy. You want to make sure that some workload that works against the Envoy proxy now works on that new BPF-based implementation. How do you make sure that this, and you could implement the Envoy proxy in a bunch of bash scripts, right? Why not? You could. And the question is, then, if you have workloads or in hardware, you might have a dedicated chip that implements that. Why not? So if you have that kind of challenge, so you come from the original, the OGU, real Envoy to some other implementations that is, or claims to be UDPA or Envoy APIs compatible, how can you actually prove that or test that you actually are? I guess that's the, without really knowing that the new test, that's probably one of the main drivers behind that question. That makes sense. So can we get the person who had the question that was relaying it to you to put it in an issue? Yes, I'll follow up with him and ask him. So we can get all the details and do it accurately. Thank you. I don't know exactly how to do that. I'm totally out of my depth here, but one place that might be easier to start than others is maybe in metrics, like the kinds of metrics you could get out of a particular proxy that might be an easier place to start. Because I don't know how to do the other things or do conformance around the other things. I'll take an action. I'm going to pull up with him around an issue that makes sense. Richard, PR reviews. Awesome. Yeah. I dropped some specific links in of a few that I think could probably use an I or two. So in some of them we had like one review, but we need two. This is related to Michelle was pointing out that we some of them we might want to make sure that we get a couple of reviews on. I put this on the agenda, but it was inspired by that insight of Michelle's. Michelle, do you have more you want to say about that? Oh, yeah, I just feel like, you know, more people are getting involved in this spec and I don't want to like lose out on momentum. But I think even Stefan had pointed out it's just taking a while to like get reviews and stuff and totally get it like I don't think anybody is working on a spec full time. But just I don't know if we need more maintainers or yeah, I was just about to ask exactly that. Can we maybe given that that there are apparently only very few people who can GDM or whatever group can we expand like is that an option to expand the number? Yeah, I think we need to like maybe engage with people and see, you know, who's interested and like then there's usually like a vote and stuff like that. So let's let's kick that off. Right. I mean, sending something out to the list saying like, hey, we I mean, we could also have something in between. It doesn't have to be a full maintainer or whatever that that might be a dedicated review but kicking off the discussion itself like hey, we need to scale like more people who would be interested in something like that if it's full maintain or review or whatever. I said, you know, I would definitely do that whether I have cycles specifically for SMI and located so I would happily do that. But again, it's not about full maintainer or not we want more eyes that can essentially authoritatively say yep. Yeah, that would be great. Let me kick off that conversation. And he'd be great. So let me go ahead and kick off that conversation on the thread and or on the mailing list and let's let's figure it out. I 100% agree. Any other thoughts? There is also a little annoyance on the how the pull requests work. So let's say you make pull request like I did. Then there is a typo where I I forgot to put minus with to some doc right and I got the reviews for it to be merged if I let's say fix that type or I had a minus somewhere all the reviews are lost the recess to zero then you have to wait like another two weeks, three weeks to find all those persons again. So yeah, it would be great to have more more eyes on this that can react faster. I that's the reason I didn't modify that type of because I'm planning to merge the pull request now and ask you to fix it in your pull request because you have to rebase so even your pull request will lose the the reviews. Yeah. Yeah. Now I totally get that. I think for me it's on every project because forest pushing dismisses all the reviews and then I'm like, please give me a review again. I promise I didn't change anything except for typo. I just annoy people. Can you please please watch this? So yeah. Is there any? Oh, I was going to say that sounds pretty good and since we are all paying attention to Asma at this very moment, I challenge everyone to pick at least one of those links I put in there and go put a review if you are a maintainer or if you're not a maintainer but definitely if you're a maintainer. Let me merge it first then we rebase the other two then we ask people. And I did put that one, you know, note that Stefan has the needed approvals on that one. So perhaps he's just going to click and merge and then we'll deal with some of those unaddressed comments. Is there any of those one, two, three, four? Is there some low hanging fruit? Like I to get some success, but is there one of those which is very, very close where we just need to maybe spend five minutes reading through it and we could close it off? Is there any candidate? Michelle's is like one line. It's a one line. It just says, should we talk about that one? It's requirements for traffic target. She had small clarifications. Yeah, there was a thread. It was inspired by a Slack conversation. I'm not sure if Patrice brought it up. I'm not sure who brought it up, but somebody brought it up and said that, you know, what is the behavior of a traffic target if no spec resource is defined? And I just put in a line that says, and we didn't clarify that in the in the spec, but on Slack, we clarified that a valid traffic target needs to have at least one destination, one source and one rule. One rule. Yeah, one rule. Thank you. We're talking about pull request 192. Is there anyone on this call who has any like objection? Merging that in like it sounds to me like a pretty straightforward thing to do. Is there any objection? So we cannot merge anything now. It's a conflict because I changed the spec. Sorry. Yes, but so people have. Yes, I'm sorry. I'm sorry. But you know what I mean. It's essentially saying like, yes, we are once the other thing is fixed, we can actually. All right. So it sounds like we've got approvals for yours, Michelle. Okay. Well, Saphon mentioned that he wants me to fix compatible with, but I think there's another pull request by Patrice that actually fixes the working. Yes. 191. Yeah. So if you want to push that, then I'll rebase onto that Patrice. I think we're in a trust environment. If we record in the meeting saying like, yes, the group considers that as thumbs up, resolving these dependencies. I guess we're all engineers who will somehow figure out the way. Yeah. Well, to rebase. And it looks like Patrice's was discussed in the September 30th meeting and then he put the pull request in. So if anyone has any objections to it, like looking at it on GitHub and recording those or approving it would be great because we already did talk about that one in September 30th in the meeting. You're referring to 191, right? The align the structure of the four APIs. Yeah. That's 191. Yeah. So you're essentially, so there we have two already approved. So that seems like also good, right? The conflict. So I'm going to fix that. Yeah. But that's exactly what I mean in terms of like agreement in principle versus, you know, figuring out the mechanics to resolve to untangle this thing because there are mechanical issues. But like, if someone would say like, whoa, I have a problem with that. There's an objection. That's something else. I just want to make sure that everyone is like, yep, fine. And then, you know, we trust that you folks will figure out. Yeah. And then I added one from the metrics repo because I thought it was kind of interesting and maybe somebody isn't usually referring or reviewing over in that repo wants to look at it. That one being if there is this issue in Kubernetes 19, then we might need to get that fixed in. Someone opened an issue and pull request. The URL. Yeah. It's in the notes review needed users that have alternate sand field. Oh, sorry. So that's 72. It would probably be, you know, useful to note. Hey, please, I missed the comment on this one. Oh, I was just saying, because it's not in the spec repo, it's in the metrics repo, people might not have noticed it, but it might be important. So I wanted to bring it to our attention. And that's all. I feel like I've taken up a lot of time with us and, you know, metrics. Speaking of metrics, Michelle had some stuff to tell us as well. But yeah, that's maybe if you are fine with that, let's move on to the next. I'm totally fine. I just want to bring to everyone's attention that we wanted to work on some of these. Thank you. If we do have time at the end. Michelle, this is my metrics. Oh, yeah. I had to move the deep dive from, or thanks actually, Bridget moved the deep dive from last week to next week. Just know that a metric specific discussion is happening next week. The goal there is to discuss problems that have arisen from trying to implement SMI metrics. So I know that the Lincordi folks took a stab at it and for using it like with their CLI commands, and like we also have taken a stab at it. And we've implemented it with Envoy under the hood and Prometheus. But we did run into some issues. And so John, who's on my team, is going to walk us through what he did and any issues. And as Stefan has talked, we, Stefan and I have talked about some issues with metrics as well. So bring all your metrics specific things to the meeting next week. Can we, for the people who were not, when we initially said that up or talked about that, what's the goal of that next week's metrics? What do we want to get out of it? I think that's a really good question. I think the idea is to talk about how you've implemented SMI metrics. So we'll bring our implementation, kind of give a five, 10 minute overview of like what went into doing that. The action I remember, the end of meeting, I'm hoping to get kind of a list of things, a list of issues that people have run into that are common and some areas that we know we need to improve. Cool. Okay. I just noticed that my colleague, David, actually tried us not. So if we do have a few, maybe we could actually jump back to the very first agenda item. Unless anyone has anything else in the meantime. I don't know, David, are you on the clock? Can you hear us? Yeah. Sorry, I joined a little bit late. I'm just listening. I'm from the AWS app mesh team. Right. And if you look at the agenda item, the first one, this is, if I remember correctly, something that we discussed in terms of the conformance suite for the data plan. Oh, the conformance suite for, yeah. I don't really know what all you've ended up talking about there. My interest there was we're doing something very similar for app mesh. And I think one of my concerns is, at least I'm in the opinion that we can generally get the API level consistent across all these different implementations. But making sure that, well, one, just our own implementations are internally consistent. Within two, having all these implementations, it's some kind of general expectation for how SMI should be implemented. And that's sort of my going concern around SMI is the hard part is really just the data plan conformance and consistency for customers. Well, I guess that was the question, right? Because I was only able to convey so much, like, what does it actually mean, right? Because, for example, it kind of, if you say data plan conformance, it kind of like assumes that there is a standard, right? Or to address the elephant rule, to assume that envoy is the standard, right? Otherwise, it's not even just an envoy, right? It's like behavior around things like... I'll use an example I know that is true in both Istio and app mesh of like, if you have a TCP service on the same board as an HTTP service, is that routable? What gets preferred there? And one of the kind of the sad secrets of all these service meshes, maybe not OSM, I haven't used OSM much, so maybe OSM is perfect here. But at least for the rest of us, there's all these interesting gaitas as we're trying to make the obvious use cases work. So for example, in that previous one for Istio and app mesh, the TCP service would just get dropped. Couldn't wrap it. HP is preferred. But we're all working to not only try and fix these books because customers do encounter them. But also I'd say as a general guiding light of where we're trying to get to is we want something that's kind of like a normal VPC. You should be able to... In a sense of like, there shouldn't be any weird edge cases. There shouldn't actually... It shouldn't be obvious that there is actually this proxy in the middle that is making preferential decisions or that you're having to deal with its configuration. And so I think in general, Istio is improving this, app mesh is improving this. I don't know where OSM is at, but I'm assuming that wherever OSM is, they're improving that. I think my concern then with SMI would be as we're all improving and fixing our gaitas, are we... Well, I think the big thing is are we converging on a consistent state and what interesting edge cases would be different between the two implementations. And then also having that conformance suite would allow us to track edge cases at like an SMI level. We're doing that for app mesh, but I don't actually know how app mesh from a data plane is differing from SMI as a spec for the data plane. I guess, so that helps already a little, but I guess to really capture everything, it would be, as we had in the notes already, it would really be great, David, if you could create an Istio. And essentially, maybe you have... Like you gave one example, which just already helped, maybe you have more, so that we then can also... Because essentially, these agendas, we essentially refer to some issues that we can track while we... What is need to resolve, etc. So if you could do that, that would definitely be very helpful. Yeah, I'll put up an issue and all. I can take the doc I've written for app mesh and... Because I don't think it's particularly app mesh specific besides the word app mesh, like a million times on it. And I can convert that into something for like the SMI OS space. Cool. Thank you. Thanks a lot. Cool. Any questions for David or...? Thanks. We've definitely been running into edge cases and kind of don't know where to go all the time. And sometimes we take those questions back to the SMI community and have like issues and threads about it. So it's great to kind of get exposed some more of these issues and see if there's more we can do along the lines of conformance. So thanks. So this opens an exciting question. Is app mesh going to be the next logo on the SMI spec web page? Stay tuned, but I'm interested to find out. Exactly, yeah. Yeah. I can see that there's reinvent relatively soon. You know, reinvent is our version of Google Cloud. I think that's the official name. Yeah, so stay tuned. Yeah. Any other questions? Anything that we can actually. I have a question for you. Yeah. If there is a plan to get the latest back in OSM, I'm referring to traffic split, of course. That was for Michelle, right? We're all looking at you, Michelle. Oh, I'm sorry. Something just like popped up on my screen. What did you say, Stefan? I'm so sorry. It was my manager. Is the latest traffic split going to be in OSM real soon now? Give us status updates, please. Oh, yeah. We are running system issues, programming the proxy to handle that situation. We use traffic target fundamentally as a way to actually program the routes in the proxy. So then when you do traffic split, you also have to handle especially the latest version with all the HTTP spec support. We're trying to figure out how to do that, but it's being worked on. It's on our public roadmap. I don't think it's going to be in the next few weeks, but definitely within the next month or two. Thank you. Thank you for the update. Can I just make the link here with the question from David, the fact that different service meshes, despite the fact that they would even use the same SMI, will not configure the envoy the same way? Is it related to what you were talking about, David? Sorry. Say that one more time. So it looks like we are in a situation where we have a different service mesh, and even if they would finally converge to use SMI as an API to receive their configuration, they will end up in configuring the data plane envoy in particular in a different way. Is it related to what you were saying to have some more conformance on the data plane level? Yeah. It's not necessarily that we have to configure envoy exactly the same way, or even be using envoy. It would help. Yeah. It is the actual behavior that customers see in the data plane consistent across all the different implementations. Okay. Yeah. And also, and maybe that doesn't have to be perfectly consistent, but being able to test a implementation and show how they're non-conforming, or I don't know if there's some kind of like shoulds or preferred behavior or implementation defined, where it's very clear how different data planes diverge and that they don't diverge on maybe some core fundamentals of how a SMI data plane should work. I like the expression. SMI data plane. The thing is, David is definitely way, way, way more deep, deep into that than the expert and than I am, but I'm really curious to learn and maybe that issue helps to tease that out. What is indeed a data plane property or issue? Because the example that you gave, to a certain extent, to me, that sounds more like the semantics of the spec might not be 100% sharp or clear, right? If it's kind of like unclear, which of those two should put up? Obviously, it impacts the configuration of envoy or whatever proxy, whatever you might have there. Yeah. But to me, that still sounds a bit like kind of like an uncertainty or it's not entirely clear in the control plane spec. Yeah, I think that issue. This is due to historical reasons. Like traffic split was first implemented in LinkrD and LinkrD does its own discovery of Kubernetes services and defaults to Kubernetes services, which is wonderful, but it doesn't work in an envoy world, where you need something to base your routes. So OSM choose traffic target, which I think it's a mistake because maybe you don't want any kind of firewall rules. You just want to split traffic. So for me, traffic target is like a net of policy. There are many Kubernetes clusters out there that have CNAs that don't even implement the top policy. ECS is a good example of that. Yeah. And I guess what I'm suggesting is that maybe the question that David raises is not just, you know, the original core question that he had, but it's maybe a wider discussion. And we might end up doing a, you know, a dedicated like in the same way that we do next week metrics, that we dive deeper into that issue around, if people think that that makes sense around that. And then if David can share any notes there to put some more flesh on that, that would also help. Yeah, I agree with that. I think one of the hard parts about sort of being spec first, which is kind of what SMI is. Now there is OSM, which is a solo planner of it, is that it's really hard to know all the edge cases ahead of time. And that's why I'm more of the opinion like a like conformance suites and tests that we know run against particular sets of implementations and using that to work backwards into a spec or a more comprehensive spec seems to make more sense to me. And especially for something like the data plan where we have several potential implementations. Yeah, it's hard. I'm with you on the implementation first kind of approach. I think that's what Lincardy originally and console and solo and there's one more person. I don't know who the partner was. This is before my time on SMI kind of got together and shared their learnings and created the spec. And then we kind of came along later and started implementing. So we definitely have run into a bunch of edge cases. Yeah. And I was I was like, it's like we're all browsers, like, you know, I was implemented things in a million different ways. And now we're trying to like homogenize things. And so we're just we're just having to look at the implementations and come up with some spec that makes sense across all of that. Yeah, I was I mean, I would be like, I think it's super important to like get aligned as a community on the conformance testing doc. And I know like Lee Calcota has kind of been pinging people and asking people very loudly to review the doc and then a little bit of it. But I feel like we need more reviews on it. And at this point, I feel like it's worth maybe doing an hour long review of the doc together so we can expose some of the issues in real time between the implementations. I don't know if that'll help. I hate I hate to interrupt, but as the moderator of this meeting, I have to insist, we are at the top of all. So unfortunately, yeah, I have to wrap it up now. But let's keep it coming. And yeah, David, looking forward to your issue. And then we can take that and put it on the agenda again and continue discussion. Okay, thanks everyone. Thanks a lot, everyone. Okay, thank you. See you around your next week metrics. Bye now.