 you're all awesome not teamwork we got there eventually so welcome to the SMI community meeting April 28 and this is the the usual meeting where we kind of discussed more so the specification not be the bi-weekly meeting where we are discussing things like service match Federation so we've got only a couple of discussion items an SMI controller update from myself a request for a bit of bike shedding on a PR from from Bridget and chat about some KubeCon EU which is coming up next week of course which SMI being a project is playing big part in and also Lee chatting about aligning SMI S&P and Mechery so pretty good agenda and do we do we have any new folks on the call who would like to introduce themselves if not you know be absolutely free to stay silent alrighty so shall I shall I kick things off then with an update on the the SMI controller SDK so where we've been going with that is we've got a an official PR which has been raised against the go SDK and that's to add conversion web hook capabilities to the existing SDK so the approach that we're going to take in the the short term is that the existing go SDK which is used by pretty much all of the existing adapters is going to be maintained alongside the the new controller SDK and we're going to figure out an elegant way that those objects can can eventually share the same space without any any duplication but we might need a little bit of you know just some some clever GitHub actions or something in the in the short term but but the intention is that both the new controller SDK and the existing go SDK the objects which are defined in there will will coexist and will be interchangeable which will make the upgrade process smoother what we're also doing is bringing conversion web hook capability to the old go SDK so anybody who's who's using the the existing SDK will will be able to define conversion web hooks now so that it'll make them easier to support the the newer versions of the specification as it's as it's released so that that's ongoing just ongoing work there and we'll see some more of that over the the sort of the coming weeks it's pretty much Michelle and I have been plugging way through that and next up we have a request from Bridget and I'm just opening opening this up so Bridget has I don't even try doing the screen sharing so I'm just going to copy and paste the the PR into the chat there but Bridget has raised a sort of a request for for comments which is clarification of scope for service mesh interface and that clarification of scope is coming from the multi cluster working group and it's intended that we start to think about SMI as a as a specification which encompasses other workloads than just Kubernetes specifically virtual machines bare metal and things like that now that that's not necessarily going to to change the the direction but but it would allow for elements of the specification which are specific to to those platforms I think this is a really good thing personally because it it enables the work that we're trying to kind of get through around multi cluster and federation and it also brings the capability that SMI is wider spread than Kubernetes so we can support all of those other workloads that folks are using so please take a look at that add your comments give it a thumbs up if you like and then we will we'll get that at some point merged into the charter hopefully or not merged into the charter if you all disagree and think it's a terrible idea can we maybe time box that a little bit because the current point in time it sounds like you know as we say in the fullness of time which is kind of like whatever can we maybe say you know some expectations I'm Bridget doesn't mention what the expectation is on there now generally the way that we we kind of run run those things is that if it gets a sort of a quorum of votes from core maintainers then then generally those things sort of go in my in my personal opinion I think this is a fairly sort of inoffensive suggestion and something that's probably gonna happen but let's say by the next the next meeting we that we can we can merge that in in seven days time I think that's that should be plenty time that sounds as well yeah which would be before well so Michael we're not having that multi cluster conversation next week right next week is it's cute you correct correct so yes so that would actually be nice if we could at KubeCon next Wednesday understand that's where we have our little online session maybe already report on that if someone asks like is that currently specific we recently decided to broaden the scope yeah just because we define the specification in YAML doesn't doesn't limit the use cases you could write a controller for anything which I think is really really really cool to be to be honest and and that's all from from these two points Lee next week is KubeCon I'll hand it over to you yeah he oh you know what I don't think that we have sharing abilities necessary oh maybe Michael you might be able to change that that was exactly why I didn't I didn't try sharing for what oh yeah like sorry I need to say yes let me um where is it allow multiple participants try again okay there it is very good um so on this topic next week if you if you haven't seen a tweet about this next week's KubeCon and like like last time I think it was only last time um we ended up we have a so SMI has project office hours um four an hour actually which uh on the surface of it feels like a long time um so we have we have a couple of things to to organize around and for all of the maintainers to participate in and all that aren't maintaining but are engaged and interested to come to come and engage and and converse um those two things are a project office hour is scheduled for well I'm looking at the time and that looks Michael is that the time that I think this is an hour off um so it should be unless no no no okay I'm doing my I had yes three to four central yes that's what you shared with me or us yes very good so there's a there's um there's a session that's reserved for that hour I'll if someone else doesn't I'll drop the link into that session here um question for those so so so I anticipate Michael will um is gonna do his best to be there so he's gonna be you know on the lit so so next next week when we we host these office hours we'll end up um engaging with people talking about the questions they have we'll also have some slides in the background to use as fodder for a conversation and to Michael's point one of those slides would ideally and hopefully be that there's been the slightest verbiage tweakage in the charter that says kubernetes and beyond and uh so what I'm looking for is confirmation for those that think that they'll be there to um you know to sit on the panel and right I would tell you the only challenging thing or if it's not entirely clear because I was just saying you know central this is you can't you right so this would be 7 a.m for us west so if you're on us west either get up very early or you skip that east if you're you know somewhere in US east not a problem but um for for west it's really early the document says 6 a.m is that correct um so I've done it for sorry yes that's 6 a.m okay good that's 6 a.m as far as the slide with folks I know those are the maintainers um I wonder if it needs updating that might be a separate conversation yeah the more the more the merrier I think we should um you know but that's I think that's the panel right yeah we were earlier talking about the sort of the thing from 6 a.m pacific or or 2 a.m might a 2 p.m might think this is the office hour we're talking about right and what you see here is yeah in this case one and one in the same so the the panel is the is what would be hosted over the office hour or like the I think the two terms of being used interchangeably that during the office hour we would um people generally come by you know a lot of times oh sorry sorry my bad yes sorry my bad I was mixing it up with something else that it's also my calendar but different thing sorry the apologies ignore me there is a there the topic of um that is another topic to address though about um to to review the those that are maintaining and potentially have that list updated or have have some move to emeritus or invite new ones or and part of that has been a topic of conversation in the past about what are those criteria I was there's different ways for us to approach it one is to define it ourselves two is to lean into CIG contributor strategy and part of the guidance that they're giving for like what would constitute engagement and maintainership and what is maintainership and these things right now that's universally left to the and will continue to be left to the individual projects but they might provide some some guidance as to what that is we have an open issue to define what it means to be active there are some maintainers now that denounce the notion that there is the world is comprised of multiple meshes that there's just one and only one mesh so the question is whether or not those whether or not this this project continues to be of interest to those people Lee can I table that um I think that's a yeah a really a really important thing that we we should discuss why don't we why don't we table a conversation for what would be well 14 days time from today where we actually have that discussion as an agenda item about the core maintainers because I think when we originally set the guidelines out there was some very loose stuff that we put in which was around if you're not active within three months but but I think it also gives us the opportunity to bring new folks who've been contributing to to SMI and participating in the community who are who are maybe not in the sort of the core maintenance group and and also the opportunity to welcome them into to the group in a more formal aspect as well so why don't we um why don't we add that to the agenda for our first meeting back after kube corner because I think that's a great a great thing for us to to talk about and formalize and if you can share some experience on that as well if you wouldn't mind can I can I ask you to to lead that agenda point because I literally know nothing about the the way of the other seg working groups sounds great um so the other thing that the project has is a booth a virtual booth in the project pavilion and so um for any of you looking to coordinate on potential virtual handouts um let me know um we're over the deadline but my understanding is that that may not be so long as we're willing to do it ourselves there's still I think the avenue to get those in so so for the rest um I guess I guess the ask here is to move on is um for those maintainers who might be available for that office hour please let me know so we can um represent you appropriately in the deck for those um maintainers um that are going to be there as well if there's additions or changes to the deck please engage jump into the deck um I just uh 20 minutes ago quickly copied some slides from last year last time to this time so so on that I think right ready for the next agenda item yes this is this is somewhere specific uh that folks can find this document can you I'll drop a link to that on chat or something yeah you bet it's um also it's in the last um couple of meeting minutes I think okay cool that's a great question yeah so back back over to to you Lee um so now you I believe you Kenny you're going to talk about service mesh interface service mesh performance and measuring and how those uh three three items align yeah so um the Genesis so we're only going to make it so far into this particular discussion but um when I I've got the wrong deck up so otherwise I'm going to share a deck and I'll look for it here but um so so um some of you reviewed a blog post that went out yesterday about measuring being the conformance tool for SMI and that's been way too long in the works right there's more um engagement with each of the service mesh projects each of the service mesh teams about how they're empowered to self you know there's more about that tool and to engage with each of the teams um the um measuring as a tool uh and service mesh performance as a specification centered on performance um those have both been proposed uh a couple of months ago for adoption into the CNCF they were up for review a month ago um the CNC the TOC didn't make it down that far in the list to evaluate them they made it down that far yesterday and um and they have an open and um well they have an open question as they'd like to understand um how the projects align and if they should come together or if they should be apart and how do they align and um and so we won't really make it very far in this discussion today but I want to bring that up as consideration fodder for consideration for all of you potentially next time we meet like or maybe in advance of that is to send out some thoughts on what that might look like um one way or the next but to help each of you independently um contemplate that um to lead the question a little bit or I'll say that um that I think all of the above so they want the projects in the CNCF um and then the question is just you know how do these line marry up and and how complimentary and are overlapping are they and and from my perspective they are um well completely complimentary that um performance is quite long and deep and wide and if some intel folks were here on the phone or some red hat folks that the maintainers of S&P were on the phone which by the way they need to be consulted in the same promeshory and the the talk with the TOC was sort of giving this guidance and the TOC members were doing quite a lovely job of trying to quickly understand a bunch of projects um don't focus on the space and um are looking to sign network for some of this guidance and so um uh so I want to bring it up today as a food as fodder for consideration um it's I think the myopic perspective or the very quick understanding of what meshery is to the the TOC members that were considering this is that um meshery does two things it is the canonical implementation of S&P and that it is the conformance tool for SMI so it's sort of a spec tool and um not realizing that it is a lot bigger than that it it also implements um OM it it also manages web assembly filters it also there's there's a list that doesn't mean that it is inappropriate necessarily to bring them together maybe that's a part of their thinking there's some brainstorming and sort of thinking a lot I mean immediately it strikes me as not not what the projects were designed to do be and do but um the last thought that I'll part with here is that now I I lost my train of thought but but it's a it's a topic to try to consider I'm supportive of of of all of the bubbly I mean um I think S&P is a really great initiative um I think being able to sort of sensibly understand the performance of a system is absolutely essential and then I think with with service mesh complexity like there's there's a heck a lot that can be done by by having a specification which which gives you a common view on that and there is a definite sort of analogy to to the service match matrix capability which exists in SMI um and yeah and of course mastery is a great great tool and a good sort of good reference implementation of SMI as well as a consumer of the specification so yeah the oh I remember what I was going to say part of the the thinking allowed by a couple of few of the TOC members was well and this was really I think I think the like two-thirds of the functionality of mesh area unbeknownst to them even though you know just be just because they're short on time but it was the notion that well hey if we're the CNCF and um we're trying to help you inform the world about what a service mesh is and and what it does like if these projects amalgamated would this be the sanctification by which it's articulate you know articulated that here's all of the meshes here's what it takes to be a mesh here's all their capabilities and whether or not they're in compliance with these specifications and and it was their holes and their like discrepancies or overlaps and underlaps and that type of a thought um but but I'm just trying to convey to the best of my ability sort of the sentiment the thinking allowed that that individuals are doing so so I'll try to try to provide some more context and slides and things as over the next couple of weeks until we we meet to help people consider that um yep mesh re-addresses a space that's well it's about twice as big as SMI sort of SMI S&P another one and another one it's a long roadmap we're being asked to engage with the chaos engineering team and write a white paper on chaos engineering in part because that's part of mesh re's roadmap as well as chaos engineering um mesh re's while it implements SMI it's also had a hard time well I don't know how to like like OSM maybe as an example um desires to imp to bring forth some capabilities that aren't defined by SMI and so um Nick Nick as an example and I have and Michelle have talked about um how to help speed along maybe certain existing specifications or potentially you know propose new ones to expand its scope such that um you know such that these things stay in cohesion you know or like with with respect to mesh re anyway and SMI and that's I am I just want to do sorry I'm just just interrupting you lead just to do a quick um time check there now it is 6 30 but technical issues uh in the in the meaning so if um if anybody wants to to continue the conversation I'm happy to to run along for another another 10 minutes or so but but if folks do have to to drop um then of course we you know we were fully fully understand that there's folks who want to get their their teas so um so I know that I know that some folks might need to go actually since Tsunku came on it it bears repeating for his part but but um anyone else have comments or I I think my just initial take is that it feels like it would be somewhat useful to look at SMP independently of some of the mesh re stuff just because it potentially is like a much broader scope uh and it may be more like I think there may be some stakeholders that could have an interest in the SMP stuff whether that be someone like the open telemetry groups or other stuff like that that may be focused on just that specific part uh without trying to get up to speed on the entirety of like what the measuring project is doing it does feel like it would be helpful to like articulate a case for how these are two different things even though they there was some overlapping scope between them and I think as I originally the both the two the products were submitted to the CNCF as individual items that that's correctly isn't it so measuring was was as an application submitted to the CNCF for inclusion and SMP as a specification in the same way as is SMI yeah I agree sorry got delayed with another office call but yeah I agree with that analysis um I think yeah I mean there's should be a good correlation with work going on in SMI and SMP and um uh in a in a measuring by itself is a separate entity definitely there's a um uh relationship with respect to what we could do together but um the scope itself can be separated out so maybe I'm missing the context so um are there any next steps being discussed here or uh I guess that's that's the next question so should we um I think maybe the best thing to do Lee is cool if you again like I think you did this to me last time so I can kind of get my own back in some ways but like um would you be able to to give a very quick TLDR to the group next time about SMP and measuring and then maybe what we do is we go away for a session we can do some thinking and then we can have a discussion about uh the the call the the action items that we we should take does that does that sound like a sensible cause it does to me it also gives an opportunity to for the other two projects implicated um and I'm glad that Sincu is on because he because he represents one of them um very directly and uh for them to kind of go through the same sort of procedure of presenting SMI and what it's you know so yeah thanks for that Nick that knows okay I have unfortunately to go rather soon nation I don't know what happens as the host is recording leave so I don't want to I think we're good I have a job too so we want we won't have any more notes either so I think that we're at a pretty decent stopping point awesome run out bad jokes so I have to go too I should tell you I'm looking forward to updating you on the multi cluster progress next time uh we we are making progress so um yeah we're looking forward to that come back for more please alrighty awesome thank you very very much see you next see you all next time bye yes bye now