 Hey everyone, today is Wednesday, March 31st. Welcome to the SMI community meeting. I'm going to be monitoring today. My name is Michelle and Bridget is going to be taking notes. Thank you Bridget. So we have a few discussion items today but it's a light meeting so if anybody wants to introduce themselves at the end or once and bring up some ad hoc discussion topics, you're welcome to do so. The first topic is Lee's topic. It's about the KubeCon booth and office hour details. Take it away, Lee. Just in time. Very good. Well, I work at HPE now. And so, even though the background may, yeah, no, no, it's a DockerCon, you baby. Bridget was probably sitting right next to me at the... All right, I apologize. Hey, I just got some, I just got details on the virtual sessions that are available to us and the, well, I'm sorry, the breakouts, the office hours and the virtual booth that will be available to us. I just put a link into the meeting minutes and so that might be something to share here briefly. So just if it is, time is against us. I think there's a, I'm not too, I'm only like a day tardy and sharing this info. So please don't kill me as I say that some of the materials for the booth would need to be, I guess the deadline is this Friday. So there's, I've kind of copied and pasted nearly all the details into the, into a shared Google doc that hopefully all of you can get to. I think as you digest what's in the Google doc, probably what we would strive for, and I realize this is maybe a lot to ask of the, but is to have some amount of coverage in the booth or see how much of that we can try to cover. The office hours. So, so the project booth off hours are listed in there. Hopefully we would get enough maintainers to try to have a person covering most of the time but the materials that we would leave behind for people to pick up as and when, or watch a recorded video would have you it would be, they're in the absence of any of any of us sitting there. There's, as a sandbox project we're afforded up to two office hours or up to two sessions. Kind of a question to all of us, they do we, we're looking for one of those or two of those. And do people have an opinion on the format of those. Or should they be about, you know, should we do two and should they be the same or should we do one. So it sounds like we need people to sign up for all these various things so there's a link in the notes. And Michelle has a great idea Michelle you want to add that. Yeah, I was just going to say, we really need it like flagger has a semi support, like sort of. So I just want to, like, get that finished off. Oh, oh, Nick, do you have a demo with like the latest SMI. Did you contributed to flagger. No, but actually the only thing that needs to change in in flagger is the provider name. So it should be a really straightforward I've been meaning to sync up with Stefan. Currently if you use like the link a deep provider. Yeah, just leverages SMI but it works beautifully, as long as you can support. I think it's like API version one or two of the service splitter, which if you use the new SDK quick plug, you get the automated conversion webhooks so even if you're running version for it, it just works out of the box. Cool. So do you want to work on the flagger contribution do you want me to help with that I'm just trying to figure out a place where I can help with this stuff. I think I was in. Oh, as they get down dinner. Okay, it's fine. So we'll talk to him when he gets back. All right, so we have a sign up sheet, you said, Bridget. In the Google doctors. Yes, there is a link in the meeting notes and I am also dropping the details doc that we think you created into the notes of rent the chat of this meeting, but it is available in the meeting minutes. And so this is all the info and we, I guess, need to get people to sign up for these office hours. Yeah, the other thing that we can do is maybe like two other things we can do one is, I just grabbed the template for cube county you and put it out there for all of us to figure out what slides we might want to talk about over the office hours, and or potentially slides to also loop through in the virtual booth. So a little some of the wording and the instructions a little bit confusing as to how many different videos could be shared in the virtual booth, because some of that, like some of that is stated in terms of your sponsorship level, not necessarily in terms of your project level. So, I'll clarify with the organizers about that. Also, I've sent out an clarification on, there were five passes included for both staff. And since we have more maintainers in that. Okay, what do we do in that case and sort of ask essentially ask for more twice as many. And I think some maintainers already have a coupon pass though so like I have I have one already from presenting in the maintainer track for how, for example, Michelle, what are you going to say. Nothing. Okay. While I do have the floor though, I just added a needs maintainer comment to the doc wherever we still need a maintainer to sign up so please comment if you can sign up for that time. Okay, so I think the calls to action Lee are to sign up for the booth and to. I think it's a sync with you async on who can do which slide. I think it, like, in my opinion, just from doing these in the past, it helps to just have two or three people from the group to people really ideally to just do the presentation rather than spreading it across a bunch of people. Would you be down for that strategy or do you have another specific way that you want to go about it. Yeah, it I agree, just like it, just like a design spec like somebody's gonna write some one or two people need to write the thing everybody else can comment and change and. Okay, so I guess you would just need one more person like one partner to kind of pair with on presenting and doing this presentation correct. Oh yeah, please, I thought you meant writing it up but you mean also also like walking through the slides and speaking to it yeah that sounds about right as well. Okay nominate Nick. He's like, uh, no. Happy happy to do help help however. Okay. Cool sounds good so that is good. Lee anything else on on that. Just the Friday is like, hey we'll try to get the kind we'll try to do this post haste. Okay, so then. Do you need the booth signups before Friday as well. I don't believe no. So just the presentation before Frank. Okay, great. Okay. Thank you. I'll review the slides as well. Okay cool. Next conversation is about the SMI controller SDK project, which has been moved over to the service mesh interface because it was donated or service mesh interface GitHub org. So it's donated by Nick Jackson. Thank you Nick. Thank you so much for your contribution. I did get a chance to review it left some PRs and some issues. So we can kind of like work async on how to, you know, do the next steps had a build error that we talked about earlier. And then I also added a contributing doc and like all the, you know, the OSS hygiene stuff. And then going back to the build. Oh, actually, two things I wanted to just discuss quickly. One is governance and like PR reviews so in the contributing doc I just put in that that PR needs to be reviewed by you Nick before getting merged, which I think makes no sense because you're the one who build a project and has the most have the most context on it. Is that cool. Yeah, 100%. So it's pretty predefined what needs to be done in terms of getting that to the same specification as the the go SDK. So maybe if I tackle maybe creating like a little project, because, because of the different ways, the different sort of implementations for the different bits of the spec. It's totally possible to do all of that async as well. Maybe we if we create like a little roadmap of what needs to be done. And then we can just like I'll put my name again some stuff if you can work on some stuff Michelle, you know, and we can we can kind of figure figure out how to divide and conquer all of that. There's also work that needs to be done around the go SDK to do the conversion webhook stuff. So with all of that, it's, it's pretty easy going it it's, it actually makes a really great first contribution from for any go programmers or folks who are learning how to program go and would like to contribute to SMI. We can maybe walk through walk through that. And that will be done by coupon. Yeah. Specifically, I think around the the bits that you you need for for support. Thank you. Yeah. Yeah, so, so, like, why don't we do that. Well, I don't know, really, but yeah, anybody, anybody who would love to start contributing. I would definitely love some, some help around specifically the the conversion webhook code that needs to go on to the main SDK. You know, ping me around that and I'll happily show people what needs to be what needs to be done to implement that but it's, it is just kind of converting one object to another, using the sort of the coop builder interfaces and things. It's a great opportunity to learn some go as well if you're interested in doing that. Awesome. Well, Michelle, Michelle wins. Anybody else who wants to contribute this welcome to actually have some new people in the community who would be great. I just, I just really want to help with the SDO stuff so anything I can do to help move the SDK, the controller SDK or the SDO thing along would be please just tell me what to do. Awesome. Well, let's let's chat chat async after the after the meeting. I'll fix the bug, which I'm pretty sure is just a reference and I'll get that uploaded for you. And then, then we can chat because I can put some time together tomorrow morning to to work on some stuff as well and maybe get the first of the initial PRs from my private branch. My, my fork of the go SDK merged, merged upstream. It's, yeah, it doesn't impact the go SDK, which is a good thing. Like, it's not going to have any breaking changes for anybody who's using that but it just gives us the ability to do those conversion works was just sweet. Sounds good. Okay, cool. I'll sync with you. Anybody else have anything on the as my controller or the SEO adopter that they want to bring up. So one more quick question which is if there's any further people who've come and talk to you guys about the security piece, because the six security group is interested in those being separate, but you cook you. You conflict with their weekly meeting for the CNCS security. Yeah. What, um, what security piece are you specifically referring to having it so we, there can be plug and play of authenticators with the service mesh. Oh, okay, okay. I remember that issue from last week. Yep. I think we did correct me if I'm wrong but I think that we were talking about that we were saying, I think we landed on this might be something that the implementation handles rather than SMI or did we want to kind of further explore and propose. A way for people to plug and play the off piece via SMI Nick Lee I think y'all were involved in that discussion as well. I'm going to paste the issue to 13 in here. Let's all just take a minute to read the issue and kind of collect some context so we can have a better discussion about it. So I see there's a need for spiffy. There's a need for SMI to support specific spiffy identities. That's cool. So technically supporting spiffy identities would be really easy, because that's that's all implementation. It's basically the provision of a string. And the creation of a type, whereas we have service account we would have spiffy ID. We would also say that if we were going to support spiffy ID. We need to support some form of gripping or globbing within the spiffy ID because the spiffy ID is obviously composed of the service identification. The unique ID the service the group etc etc, depending on how you, you cut that up. So potentially for for to make spiffy ID you would need to have, you know, a way to kind of say it's this part of the spiffy ID either the domain part or the the service part or as I say, there's no hard rules on on how you define that but it's just a URI so regex with a URI based syntax would would probably work. It makes sense to to me to support that. I don't know whether we would need a filter and, and I don't know. I mean, I'm not against the idea of the extensibility my, my concern is that with filters you're starting to talk about implementation details. So it's, can we create a method that allows to to not worry about implementation detail. So the problem that we have when we start talking about the sort of the hard coding aspects around spiffy ID and I'm not saying it's a reason why we shouldn't do it but it's when you have to bear in mind. Not all service measures use spiffy ID as their, as their identifier. So if you, if you have a traffic target which depends on a spiffy ID. You break the ability to have a portable implementation of SMI. So that's that, you know that that's not necessarily a problem depending on what your use case but it's it's certainly something that that should be considered I think. Like, if we supported spiffy IDs, like the simplest solution would be, in my opinion, to add like in the sources list you can have kind specifically spiffy and then you have a string, and that's like the easiest way to do that. I see what you're saying about portability, but then do we say oh you have to like embed the spiffy ID in a like service account object or a secret object or config map object because that seems like a barrier to entry and like, I don't have a new Kubernetes object for and also like, you know what if folks want to like not use Kubernetes like we were definitely going towards like hybrid scenarios, at least on our side. So, um, so that, that's the topic on to its own about SMI like I'm happy to hear you say that kind of thing. Sorry to interrupt. I just like it but it's just been stated like so, like front and center on the SMI spec page that like the word Kubernetes and how centric it is and how that's something that I'd poked at Brendan and gave about a couple of you know, my year and a half or whatever a couple years ago whatever it was that but yeah so I'm supportive of that statement Michelle and kind of the same thing that Nick was articulating around Marlo's use case or the use case is described in the issue being really intriguing to me or like interesting and like yeah why hey why wouldn't you know SMI as a you know have a spec that covers this kind of a thing that it's in entirely a coincidence but the fact that I'm wearing an HPE shirt is like is weird because of the interactions that I have with folks there. The, the spiffy folks that are there have been keen on seeing spiffy inspire but you know spiffy as well. They've been represented across all of the service measures and supported by them and so you know as a project that you know that sort of I don't know that the project represents them all but to the extent that it does. Yeah. So what may be helpful is to get a couple of them to come and talk to this meeting. I'm one of them being Frederick who's already commented on there and and have a discussion. The issue is that this does conflict with security and this is a security thing. So it may be useful to have a one off. I think it's very sensitive supportive of of adding. I think the other identity, the sort of adding spiffy identities that the key thing, sort of for me is, is not whether we should do it it's can we do it in a way that creates portability. And whether the answer to that is yes or not and if the answer is you can't do it you've got to accept that with security portability is, is not possible. Then all we need to do is just document that as a, as a decision and we forge ahead and, and create a spiffy type. And I think, I don't know, what do you, what do you all think. I mean, I think it's probably worth creating like a draft of a of an identity and how it would be used and maybe just get some thumbs up on that issue and if it's, if it's acceptable we just merge. And I think Michelle's proposal around the, the, the sort of the extension to the, the grouping for the splitters. Yeah, like some stuff in the SDK would have to change but I don't think that that's an issue. I like the idea of kind of going with that simplest approach. I think anybody disagrees on like wanting to support spiffy identities, or really any, I mean there's going to be a multitude of types of identities we should support. And even in the spec it highlights that we only support service count for now and we want to add other identities. I think at this point it's a matter of a proposal. I think that's pretty, I think a simple thing. I'm happy to help with that Frederick, if you want to do that you're welcome to do that. And from an impulse implementation perspective just to kind of like go into, I think how we would implement it is, we would essentially if, if there were a spiffy identity and like our implementation didn't support it we would just throw an error in the, in the docs. Nick is that how console would essentially implement it as well. Yeah, I think so I mean so console does use spiffy IDs but we don't expose them to the end user. So it's, it, it wouldn't, you wouldn't actually be possible for a user of console service. I mean you can find out those IDs if you dig but yeah basically if it wasn't valid you would we would just have to throw a valid we'd throw a validation error and say you're trying to configure blah blah blah with these two services. And we can't find services which exist for those IDs and I think it's just a traditional validation problem same as we do with the service accounts. That brings up a good point like who actually exposes the spiffy IDs to the end users and I think SDO does if I'm not mistaken. Maybe it'd be worth looking at other implementations that use spiffy but regardless I'm not like opposed and I think we should be adding a multitude of identities. Anybody else want to chime in on the this conversation. Yeah, I think that that particular section there's two schools of thoughts here and they're both likely to be used in both environments. I think that it is important to have something where you can have a transparent mode they're just going to be applications that have no understanding of spiffy they don't care about it in security is around the network is the infrastructure problem. They may have their own tokens or things that they drive but they don't really care about what they're what they're running on. And then you have other environments that they're looking to drive that identity down to the application level itself. The application consumes and validates at the TLS layer itself and applies its policy and it makes decisions on what to do with the at the L4L7 layer even with including things using like the JWT token so spiffy can do a X519 or JWT that's signed by that same X519 certificate to to use as a token and you set the audience as to what you're communicating with. So there's there's multiple paths towards that but some of the some of the infrastructure that that I've been looking at is less about how do you identify how do you create an identity within a cluster, but is more and is leaning more towards how do I identify. How do I create an identity for a workload in a, in a, in an enterprise that I can then use that identity to validate against services that are not in my cluster that so I can do cross cluster or even cross organizational strategies that are holistic for the whole organization. And one of the big problems we run into right now is that all of the identity strategies for most service meshes are they weld identity to the cluster. And when you try to do a multi cluster identity, it's, it just doesn't, it just doesn't work. And so that's, those are some of the things that I'm seeing in this particular in this particular space and I think there's a lot of value in trying to work out is it possible to do something that the SMI yes we do something on identity, but also in the long run, if there's a way to help guide people towards a global identity strategy or at least a company wide identity strategy, then that would be highly highly valuable. Yeah, I mean, I think, I think we have to be careful about implementation. I mean, I'm, I'm pro spiffy. And I would recommend folks, folks use that but I think we've got to be appreciative of other methods, just for a very quick bit of context that the reason behind service mesh. The other service account was that it was down to the implementation to do the ID look up based on. So you would basically look for application instances or pods or whatever, which, which use the have a service account applied to it service obviously you can control the application using our back etc. And then the implementation would would look up the the actual underlying ID. But you're 100% Frederick that falls down when you're outside of Kubernetes and we you know I think it's valuable for SMI support broader picture so I'm totally supportive of this if you want some prior art look at for before Kubernetes existed things like his tricks and Netflix which service messages are a downstream or the descent for that. And you'll see that that was originally a company wide strategy, not a lot of cluster strategy, and then the way we developed service mesh within clusters was a hyper focus of those technologies into a single cluster so in a way it's, I'm not saying it was a bad move it was smart for for what they did at the time and they saw but we're running into the strengths of those bigger paths, and I also agree it has to be the best case scenario is it's something that we can, we're not dictating implementation, and I don't know what the right balance of that is like that's that's going to be a fun area. So it's, I think it's not finding that flight that framework that allows you to, to do either that if your service mesh doesn't really let you do that then you don't really have a choice but if it does then you have the option to, to bring that into into the picture and plus striking a good balancer is going to be important. Yeah I mean, I mean if you coming next week right Frederick. Would you like to draft a PR on what you would like to see with with traffic access control and maybe we can talk about it in the next meeting and just get that rubber stamped and merged. Would that be cool. I'm happy to put together some some material and see what we can do in that in that particular space and I think this is something that we have to look at it oratively I don't want to just draft something and throw it out and say okay it's part of the spec and I don't think you're suggesting that either. But, but I think it's an area that like I don't, I don't fully understand everything that in terms of where you're trying to set SMI from a level. So getting some help on that would would be as well I'm happy to write material here and to provide an understanding of the problem and to propose possible solutions towards that. Yeah that'd be excellent and you know feel free to DM me if you want to bounce ideas of me and obviously I know Michelle like I'll volunteer Michelle as well. I can always volunteer me. Hey, we're at we're over time. But thank you so much everyone for a great discussion Frederick let's, let's definitely talk via slack and also post on the issue just so everyone can follow along. Next week we have a discussion on multi clusters so this is super relevant for that as well if you could join and if anybody else who wants to join that please see the slack channel for more information. And does anybody want to moderate next week. Volunteers for moderators next week is our one off Michael Michael already said he would volunteer. Oh, awesome. The week after that. Okay, the week after that does anybody want to volunteer. Nick does. Oh yeah. I'll take notes. Thank you for it. Alright, have a wonderful rest of your day. Thank you so much for joining and we'll see you next time.