 Excellent. Hello and welcome to the SMI community meeting. Today is Wednesday, June 24, 2020. And welcome to everybody that's been here. I see a lot of new names today, which is fantastic. My name is Lachlan Evensson. I'll be moderating and Bridget is with me taking notes. Bridget has so kindly put in the link to the agenda and notes in the chat. So welcome everybody. We'll get into it. We have an agenda. We have 30 minutes. So we'd like to drive a very quick, productive meeting. But if there's anything that's coming up, feel free to add it to the agenda as we go. If we don't get it today, don't get to it today. We will endeavor to get to it next time. Okay, so right into it stand up discussion items, website, blog post guidelines, Bridget. Yeah, I was going to mention that because we talked about it last week and I said I would do it and I have not done it, but I also have not forgotten and I will actually do it. So hopefully we'll get our blog post, blog post going. The reason I want to talk about it is because people might have felt discouraged about writing a blog post about the things they're doing in SMI because we haven't published the one that we talked about from solo. That's entirely on me. We will do that. And please think about what blog post you might want to put on the SMI website. That is fantastic. Thank you very much. So yes, if you are working on SMI and you have a great story to share, there is a premises that we just added to SMI dash spec.io for blogs, which is a neutral place under the CNCF where you can put your stories about how you are solving problems with SMI or anything. So and we actually have an entry from solo about some work that they've done. Bridget's adding that. Thank you very much. Next up, we have top level spec update almost ready to go needs one more review. Bridget's name is that it is I added it, but it's not really about me. It's more, I think, Stefan and Thomas might have been talking about it and they are, they don't look to be on the call right now. But if there is somebody who is a spec reviewer who reads these notes later or whatever. Yes. By the way, there's a question in the chat about, can there be a link for the blog? Yes, I will add all of that information to these notes when I stop talking, which I am going to do now. I quickly just grabbed it there. I actually had it up easy to find. Okay, so if you are on PR 169, it looks like there were some changes that Stefan has proposed. Thomas is actually LGT and then we need another round. Michelle had LGT and then but Michelle is out at the moment. So if anybody else is a reviewer on the specification or wants to be a reviewer on the specification, we don't mind if you don't have a binding LGTM, please feel free to review it anyway and add your comments about this. So this is looks like changes to some top level fields in traffic access and splits. So I won't go over that. It looks like it's good to go, but if you want to take a look, please do so. Okay, we have a question from Slack. Time frame for 0.4.0 release of the SMI SDK go. Thomas thought it was possible to do it without further delay. What does Stefan think? I don't know if we have Stefan here. Quick inspection. No, and we do not have Thomas either. Does anybody have anything to say about getting out the latest release of the SDK? Would that help them? Do they need to voice any concerns? Nope. I will go and pull the thread on that with Thomas and Stefan in the CNCF Slack channel for SMI. And if this is your first time as well, there is a SMI channel in the CNCF Slack where all these discussions happen. So you're welcome to join that too. Okay. Next one is a question from Slack. Do traffic specs apply to all back ends? Why are matches for traffic split in traffic split back end and not in traffic split spec? Why is the matches type for traffic split loaded type to local object reference instead of string like it is for traffic target? We have Calia there. Calia on the line. Did you want to speak to that Calia? Yeah, I think now regarding the first question for why it's associated with the back ends, just looking at the example for the YAML for that. I guess it didn't make it obvious that the matches would apply per back end I thought it would apply to both. So I was expecting the matches to be in the traffic splits back itself and not inside each back end object. And then on top of that, yeah, I'm just wondering why there's this type discrepancy. Okay. Can you can you provide some links on exactly where the documentation is not concise? Because I would like to raise an issue there or you can raise an issue. Thank you so much about Calia for putting that detailed info in Slack. And if it isn't already an issue, it would be awesome if it could be just so that that way we don't lose it in Slack. Yeah. Okay, there's the traffic split, like the API. Yep. And then we can compare it to traffic target. Okay. And was the documentation as well? Yeah. And then this is the documentation. Looking at multiple windows. Okay. Yeah. Excellent. Yeah, I know I'm the attendees list. Excellent. Thank you so much. I think, you know, does anybody have any did they want to comment on this now? I know Stefan probably will want to comment. So I think capturing this in an issue with the detail you've provided. And then in the SMI channel in the CNTF Slack, let's go and ask Thomas and and Stefan and then I could probably do some work to make the documentation a little clearer. So are you hoping for making the documentation clear and then or just some background as to why this has been done? I think Michelle would probably offer this up as well. Yeah, probably. Oh, Michelle was also kind. Well, I don't think Michelle knew either. But yeah, looking for background and then perhaps updating the documentation. Okay, it's fine that the types are different. I think it just makes it harder because then we have to reuse code paths pop probably or like I would expect consistency. So I don't know if they're trying to update traffic target eventually. There are lots of questions. So Yes. Well, thank you for taking a look and keep bringing those questions because we want to make sure their answer because if you're coming across this, I'm sure other people will find it too. So let's make it clear. An issue and tags to fun. Yep, create an issue. You can send it to me in the Slack and then I'll kind of fan it out to whoever or you can just tag Stefan, Michelle and Thomas or anybody else who would like to pick it up to feel free to comment on that. Okay, thanks. I know we've done some strange type changes across API versions, which had caught us up in the past, but I think if the APIs haven't changed, it may just be an oversight and we might need to rev them so we don't have typing clashes because that does cause a pain when you're implementing it. Okay. Extremely valid. Thank you so much for raising that Kalia. Anybody else want to weigh in here? Okay, that is it for written agenda. I'll open the floor up to any comments, questions or other discussion. Do we have anything planned for the upcoming KubeCon mid August? Is there any? I know it's obviously virtual, but there anything community wise? I know there was, I thought Michelle might be submitting a proposal, but I'm not sure. So I'd ask her on that. I know in previous, we had planned to do a face to face. I don't know if we pegged out because I think anything in Sandbox needs to apply for a session. Now it's not. Yeah, I think Sandbox doesn't get a session right off the bat. Right, you have to ask. So I would, you know, put an item here. I'll ask Michelle if there was anything submitted. I did not submit anything. Do you have any other ideas on top of that, Michael? Because I know that you've come up with a bunch in the past. Well, it would be good on the one hand to kind of like give a little bit of a status like where we are and what's the current thinking, direction, whatever. And potentially, you know, there might be others out there who might want to start contribute or have something pretty much about awareness and kind of like showing where we are and what we plan. So I mean, as I said, it's given it's not a physical event. It's a little bit hard. You know, otherwise, you could just say, you know, let's have lunch together or whatever and hang out. But are they doing a project pavilion sort of thing at all? For virtual, for like projects? Well, I don't know if you remember the virtual booth or whatever. Yeah, I know Karen is looking at that for helm. So I'll find out about the virtual pavilion thing, which is some kind of premises where you can put things. I think the other avenue outside of that event is we did do an SMI CNCF webinar, probably about two months ago, that Bridget moderated with Thomas, myself and Stefan. And then even at the camp cloud native yesterday, there was a fireside chat with Bridget and Lee Calcote with the new stack. So I encourage you to also think we're trying to do those kind of outreach things in between cubecon events as well. So if you have other events or you think we should do a webinar and you want to be part of that webinar, Michael, we there are the outlets as well. But I'll find out about the project provision. I can also ping the CNCF and say, is there any room to do an update? Because we could see if their schedule has room, I'm not sure. So how about we ask that question too? Because I think it's good whether we do a panel, or we do an update, or we do a fixed session, I think that all would be good just for awareness. Yeah, we might have an answer on that by next time. Just because they say might because I've been trying to even just schedule the helm session with the CNCF, and they are maybe still a week or two out from actually telling me when my session is. So it's like there's a lot being rearranged flux. Yeah. And so once they get a lot more of that settled, they might be able to answer questions like, is there room for a sandbox project to talk about things? Okay. Thanks for bringing that up, Michael. Do we have any other liaison? Is there any? Any other questions? Hey, this is Dominic from Cisco. I have a question. Hey, Dominic, go ahead. Hey, thanks. And I was wondering about the scope of SMI and just for a little bit of background. We see a lot of interest lately in multi mesh, multi cluster, or single mesh multi cluster. And I understand that that is currently not in scope of SMI. But as a preparation, I was wondering if SMI may take some into the scope, some more self awareness or clear ability. So for example, to be able to ask the Kubernetes cluster, what service mesh instances are currently installed? Could be multiple instances on one cluster as well. So what instances are currently installed? What services do these instances of service mesh know off? And what workloads back these services? So that we have more of a clear ability. The reason why I'm asking is I was checking out solos service mesh hub. And the service mesh hub actually includes code that parses the available objects, right, and does some quote unquote, like reverse engineering, what services are there. And I figured SMI is the quasi standard or the only standard that tells us currently what the proper service mesh is, maybe and maybe the right place for that. Like, I know solo is working on a blog post for at the SMI website about service mesh hub. So I don't know if we'll get more detail there, but there will be a blog post about that soon. Lucky. Yeah, I think I think the scope of SMI can change. So you have that flexibility. I think, you know, when when we initially opened it up, it was to create a common abstraction that provided the value of all service meshes so that you didn't need to be fixated on the implementation and create and hence have an ecosystem of implementations. I would like to add a couple of things. We've had conversations, Edith Levine, who's from the CEO of solo has been part of the conversations. She had a conversation about potentially with me, you know, talk bringing those APIs into SMI. So there hasn't been a formal proposal. I've also seen similar APIs in link ID. They have a multi multi cluster set of APIs which can stat at the moment, which clusters are connected and wire them together. I think the most pertinent things that I'm seeing and this is just my opinion. Obviously this is a community. We can we can bring this up together. Multi cluster, circuit breaker, and rate limiting are the biggest glaring things that are missing from SMI in my opinion that almost all service meshes implement in some form or another. So if you have something, Dominic, that you want to propose, you mentioned solos. We can go back and talk to solo. We can invite Edith here to have that conversation. I think she would be willing to see, you know, if there is value, actually having that spec go upstream. I think for the first, you know, first initial specs that landed in SMI, there wasn't anything. Now we're seeing a lot more tooling in the ecosystem. And if we want to extract those APIs from tools and have them in the spec, I'd be willing to do that. And I don't mind if it's app mesh that brings us that from AWS. I don't mind. I'd be willing to consider those things. And we should be making sure that SMI covers the largest amount of use cases that we think are important for service mesh users. So that's kind of the high level view. As for action items, I could go back and ping Edith on the CNCF and say, hey, there's been questions about whether we could look at multi cluster interfaces and somebody suggested solos service mesh hub. One looks like a good place to start. Would you be interested in having that conversation of either donation or understanding it more? And then we can talk about that. So if you don't mind for me to chime in real quick, I just want to emphasize, I think that the multi multi cluster multi cluster multi mesh, I would think is already step two. Step one, that is what I was currently interested in is the more the self awareness of SMI when it comes to only one mesh instance. So for example, service mesh hub currently parses the deployments and looks for a deployment that has a container and is there the string link at D in that container or is still D in that container and then concludes that this is an instance of an Istio mesh or an instance of a link at D mesh. And I was curious if we should extend SMI with objects that tell us that here is an instance of a link at D mesh on this cluster and here is an instance of an Istio D mesh on this cluster. Basically as a prerequisite or step one to multi clustering, but not jumping to multi cluster right away because that opens up many, many additional questions. And can I can I tag onto the back of that? What would you do by knowing that or what what is your intent to do with that information? Then that comes then to step number two that enables step number two for multi mesh because if you have a if you have an uber control plane similar to service mesh hub, that control plane needs that information. And currently service mesh hub reaches into the implementation of Istio and reaches into the implementation of link at D. But I was thinking if there is a common abstraction on an SMI level then it is of course easier to reach into the spec than instead of into the implementation. I mean this is a great amount of detail Dominic. I think what I would propose is would you be interested in flagging a proposal issue? So at least we can shop that around to the link at D folks, the console folks, we have AWS folks here. They might be looking to solve the same thing. At least then we can have a started discussion and bring that to bear. I don't think it's like a high level. I see value in that. I don't see why SMI couldn't take that. It's not my complete decision. Everybody needs to decide that. But I think it's not it's not a bad idea. And I'd be willing to create the processor at least have people propose new APIs that provide value. Because at the moment we're iterating on the ones that are already there. But what we're losing is context of new awareness or new features that people actually need in service meshes. And we want to make sure that they're represented in SMI. So would you be interested in jotting down just a narrative form like you've given us? What you want to know why this is important or have you already done it? Absolutely. Absolutely. Yeah, I have one issue on the SMI spec GitHub repo. It's number 170 and a little bit back and forth with Thomas G. Yeah, if you wanted to chime in would be great. I'd be interested if the community as a whole is interested to make those service meshes more self-aware, so to say. For my part, I think this as a spec like having the ability to identify which type of mesh it is that you're interfacing with can make a lot of sense. The implementation of that discovery and that synchronization that's probably beyond the scope of a spec itself. Like the implementation that you're speaking of, Dominic and searching for the container image name inside of service mesh hub is one way to go about that. It is helpful to be a bit more self-aware, being self-aware than enables some of the other use cases that you're describing. Some of which are covered in some related projects that we've spoken about on this call in the past about homeo genius multi cluster and then heterogeneous multi cluster as well. As a on a related topic since we're talking about service mesh hub as much as we are, I'll mention that there's a similar there's another management plane project called Meshary it the community is actively working on enhancing what's referred to as mesh sync, which Dominic is precisely what you're referring to in terms of being continually in sync with the notion that there are one or any number of the same type or different type of service meshes in the environment. And so it might be a point of interest for you. I agree with what Lee said, getting the spec up there and leaving the implementations to decide how they want to fulfill the contract point of that spec, but having a spec that allows interoperability or a tool chain ecosystem based tool chain to hook into that. Much as we've seen with Flagger hook into all the service messes via SMI to do its rollouts. If I'm glad that there are there are some several instances of this converging out there. So it might be time to have that conversation because I've seen a simple similar thing from Linkedee. So yeah, and I'm not sure if Istio has something similar to do you know mesh discovery, but I think having people from all those communities actually come and say here is what the spec should look like. We probably have enough to go off already in what Meshary's done and what Solo's done and what Linkedee's done to converge on something. I think at this point you lead with implementation and then extract specification out of implementation rather than deliberate on something that's never been used before. We're at that point of it now. So if it's valuable to everyone let's just extract where it's implemented and figure out what the spec needs to look like from that. Two minutes left. Anything else? Two minutes left. There's something for me and that is that just we've I mentioned we've talked about the SMI conformance tooling. Well for a long time actually the project is finally in-flight. The design specs of I think we mentioned maybe a month or more ago kind of the call for review of the specs. I'm trying to find where we have the meeting minutes. Yeah, at the bottom of the meeting minutes are right next to where Bridget is typing is a link to this back if you're interested in reviewing kind of the approach to being taken in that project. And what am I trying to say that we're probably on schedule for about a month out maybe from being able to have repeatable tooling where you can define assertions on what conformance of each of the four specs is and then a repeatable kind of tooling to run those tests. What's that I call for feedback? So you're asking us to. Yeah, there has been previously but there's feedback is most welcome now as well. Excellent. That's great. I'm great to hear that. I will take a look. Thank you, Lee. All right, we are at time. Anything we made it through the agenda? Please add any items for the next call in two weeks time from today and feel free to add them or carve out some space in the note stock to add them. Thank you very much to Bridget for taking notes. I would like to ask if anybody would like to moderate the next one before you all leave. Any hands? Thanks, Maria. Thanks for joining. As usually, if there are no other volunteers, happy to. You know, I was coming for you, Michael, if Locky had a job to do. You were like, oh, Locky should have. That's why she didn't try to talk me into it. All right. Thank you. Have a good one. Thanks. Thank you. Have a great day. Thanks for joining.