 Hi everyone today is Wednesday, March 17. Thank you so much for joining today's SMI community meeting I'm going to moderate. My name is Michelle Nerly Bridget has volunteered to take notes and run all the things So thanks Bridget. We have several discussion items today that we're going to breeze through First we're going to talk about Bridget is going to talk about KubeCon, CloudNativeCon Europe. I have a discussion topic on traffic split And also the another discussion topic about the CID, CRD, excuse me, CRD API group inversion And then Bridget has a topic around supporting custom off filters to allow delegating off logic to third party components. So if you do have a discussion item, please feel free to throw it in the agenda. And then we'll have time for introductions and any other topics at the end as well. So that's it. Bridget, I'll hand it off to you for your first item. Alright, so nice and easy and short. We have in the past, CloudNativeAustin in fact has arranged for us to do Community session during KubeCon and I'm wondering if anyone would like to volunteer to be in charge of scheduling and running a call for you to promote the project. During KubeCon EU coming up May 4 to 7. It's okay if Lee doesn't want to. But If he does not want to, I probably will end up having to do it and it's terrible if I do all the things. So Does anyone have any interest in participating in that and or running it and I'm looking at you, Nick, Mr. Europe. I was just about to say if Lee doesn't want to do it, I would be more than happy. I am Great. I took, I sent in the form. Oh, you sent in the form. Fantastic. I just because it's like, oh shit, like I've seen that message three times like holy hell we have course of course like and so the Great. Please continue. Yeah. And so the this time I so so I'm taking all the liberties on all everyone's behalf is making all the assumptions so making an asset of it. And so This time the there was a choice with respect to The format. And so last time the format was You know, like, hopefully, you know, and you guys were there, you all were there, you know, the format. And so this time it is Well, I ticked the box for both that plus a bit of booth time so that we can show things in action. And so that we can interact with folks there and I figured, shoot if if nobody else, if, if It isn't going to be the case that none of y'all are going to sign up and everybody's raising their hand now. So that's, that's great. We'll have both covered and I don't So I'll do that. I'll I think the action item is for Lee to add a comment with some info about when and where links and times. And also call call for Content and recordings and like how do we Organizing things Okay, and it sounds like Nick will help you with that. Mr. Jackson See the look of panic on his face when he when it was he thought that I was going to have to do some organization. You're just going to help him with wonderful content. For example, Info about exciting new work that you're working on. This is great. Okay, thank you, Michelle. Okay, great. Thank you so much. All right, so I'm just going to paste a link to this issue that I opened here. The next up the next topic is on traffic. Split. So Basically, I'm implementing the one alpha four of traffic split in OSM and I just ran into like a little bit of ambiguity. So and actually it's been brought up once before by someone, but I wanted to just kind of follow up and give everyone a brief overview so you can throw your thoughts into that issue. So essentially in traffic target, we have a source in the destination. We have some rules that we apply to traffic from the source to that destination and from from a set of sources to a destination. So each rule is basically a reference to a traffic spec. So an HP route group or a TCP route group or UDP route. If we have that in there. So anyways, there's some attributes that apply to those rules and a rule can have an optional match condition. So you can say in an HP route group, you can specify Different types of matches. So one match condition would be you want to match on user agent Chrome or something and then another match condition might be like you want to, you know, Match on some path with some other header, for example. So that's all well and good. We wanted to do a B split a B deployment with traffic split. So we applied Matches condition on the traffic split. And so what happens now in the way that we've defined it in SDK and I have the actual lines of code emblem are linked in the issue. But traffic split doesn't have a set of rules. It has a set of matches and matches is just a slice of typed Local object references in Kubernetes. So you can say, Hey, match on these HP route groups, but there's not necessarily to my knowledge a way to specify like Within that HP route group object like the actual match condition. It can have a set of match conditions. So right now the way I'm implementing an OSM is that I apply rules for all of the match conditions that are in that object. But I'm just kind of wondering, do we want to go that route. Slightly ambiguous. Do we want to match on specific conditions with a traffic split. Any immediate thoughts. Has anybody else run into this issue. So I have, I've, I've hit this issue a number of times. And the key thing that I always fall down on is the lack of a virtual service. Now I know that's a kind of a like a meta element, but That like to be able to do traffic split and to be able to say I want to route 20% of traffic to API primary and 20% to API canary. I'm wondering whether it would also be useful to be able to have a construct where SMI could define what API primary and API canary was as like a definition for a virtual, you know, virtual service, which could be a have selection criteria. Or maybe need both. I'm not sure I understand what's missing between the traffic split and like the concept of a virtual service. Yeah, so, so I think it's It's, I mean, it might be specific to console, but, but console has As the concept of, of, I'm saying it's a virtual service, but you can basically create a A service which is an aggregated collection of endpoints and you can basically specify metadata. So I could say, hey, give me all of the endpoints which are tagged with V1 and the service name is is API and then I could create like a virtual service which is like API dash V1. So then in my my traffic split, but that you see that service doesn't actually exist. So, but that's fine. Like I could still reference the service and have the meta criteria from from within SMI, but I have to create the virtual service definition out of bound of SMI, which, which always feels a little It still has exactly the same thing. It still's got traffic. I forget the name of the thing. Leo tell me better, like traffic director or traffic thingy, whatever it's called. There's a block where you can basically Yeah, destination rules. Right. So, so maybe it's worth thinking about the inclusion of that as well. Yeah, I'm down to think about it. Do you have an issue already open for it? I think I created one at some point and I would gladly re-raise it if it would be I could maybe just create like a rather than an issue issue. Maybe it's easier if I mock up what I'm thinking and then we can figure out whether it's worth looking at. Yeah, I think that'd be helpful. I could definitely rabbit hole on this because I think OSM just uses is it's native SMI. So we just use Kubernetes services for everything. So we haven't necessarily run into barriers here. Yeah, I mean, it's, you know, to be honest, it's not in terms of like we can use Kubernetes services and console as well. But the problem is we have to configure the Kubernetes service. Yeah, which is out of bound of SMI that that's that was, you know, it's not, I say it's not a problem. It just feels disconnected that I've got to do some stuff in SMI and some stuff in in my native platform. And you would have exactly the same issue, I believe with Istio that you would end up setting up the, you know, the traffic. route, which then creates the service and stuff, but it's out of bound and probably with with maybe OSM it could benefit as well. Let's chat more about it. I think this might be parallel, though, to the matches conversation if I'm not mistaken, right? Okay. On the matches, if we did want to go continue down that route, do we would we want to specify on certain match conditions or do we want to leave it so that you just reference the types local object reference, which is an H to be our group, which we don't validate, but in and you just apply all the match conditions in there. You would have to see any sample. Okay. Yeah, that's cool. I'll just like throw the issue there if anybody has any like thoughts around it. Let me know. And then I'll also dropped up an example on that. Yeah, because I think I I just I completely agree with you, Michelle. I think then there is something that needs to to be done with with that area. The last time I was I was using it, it felt awkward and and it was it was based on knowledge of implementation at a particular time. Yeah. Okay, cool. Sounds good. All right. So one other thing I had was just an update on moving CRDs to V1. Is this issue I picked it up like yesterday and I'm just I'm working on it and I just wanted to say, hey, I'm working on it. So it's coming and basically if we don't update it. S minus one dot two two of Kubernetes is not going to work. So that's it. So I got what's the next topic Bridget, I'll pass it back to you. Oh yeah so I was taking a look at anything that had come up since our last meeting and I think this issue actually came in right before our last meeting but since we haven't commented on it at all I thought maybe I should make sure that we at least update it if we are you know going to have any input for this person and they were asking about supporting a custom authorization filter to allow delegating authorization logic to a third party component specifically they wanted to configure SMI to use the Envoy authorization filter. And I thought hmm we should at least bring it up we're not going to necessarily cover it in detail here but we should at least bring it up so that we can figure out if there is somebody on the call who wants to take this on and put some comments on it. You know completely say no this is not something that's going to happen at all. I mean I think it's a sensible, a sensible idea. I would sort of also add that it feels like there's a specific implementation in mind that somebody has and may therefore maybe they're the best people to present a spec change on that. Because I wouldn't say I've got the sort of the knowledge to, I mean I think it feels sensible. Yeah, from my perspective the request and concept feels fantastic, feels great. The fact that they've called out Envoy filter and OPA has two specific technologies are highly relevant, highly appropriate, you know popular. Also our two specific technologies of which hopefully we would ensure that the design would ensure that something like caverno would potentially also work for as an off system and maybe not just NGNX or Envoy filters but filters of other. I mean I think it's an interesting thing right and to like echo these points like Linkedee obviously is an Envoy based traffic traffic mesh isn't Envoy based uses traffic proxy. Both of those may have a comparable feature, but it obviously certainly wouldn't be with an Envoy and I as popular as Envoy is it kind of, I don't think we should basically write a direct, you know, we shouldn't be directly exposing Envoy features without considering an abstraction as such. But as a as an abstraction it, it feels like a sensible thing to do and I would I would recommend like yeah I think the person who certain issues probably the best person be able to come up with the. NGNX service mesh with NGNX plus as their proxies kind of another to add to the list and to also highlight that filters or that proxy has pluggable filters as well. And so it is a good. So question is as well, do we do we also jump the future proof and just think in general filters and define filter types because wasm filters are like, whether you, you think wasm filters are the new hypo or not I think wasms pretty, pretty interesting so we could even start thinking about how SMI could support that side of things as well and it might just be something where it's filter type authorization or type request filter or something like that and you can get away with a generic abstraction which would be. I just want to jump in here, I think that's an interesting idea supporting optional wasm filters, but I also think that there's maybe an I agree like I would really love to see a spec change or what this user is envisioning. So I'd love a contribution from them, but also like it's up to the implementation and decide what like other technologies they integrate with so you'd have to like for OSM you'd have to like enable OPA integration or OPA usage and we have to be able to support that so I think. Like specifying that filter is the implementation level, and then for us like we need to be able to support the type of identity that folks need in order to use that off filter so right now we support service accounts, and I think we might need to support like to other like maybe something in order to support OPA so I think that there's like two ways we can go about it we can go higher level and figure out what the higher level abstraction is, but also at a lower level, what identity needs. Have we not met in SMI that we can add to the spec in order to like fuel this kind of integration. That's an easy set of identities that you currently support somewhere that I can reference, because I have some people that would be two different people that would be interested in us. Yeah, that'd be great. We support service accounts right now solely. I think there has been talk of supporting spiffy identities. And we haven't added that or have had much request for it. So yeah I would be really interested in understanding more. Can you put as a comment in there what you do currently support just so that it's really clear when I link them to this issue please. Yeah, definitely. Pretty sure it's only service account and the rationale behind that is because it's cryptographically verifiable within the cluster. So Bridget I think we have some next steps right we want to ask the user for or the person who submitted the issue for like what they, what they're looking for and, and we can also talk to them about our thoughts around what kind of identity needs to be supported and also if they're looking for some sort of high levels filter specification. And then I'll add that link to the service account stuff for Marlo. Okay, I did not write down everything you just said but I will follow up with you and make sure that that person gets their answer. Yeah, do you want me to update the issue if that's easier. If you would like that sounds wonderful. Alright, anybody else have a discussion topics or want to introduce themselves. Hey Nick, what's going on with the SDO adapter. And do you need help. No, I haven't. I haven't done anything. The proof of concept around the SDK has been pretty good. I've just been getting the service splitting stuff working really good with console so that I can use flag it and been kind of working which has been keeping busy and but it works great and I love flag it and I am the biggest convert in the world to canary deployments with flag it. The, I've got all the like the build stuff. So being able to, I think the key thing around that is just support that very narrow subset that we need to do to unblock coop flow so that then coop flow can then come. The coop flow is SMI compliant. It obviously then can can be used by everybody who supports the SMI which is a really cool thing indeed. So, like, if I can find some time this weekend, I can maybe present that to all next meeting. Awesome. Can we move the SMI controller SDK to the SMI org or service machine or Facebook. Yeah, I just created it in my personal repo because I don't know whether you'd hate my junk or whether you wanted to like get some somebody who knows how to do it properly or, you know, I'm supportive if that's good for y'all and I'd love to hear from our maintainers. And I think, from my perspective, like just giving a quick update on that it, the new cube builder stuff just works really great. And there's, there's a lot of stuff I think we can, you know, we can, well, I think it's always going to be a problem for us because we asked the SMI go SDK which is a hard dependency. You know, cube builder can do things like generate all of the CRDs and it can create customized config and stuff, which saves a little bit of maintenance. It's not necessary. But some of the stuff that you can do with with auto generation is kind of neat. I don't think we're going to be able to take advantage of that because of the SMI SDK, but it doesn't really matter. It's not, it's not, it's not a massive, a massive problem. So yeah, I mean, if, if you'd be interested, I can actually just blanket transfer that over to you all. Click that button. Yep, big, big plus one for me. Good. Could I ask Michelle in the short term, could I be like get pushed rights on that without having to go the whole kind of pull through a while, so we're just thrashing. Yeah, thrashing that controller out. Simplify the workflow rather than having when I'm just pushing random commits to it. Yeah, I'm good with that. I think in the contributing guide, we should just like say, hey, like this is what it is for now and we're good with it because this is something we're experimenting with and trying to like make work and especially for the AC adapter. It's really nice to have that in that. Yeah, but it's it's been, I've been like, you know, dog fooding it with with console. And it works great. Like, it's totally, it's totally great. So, Hey, I'm in the SDK code base right now. And fixing up things because we don't have like auto generation of series is a huge pain. So, would it make sense for me to move the SDK to co builder. Is that do you find that helpful or do you think that's like kind of a go waste. So, the question it if you can, I don't know whether you can so I think the problem is that co builder doesn't use so like the, the SDK, the SDK generates all of the, I forget the name of them but all of the stuff. That's right isn't it like all of those auto generated resources. Yeah, you know, like the API folder so you've got like the, you know, see, I think it's like the list as and the, like all of the, the internal mechanism for building stuff like that in terms of inside a coop. I don't think co builder generates those because cube for builder manages that internally. So, you, it would be great if you could. Okay, I'm going to look into it. I don't know. I haven't really touched co builder much, but I've only heard really good things that's all. Okay, so I don't think we have any other topics as anybody have and like, please. Yeah, I had one hopefully it's quick so during the last meeting there. We were talking about multi cluster Federation and scheduling a call on the off week to kind of dive into more detail of what folks requirements were there. And I'm wondering if there's anything on any agendas are in slack of whether that call was scheduled I'm wondering if that happened and if not, is that something we still plan to get on the calendar. I think I dropped the ball on that let me do that right now. Not mess that up. Thank you. Okay, thank you. I'm interested in joining to. Okay, well, I will schedule it Michelle. Thank you so much Bridget I appreciate that. All right, you get three minutes back. Thank you so much for joining and see you on the multi cluster call, hopefully, and if not that next SMI community meeting in two weeks.