 All right, welcome to our special edition of SMI meeting. This one is the working group on multi-cluster. And if you haven't yet, please add your name to the attendees list. And the last time we had this agreement in principle that we wanna look into that, we wanna work into that direction. And we stopped short before we like really got into the scoping with the main question. Maybe I should add that reference again, just in case you don't know, that's the issue to 12. And obviously for the benefit of everyone else out there, we wanna any kind of discussions or resolutions agreement, we should also document that issue so that everyone who is watching on that issue, not looking at our Google Apps here, sees where we are. So any question to what we discussed last time, April 7th? Is anyone who has not been in previous call, any questions where we are with this multi-cluster? I'm just catching up with the notes from last meeting. Cool, if you look at April 7th, you should see where we were. So in general consensus, yes, we wanna do that. And today's coping, I think, depending on how far we get, we might be able to do more also, what are the implications in terms of the charter, there might be some housekeeping or whatever to do with CNCF regarding the SMI charter, and then how we proceed in terms of timeline, what do we need to draft, the policy of the POC, et cetera. Yeah, any questions so far? I think that seems great. Let's jump in right away to scoping. What is in scope? That's a really good question. So if you look at the issue 212, it offers a number of opportunities or possibilities, options, and at least from my or with my AWS head on our point of view, it would be really great to support what Nick called heterogeneous workloads or what I just called cross-computed. So think of, you have a monolith running on a virtual machine, you have some functions, you have some managed or not so managed communities, and ideally in either work, we would be able to mesh across these different compute environments. That's at least our point of view. Yeah, thoughts, do other people have other, like I would specifically be interested in if anyone says like no, we should focus only on communities, we should address anything outside of communities. That is I think the core of this discussion. I'm definitely in favor of having it be sort of extensible to non-competitive environments because I think that's also like the use because I'm coming from. So that's my personal interest there. I definitely agree with Astra. In fact, I think it was about a year ago, I opened up a kind of a proposal PR against SMI and Thomas Rampelberg and I kept going back and forth discussing various options to bring in heterogeneous payloads super interested in that as well. Can you share that? That sounds awesome. I am not aware of that too. Yeah, let me pull it up. I've been thinking about it. It's now a closed PR authored by another version of me. It's actually a PR is 67, June 10th, 2020. And I will share it in a second. Now whether PR is the right form to have this kind of a discussion is a separate story but it kind of has a few proposals. Myself, Lockie, Thomas Rampelberg kind of discussing and going back and forth on various options. There's some context there. Well, that's awesome. Thank you very much. That's super helpful. And I think, yeah, the right way to go about this, I think first to have the discussion in terms of scoping and everything. Otherwise, it's a little bit like, here's a PR. Please merge by maybe not doing all we want to do. And to be clear, the PR is just kind of a demo kind of a thought around changes of existing YAML shapes. So. Cool, appreciate it. Any other inputs, statements, positions, thoughts, the scoping issue? And it's interesting, I should comment because we're talking about multicluster and it almost sounds like heterogeneous payloads is slightly orthogonal. And I know we talked about that last time but then if you think really deeply while multicluster perhaps on the one end of the spectrum, it seems like heterogeneous payload is something very different than multicluster. Yet, it might be the exact same thing. So I wonder how folks think about that. Are they the same thing? Are they different? I think they're different. Mostly just because I just want to mess with you. Contrarian, I like it. Yeah. That's how we arrive at truth. Let's make it, yeah, let's make it interesting. I think what you articulated was from my perspective probably spot on that like, yeah, depending upon the angle from which you look at this, like that's an orthogonal but slightly related problem. If you kind of look at it from another angle, it's like, well, we could probably, you know, two birds with one stone kind of a thing and like that it certainly makes it until it's proven that you're gonna have to pick up two stones, maybe we should just pick up one and see if that works. I like it. I hope the stone doesn't become too complex. I also think the same, right? It's different. Your cases. Speaking of, if I may, Sergio does refresh my memory. Does Hamlet account for, so clearly accounts for multicluster on sort of service catalog exchange but heterogeneous workloads? Is that that's accounted for as well in this aspect? Yeah, and that is maybe the reason why Hamlet is more appropriate for heterogeneous workloads rather than for homogeneous workloads, right? Because in Hamlet, the goal was to abstract as much as possible, right? In order to be able to do heterogeneous workloads. But when we go one level down, right? If we double click, let's say we have two platforms, we double click on one of them. For that platform is going to be homogeneous workloads, right? So behind that platform, we may have multiple clusters or single clusters or not even clusters, right? Depending on what the platform is. And for homogeneous platforms, you may want to interchange richer data. Because maybe it is a proprietary platform. And that you may want to do more things than the ones you would do with Hamlet. So I think that objectives may be different. That doesn't mean that Hamlet cannot do multiclustering as well, right? So we have used that internally in VMware to do some POC with multicluster. And the conclusion we reached is that for multicluster, you may want to expose richer endpoints. So you may end up overloading the Hamlet object with a lot of proprietary data as metadata in the protocol, which is still you can do, right? But maybe that's an indication that different kind of object is more appropriate. Cool, thanks for the clarification, it helps a lot. I just realized that I failed to ask new people. So if you're first time on this call or in this working group, please feel free to introduce yourself. I at least don't recognize every name and our face. So you don't have to, but if you want to, first time, if you're the first time around, please do. Sure, I'll go first. My name is Johnson. I just joined the Microsoft Open Service team about two, three weeks ago, three weeks ago, I think. And I'm still learning stuff. And I decided to be more proactive in the SMI project. It's a very noble project, noble goals, trying to unite all of the capabilities of various service meshes that have a standard spec. It's very noble and nice. So yeah, I'm still learning. And hopefully I get to contribute in the future. Awesome. Welcome. Great to meet you. Thanks. You're on mute if you're speaking. You're still on mute, in case I can't hear you. Yeah, we can't hear you, Alan. But I am interested though, Michael, because you put a few other notes about where we take this discussion while Alan sorts out his audio. And I'm curious what you mean by changing the charter. I just looked at like the repo for the spec and it says specification for service meshes that run on Kubernetes. It doesn't say exclusively. So if we were to hedge that, we could just say service meshes, including service meshes that run on Kubernetes. I feel like we haven't, it is definitely, Lee, you're right. It was definitely implied, but like. That's great. I'm not super concerned about feeling limited by what's written in that it already was sort of a. Awesome. I think I can't remember who brought it up. I think it was last time where someone said, we need to look at if our charter actually allows us to do it. And if everyone agrees, fine. I just want to avoid this situation where, at some point in time on TSE level or whatever, someone says like, whoa, what are you folks doing? Like you're not charged to do that, right? So to make sure that we do the homework. If everyone is on the same page saying like, yep, we're absolutely charged to do it, fine. We can cross that off. We can say, yep, the word, you know, SMI says, yeah, we all agree on that we're allowed to do that. Just to make sure that we are in chartered work. Satisfied. Lee, you're unmuting. What are your thoughts there? Yeah, a couple of very positive thoughts actually, that one, when I had asked, so it was Brendan Burns that I'd asked this of a time or two when, you know, a year and a half ago when SMI had come around and I was dismayed by the answer at the time which was like an exclusive focus to Kubernetes. And that's why I'm on this call because I'm a proponent to this discussion. And then I think the other good news to this is that, well, one I would, from my vantage point, I would say that it's that approval from the TOC is not required. And if there's any amount of formality to be done in this regard, that there's a level, there's a step before the TOC, which is SIG network within the CNCF, CNCF SIG network, that this is a forum in which this could be presented and then some amount of rubber stamping can happen. And since I chair that SIG, that's also helpful. I mean, not that it wouldn't be evaluated abstractly and things, but in general, the answer here is that unless there was something really, unless it was like to not work with Kubernetes, like if that was the change of the charter, it would be, I think the sentiment of a few different TOC members would be more like, well, I'm not sure why you're asking it to us, it's like that's more, that's the turf of the project. And so. Awesome. Well, thanks a lot for that. Clearly, that helps definitely. And I don't know unless you feel like we should kind of like escalate that or whatever. I'm perfectly fine with saying like, okay, the SMI members say, yes, we, this is the way how we interpret the charter and we are perfectly fine with, as long as we continue to support communities, obviously that to me, that goes without saying, I think no one suggests to drop that part. It's just really, are we beyond that also allowed to cover other compute environments or whatever? And so it's to me that. I would suggest we have a mechanism for this in that if you wanted to just put a PR or I could make a PR that just changes the language instead of service measures that run on Kubernetes, saying service measures, including those that run on Kubernetes. And then we could get an LGTM from everyone who cares. That sounds awesome. Let's please do that. And also if, I don't know, Lee, if you find it necessary to kind of like surface that towards TUC or like, you know, FYI or whatever. Otherwise we can just, you know, have that PR and see if anyone says, hey, here, major objection. Sounds good to me. Let's do that. Yeah. I think that it is that servicing it within SIG network and to the extent that the TUC liaisons that focus on SIG network, that it's like, to Bridget has like a fair point, which is like, well, technically, technically the language didn't, you know, it doesn't say that it won't work on Mars either. Like, what, you know, what's going on? Like why do we, why is this an issue? Sounds good. Yeah. But I think that doing so, briefly doing so, like actually there's two benefits. One that might be somewhat tangible and it is awareness and solicitation of interest from others. Exactly. Exactly. Exactly. Doesn't cost us anything and it shows the good will that we are not trying to hide anything, right? It's not that we're trying to do something in SIG, but you're spot on, Bridget. We have a process for that and that is PR. And if you kick that off, it would be very clear if there is someone objecting to it or everyone in agreement. Yes, let's do that. Cool. Then we have another 12 minutes if given that we have figured out that part. Again, let's try it. Eln, are you, do you sort out your, your auditions? Are you able to introduce yourself now? Eln, are you able to unmute and say hello? I'm excited. Yes. Now we can hear you. Yeah. I just dropped a message in the chat. I was going to skip. I'm a new member as just like Johnson just joined the open service match team. Yeah. Because I'm a little bit interested in the multi-clustered vertical. So that's why I'm first time joining in the, this meeting and say hi to everyone. Welcome as well. Thank you. Anyone else on the call who is new? Okay. Cool. My name is Sanya. I'm also on the open service match team. I've been here for a bit longer but hadn't made it up to an SMI community call yet. So just wanted to come on here and see what's going on in the community and say hello. That's awesome. That's implicitly almost answering the next question who's going to do the POC for it, right? Kind of like just kidding. Awesome. Anyone else who is new? All right. Well, then let's move on to the next steps in terms of timeline, in terms of, I initially had this in mind where if we have a draft of that and then we have a POC kind of like trying to see how that feels if we implement it or when we implement it. And then obviously the overall timeline, right? Is that something that we want to do within the next couple of weeks? Is that by end of year? Like where are we? Which obviously has to do with, who is volunteering their time to, for different parts for drafting the stuff, the POC, et cetera. Yeah. Any ideas, any volunteers, any suggestions, anything in that direction. Next steps. I'm very happy to work on a POC, but I'm also very happy to not work alone but perhaps collaborate with someone from the community. I have been thinking about multi-cluster obviously for a long time. So one, I wonder if there's a second person that can collaborate on that. So just to be clear, that's great to hear. And just to be clear, I would not necessarily jump directly into a PR, but I would say like really in the way it is kind of common that you have a design document where you talk about, this is the actual scope. This is what we're trying to achieve. Here are some examples of these environments. And then actually fleshing out the design document, that is roughly what I had in mind. Again, this is just a suggestion. I'm not saying that the only way to go about. That matches kind of my thinking as well. In the open service mesh repo, we have one issue which says start a design doc around what multi-cluster may look like. So I would love to kind of leverage that and open it up just broader and then think about what Sergio said, what we've been discussing here kind of, yeah. And I think I'd be happy to work with that as well, if you think it adds value. Absolutely. I think having at least two or three people, like it would be great to have a smaller set of people who actually own that, right? If like 10 people say like, oh, we love to work on it. And then like, no one is responsible, but having like two or three people, maybe two is the right number, to own that design doc, going to say like, this is what we suggest. And everyone else on the call, wider SMI community, obviously putting in requirements, saying like, here we want to be able to do whatever it is you want to do, whatever your environment is. Maybe it's something we haven't been thinking about, right? It might be some Raspberry Pi cluster or whatever. I don't know, right? And to answer Pritchett's question, I'm more than happy to provide feedback, to review and provide feedback. So it's great to see Bill and Sergio to co-own that. And again, this is not, like if someone else wants to try a minute and say, yeah, I'm happy to, for example, there might be some work around compliance, right? For example, just saying or test cases or whatever, right? So there's plenty of work to be done, but having two people to volunteer to say, yep, we want to lead this design document. That's already super awesome. That's much more than I was hoping for today. That's great. And yeah, I'm potentially interested in considering the design doc too. Less likely to focus on early proof of concept code writing stuff, but like design doc, certainly that's like within what I'm anticipating like working on from council's perspective anyway. It's like that's kind of like the stage of the project that we're at. Looking at more of like a longer term, something by end of year proof of concept kind of timeline. But yeah, happy to help like scope out the problem early on for sure. Yeah, I mean, the natural place would I guess be KubeCon North America. If we set ourselves the goal that we can present the PSE or whatever, or how far we get there, then we have something that we can work towards. We can say, okay, we know this is X months and how long will we spend on the design? How long, you know, maybe even already in parallel start with PSE and potentially different other folks who are not on that call today say like, oh yeah, if there's a design document, I'm happy to, you know, do a test implementation against that or PSE against that. Cool. We have some six minutes left. So any comments, anyone else volunteering with something, any thoughts? It sounds like by this working group meeting that happens again in two weeks, we'll have a regular community meeting next week. It sounds like by two weeks from now, it would be nice if during that meeting, Sergio and Delyan want to give us an overview of what they've started sketching out so far. That would be kind of cool. That's an agenda item for two weeks from now. Sounds awesome. Another agenda item that Michelle had wanted to chat about, but we've run out of time in this meeting, but it would be good to start thinking about it for two weeks from now is identity. Oh yeah. Yeah, we should clearly state, I don't have a strong opinion on it, but we should clearly state in the design document, is that in scope or not, right? So like, okay, we want to tackle that. We want to make sure that it's compatible with other already existing approaches. I don't think that we can resolve it within five minutes, but being able in the design document to say, yes, we're going to tackle that, or here's what we think about it or not, that would be super helpful. And I mean, now you have two weeks time for some, I mean, 20 pages would be enough. That's perfectly fine, right? Don't overdo it, right? Yes, professor. I'm just kidding. I think having a kind of like at least some draft outline to see what goes in there would be super useful depending on what time you can afford for the next two weeks. But yeah. Okay, if I start the doc, Sergio, or do you have another preference? Mike, can I start the doc and share with you too? Use to select channel that's transparent, just assume that not everyone who is interested in is necessary on that call or we'll see that recording. So use to selection, use to mailing this thing, like here's what we intend to do. Here is where you should look, et cetera, et cetera, so that everyone asynchronously has a chance to catch up and contribute. I think there is another important point that this, and then we can already see that in the latest issue that we opened, that was the way we kicked off this conversation is which are the use cases we try to accomplish, right? Because there are different people from different companies with different opinions, different backgrounds, right? And I'm sure because of different company strategy and all these different things, there are going to be different ideas, right? So if we can consolidate all that between all of us and enumerate, at least briefly describe in best cases scenario, which are the use cases and differentiate between them. I mean, not saying that we should have this in two weeks time, right? Because that is gonna require discussion as well. But I think that's maybe some direction we can take before we dig any deeper into any of these use cases. That's a great call. I think if you have that as part of that design document where we then kind of a call for action to the wider as my community saying like, hey, we want your input there, either directly right into that Google Docs or let us know and then we can flesh it out. That's absolutely spot on, yes. Yeah. And then get your rubber stamps from the Do you wanna help with that, Lee? Collection of rubber stamps in all colors. All right, we have two minutes left. Any party words? So thanks a lot for that super discussion. It was really very productive. As I said, I didn't expect it to get that far. Thanks a lot both Dylan and Sergio for leading that and Mike for offering your help there. Any other comments, anything from anyone who hasn't spoken up during the call? Did we miss anything? I'm sure we missed them. Anything you want to add? Anya, Asra, Sniha, Elm, Kanya, yeah. Cool. All right. Well, thank you so much for your time and for all the feedback and input. That was really productive. Thanks a lot. Thank you very much. I look forward to it. Thank you. I'll meet you next week. See you next week. See you next week. Bye now. Bye.