 Who's moderator. That would be you because I just talked to you into it two minutes ago. Oh, yikes. Okay. All right. Thanks everyone for joining us. It's Wednesday, April 14. I am Shaw. I'm going to be moderating, which I learned few minutes ago, and I remembered, as I remember things sometimes. So I'm going to paste the meeting link or meeting agenda in the chat. We have an SMI controller SDK update, we're going to talk about the conversion logic in the SDK. We've got some updates from Bridget and Michael on the multi cluster stuff and then we have a question around custom app support off filter support. So, let's get started Nick, feel free to take away. A couple more controller bits and pieces to the conversion logic. So it's about 50% complete now. The, from a conversation we had with with Michelle we decided that. Sorry, Nick, you're really quiet. Could you possibly speak a little closer to your mic. Sorry, it's this laptop. It's just awful. Much better pilot junk needs to be burned. So, yeah, so, so we're about about 50% through the conversion logic. There's just a couple of API's left to do from Channing, Michelle, we decided that we should pin to the latest version of the SMI API. That still means you can convert between V1 and V4 and V4 and V10 or whatever we end up at. But the kind of the base version is going to be Alpha 4, which is the most mature version. And we're currently working how to get that conversion logic merged from the Go SDK into the new controller SDK. So we can have a single report rather than having to maintain two different things. Benefits for that are that then we can use KubeBuilder to generate all of the CRDs and things like that. As opposed to how it's done at the moment, which is a manual process. Hey, I can give an update on that. I've been working on moving the API's into the controller. And I do have a PR so I'm trying to work all the way through, like at least getting the traffic split example working. So there's a work in progress PR there. I used KubeBuilder V3 because V3 has good support for multi group APIs. So that was the reasoning and it's the freshest one. So to that, I did run into a ton of issues with the code generator script. So if anybody struggled with that or has experience with that, I'd love a second pair of eyes because I don't know if I'm doing wrong or if there's a bug, but I definitely opened up an issue in the code generator repo. And that's basically the tool that we use to generate the clients and formers and listers from APIs automatically. That's it for me. Michelle, if you want to ping me a DM, we can maybe help you debug that later on. That code generation script is pretty hacky. Sounds good. Thanks. All right, moving towards the next topic, which is the conversion logic and I think Nick already gave us an update on that. Nick, if there's anything we can do to help, please let us know. This is something that open service mesh really needs like pretty immediately. So we'd love to use like the SDK and we'd love to do anything to help with that stuff. So is what is in there right now ready for review? Like, can we Yeah, I was just looking at that earlier on. I think it is so I've got my PR as marked as work in progress. I think it's a sensible thing to do is actually to merge the conversion logic that I've done so far into the SDK. And then we can raise further PRs based on the other stuff but it also means that there's a better guide on how to contribute to that stuff. Yeah, that sounds perfect. Okay, so go ahead and review that. Yes, Michael. Do you mind maybe I know it's a little bit of overhead but I think it's worth it at least to the beginning now to our surface of flag these, you know, if there's anything where we can unblock you in terms of reviewing on the selection, just saying, hey, you know, there is a PR. I don't know, otherwise, I feel like, you know, we're always within like a week or two. Oh, there's no, there's no block the PR I raised. I only raised it as a work in progress just to give exposure to what was going on. Oh, sorry, I thought, okay. Yeah, you know, no, the intention was to, to like, finish all of the conversion logic and then just merge it but I think we can probably merge the partial PR because it's fine. So I'll tidy that up in a bit and then I'll get that ready and request some reviews. My bet for misunderstanding you. All right. Thank you, everyone on that anybody else on the controller or the SDK anybody want to share their thoughts or ask a question at this, at this time. All right, thank you, Bridget, you want to take it away. So if you're looking at recordings of this meeting and you're thinking, wait a minute, you just have one last week where you're having one again. The one last week was the SMI multi cluster working group meeting. It's currently going to run every other week at the same time in this time slot on this channel in the weeks we don't have the community meeting. So this meeting is currently a weekly meeting. And Michael led the very first one, and I think he could give us a short update as to what is going on with this whole multi cluster working group, Michael. Absolutely. Thank you. So we had an awesome discussion. It was really productive and create outcomes to to, at least within the people who were present last week consensus was that, yes, a in terms of the issue to 12 multi cluster. The group want to do that in SMI. And in terms of what is in scope or out of scope, I think we didn't really have a, or at least we said that certain heterogeneous environments across compute is important but we didn't really have a like consensus on what exactly the scope is at least that is my interpretation please correct me if I'm wrong. So I would like to, you know, bring that back to it to enter a group here. The meeting notes are below you can see the details there. I think we should just continue in that way to essentially find consensus in a smaller group and whoever is, you know, as a stakeholder has something they want to do their implement or whatever please show up every other week. Whenever we have consensus on a certain bit and report it back. And if there is is a need to kind of like open up something and see like oh you know the wider group or all everyone represented here has an issue with that we can definitely discuss that and reopen that but in general I think we should trust the people who actually put some work into that to decide yes, you know that's in scope or not or whatever at least that's that was my my approach to the whole thing. Yeah, and any questions or any comments on that is that a viable way is that a way people are fine with running things or do you want to see a different way or we kind of like make it up as we go along where we don't really have a charter or anything we might also want to consider or maybe I'm missing something but I don't think that we so far have defined the workings of working groups and what's the, you know, the way how we work back and find consensus or whatever I think we're just kind of like trying to follow best practices around since here. It looks like you had a pretty vibrant discussion last time and captured a lot of it so I would say, guess you're doing that again next week and we'll see what comes from that. I'm excited to see a lot of progress here and a lot of folks feel bought in on like the macro vision so yeah, look forward to it. Michael where the notes are those is that in the just below. Oh, I see if you if you scroll down to last week. It's everything there. Okay. And so, yeah, a little bit of catch up to do but one of the things that I think is I assume is implicit to this at least from what I see in the GitHub issue is Well, speaking of charter is an expansion of SMI charter beyond the Kubernetes because it's like pretty big it's been explicitly stated once more than once that like this thing is. It's very, very, I hesitated to bring it up right away because we haven't really addressed the scope yet right to the first consensus was essentially, yep. There is interest want to do that, and then we didn't really wrap up the scope so it would be a little bit premature I think at the current point in time, but you absolutely spot on. As soon as we have to scope defined saying like yes this you know it is indeed not just communities clusters it is I don't know anything from a VM tool functions a service to communities to maybe even messes who knows like any kind of service to, then obviously, yes that would require us to change the chart. Absolutely. I guess I'll do the last question real quick so I see Sergio pose I was asked that that's great. The in reflection to Hamlet. What was the, what was the, what was the synopsis the really yet get to the point where it's like okay, how do we actually go about what are the options that we have I think that's part of the, you know ongoing homework to see like what are the options Hamlet in my understanding absolutely is an option. But I think we should be open minded in the sense of that we, you know, immediately jump to conclusion, like, oh yeah, it's about, you know, rubber stamping Hamlet and off we go right we should say like okay what is the solution space. What is the problem space what what what is the scoping there and then select okay here the two options three options, whatever, whatever we can do and then I think that is something once we get there to that stage that the entire group so should, you know, say like okay do we have consensus on. Yes, it is indeed going beyond communities because as you pointed out, very rightly, quite some implications there right. Cool. Great. Anything else on the same question. I do think that we, if we keep keep that momentum that we actually have for cube con which is first week of May, at least something that maybe we can actually share in the booth or wherever we can say like, hey, you know, should you be interested in in the SMI beyond a single critic cluster. You know, please be part of that right be part of our effort. Just just the phone. Michael actually that's a great point that there's, we have the ability to create a survey for the booth and so that. Nice. That's it. Moving forward, Nuno, feel free to introduce yourself and ask your question. Okay. Hi everyone so I'm going to get this with me is also under a fun secret we are both from millennium BCP which is a bank in Portugal, and the my topic for today has to do with the issue we have on GitHub, which is related to supporting customer authorization filter. Our use case is that we want an envoy to pass the requests and through a set of policies that an open sidecar will evaluate. So this, we, this is how we expect to do authorization for the requests that we are delivering to the app. And for us to do this pattern. It's something that we would like to use SMI and SM as well to support this, but we believe that this is something that's currently not supported and defining this customer authorization filter, and would like to have your thoughts on this. I think it's a nice idea. I'd, I'd certainly support the inclusion of custom filters in the SMI spec. I think the, maybe the easiest way to do this is if you have an idea on what the shape of that would look like for you as a consumer, so I think that's always a great place to start. Maybe create a, like maybe even a PR, PR is a pretty good place to, to actually, you know, discuss working, working versions of the spec. It feels like there's maybe a natural place for this inside of like the HTTP root group or the TCP root group, but maybe not. I think that's, as I say, it feels like a reconcume on that thing. So if you'd be interested in doing that, I'd certainly be happy to kind of chat with you over this. Try and help shape that out. I think our basic math really was how to package this and something that could be talked about. People look at it and get inputs on. Yeah, I think it's, I think it's a really good idea. I mean, I think the sort of custom, custom filters and extensions are something that folks are just going to naturally gravitate towards specifically as things like Wazim matures as a standard. So I think SMI supporting that certainly like on boy right now has the, has the capability to, to accept HTTP request filters inside of on boy, which is configurable for any of the on boy service matches. The leaf lickety has Wazim capability as well. Maybe I could be wrong about that. So, so I think that that's the key thing that was on boy is your generic your sort of destination technology specification that we propose is SMI has to encompass something which is abstract enough to consider service measures which don't support on boy. But I think it's totally doable. I mean, I think Nick summed it up really well and I echo the same thoughts. At first I was like, okay, well the custom off filter you know that's very implementation specific. But I mean at a high level yeah like if the the end user wants to be able to configure that through SMI that's something that we should have some mechanism to do. But it would be really helpful to understand what like the UX looks like so how does it actually fit into the traffic target object or the HP route group or whatever, whatever it would go into so I think having just even a sketch of like what what you would want that experience to be like will give us a better way to have a, you know, conversation further conversation about, you know, what is the right layer of abstraction and how much information do we need to put in this and, and that kind of stuff so I'm very, I'm very supportive of Paul requests and moving or having an async conversation on that PR going forward and then sinking back up at this meeting. We'll do. Thanks. Thank you. There was a different comment around spiffy identities as well so I think on that on that same thread so someone wants to propose a PR for that as well that would be great, and we can have a conversation about that on the PR as well. All right, moving forward. SMI conformance Lee feel free to take it away. I was just typing a message to new owner Andre. I'm most supportive as well. It's a great, great topic research on on on SMI conformance. I don't know if you are sick of talking about it but I am. It's, it's ready, or you know, like, it's, it's time I think that the tooling is at a point by which, and has been for a little while at a point by which is ready for individual service mesh teams that are interested in owning their own compliance. That's the right anyway, those that are interested in running conformance tests themselves and self reporting. There are a handful of contributors who've worked on this particular functionality of misery that are ready to engage. The summary is was up for review for donation to the CNCF last month and it's up again. We didn't get to it this month. So it's up again here in a couple of weeks. I figured I'd say that just because I don't know just to help clarify the intention of the project. It focuses on, you know, largely like two specs at the moment. There's typically conformance and then SMP on on performance to engage like turns out this this darn thing is not necessarily a small to bigger piece of functionality than it's a decent size piece of functionality. I think that there's probably, there's probably two steps to start to engage. One is the engine X folks had reached out a week and a week ago on quite earnest to to move forward and the next steps are a little bit challenging because they don't. You've got to send a eula to get to their software, which makes which I guess will prove the point of it being good to empower them with the tools that they can run it and self report so actually now that I say that that that all that's not as much of a it's been a hiccup for us in terms of doing those tests but I was considering so so I think like Michelle has two great questions with both of which I was fumbling over just before this meeting and how to engage and how to get started my recommendation is to go is two things one to go try the tool and find a bug. And you know there's there's probably one or two in there is to try the tool and then either depending upon if there's a multiple of the service messages that are wanting to the implementations that are wanting to talk about it that we would schedule some other time to walk through it, either individually with those teams or just centrally as a, as another set of series to engage with multiple measures at the same time. The idea here is that it becomes a self service tool that you're empowered to that each of the teams are empowered to run and. Nice. I find that really interesting really exciting, and I have one immediate like please please request. And can we please add legend that says you know what exactly are the semantics of X. And so like it's, if I look at that I was like, what's the difference between full and half one, I guess, like, you know, you want to make it super clear what what the semantics of that it's that there's I mean it's it's you have it down and more about that. But if you have that the problem that I see is that this fits perfectly in a tweet right someone taking that, and without providing the context, tweeting it. It's like, what does that even mean right if you have a legend that directly sits next to the table saying like this is the semantics, you can still argue like is the true or whatever but at least it's clear, like this is what it means. That's my little feature request here, right away. That's awesome work. Thank you so much. Great time check real quick. So I think, oh Bridget move the flagger comment up. So I just wanted to get a quick update on the flagger and SMI conversation. So Nick, do you have an update by any chance for us. Also, very interested in helping out there. We have folks that can work on it on our side so we really just need to understand like, I don't we don't want to step on anyone's toes I don't know if there's work already been done so Nick you have any information on that did you get to have a conversation. I apologize. Let me change him from from my understanding the welts from off my understanding that the linkity provider is actually SMI. So I hope that it's actually minimal effort flagger just add an alias to provide or create provider of SMI to the functionality that's that already exists around the linkity provider. And that obviously wouldn't break linkity and it adds future spec. Stephens probably the best person to speak to and maybe we can invite him to the call next week as well to talk about flagger for folks who don't know what it is. Yeah, that'd be great so let me just get you to on a thread going. I also think there's some discussion we can have around just having our own SMI provider because we, for example, an OSM or on V1 alpha to and want to get on V1 alpha four and our next release and when we're talking about the conversion logic we decided that you know the hub would be V1 alpha four so it makes sense maybe potentially to have like the SMI provider on a like on the more updated. Yeah, I think I mean the good thing is so when the V1 alpha, sorry flagger currently supports V1 alpha one, which is version of the linkity is pinned to the version console support is actually V1 alpha four. So when I built the console controller when I was using it and dogfooding this with flagger, the conversion logic inside of the controller, the new controller SDK does actually manage to convert V1 alpha four down to V1 alpha one. Successfully the flagger can run, which is actually great because it's minimum effort then for for Stefan. Yeah, that makes sense. Okay, we'll move this conversation a saying who wants to moderate next week. Well, I'll offer to do it this time and I totally forgot so let me offer to do it again and I won't forget. Thank you and who wants to take notes. I can take notes. And keep in mind, Nick you've signed on for multi cluster working group next week so. All right, thank you. And, okay and Michael you want to give us a or was it Michael or Lee, who's the next topic. It's on. Lee, Lee, I'm sorry about that. Okay, Lee, go ahead. I briefly today today's the last day for us to drop some content into the into a Dropbox folder for the booth for the project pavilion booth. I don't know that anyone has done that just yet. They'll have our the logo up there and otherwise. But so the quick call action there's there's a link in the meeting minutes that goes to a doc that has other links that talk about if we'd like to do a survey. And, and if we would like to do and if we have other content to put in there. There's a, we do have project office hours scheduled. And so a few slides for that those office hours to kind of speak over would be good and those same slides are great make great content for the booth. You know, a good starting point might be copying from last time. Okay, who's on the hook for actually doing the slides because I don't think that crowdsourcing is going to work here so I think Lee you're going to have to point to someone and be like, can you do this, and that's just going to have to be the case or if you can do it it'd be great but if you can't then you just need a point and be like please. And I don't see any other way to do it. Sounds good. Yeah, we can, we can continue this on Slack so we can definitely get that content over it'd be really good. Thanks for overseeing everything there. Michael you have something. I just want to say, thanks Lee, thanks for keeping our collective. Seriously. Thank you. Gotta get on it. All right. Tell us what to do. All right. That's it for this meeting. Thank you so much everyone for joining. I will see you next week at the multi cluster meeting and the week after at the regular community meeting. Bye everyone. Happy machine. Bye.