 All right, welcome everyone to the SMI community meeting. Today is April 29th and welcome everyone. Thanks a lot for joining. If you have not done yet, please go to the Google Docs here in the chat and add yourself to the meeting attendee list. And with that, we directly jump into that. First up is Michelle. You suggested to talk, give a little bit of time regarding the last week's or last time's service mash-up demo. Right? Yeah, I just wanted to give folks a chance to ask questions. So for full transparency, like the solo folks with service mash-up have some APIs that look a lot like SMI APIs, but they're also very different. So I just wanted to, I had asked for them to give us a demo last week because I wanted to kind of see, since solo is part of our community, see what they're thinking, where they're at with this stuff. And I think the demo is very informative. And then I kind of want to, after we answer any questions, kind of talk about whether we want to collaborate as a community, these APIs kind of overlap with SMI. So I just want to make sure there's not fragmentation if there's a potential for collaborating, we should. And if there's not, that's okay too. It's not a big deal, but yeah. So are we okay to answer some questions or ask just anybody have questions they want to ask? Thomas, did you have something from last week? I probably would have if I had had coffee at this morning. That's my story and I'm sticking to it. I love that. Okay. Maybe we can just post a recording and like ask some questions. Does anybody else have anything? I do see Edith on the call if we want to have her say anything because she was here for the presentation last week and getting part of it. Yeah, me and Christian is here. I mean, if you have any questions, we'd love to answer. So I have a question. Like for access control, we've been thinking a lot more about or discussing a lot about identity and how do I identify what workload I want to grant access to or between workloads access between English. But like some things we've been thinking about. I know that in the service mesh hub world, there is, you know, you tackled access control when you have an access control policy API. So I just wanted to understand two things. One, how do you do per route access control in that API? And two, have y'all thought about how to extend that beyond just Kubernetes and how do you do that in a world where you have like hybrid situation, say VMs or something else? I can take the second question and I will let Christian to answer the first one. In terms of the multi workload type word, to be honest, this is an API, right? So the question is, is this API's owner that? Is there something in this API that will prevent you of using it if you want to extend that? And in my opinion, the answer is no. So now the question is implementation details, right? I mean, how do you do this in this world? And that's a different question, right? I mean, we can talk about it, but it's totally different. The question is as a spec, what we need in my opinion to figure it out if we will want to use it. Because again, this is, as I said, my point is that this is an implementation details. It's not related to the API whatsoever. Because the question is the API's owner, if something like that will happen. When the user will want to do, take two meshes, whatever from VM and serverless and cluster and join them together as one, can they do it? Yes, can they will be able to then route or do an access control? And in my opinion, those API is owner of that. Now, how to do this, this is implementation. Then we can work on them too. Talk to them about them too, but it's different. Yeah, so let me clarify the question a little bit. I think in the API, it really like, we heavily rely on selectors. Like, and so there's an example that says there's, I don't know if it was on the source or destination, but you can have a namespace selector. So that's a very Kubernetes-specific concept. So I can explain what we're doing. That's actually really, really important question. Okay, so all our job is to abstract, right? But what I want to abstract, not stuff that I discover. What I want to abstract is stuff that the user is writing with me, right? So if he's writing a whatever traffic shifting model, that I want to abstract for any measures. But if I'm the user there right now, just push something to a deployment, right? And just for COVID, I wanted to use right now some label to choose it. In console connect word, it will be tag, I think. In VM, it will be labels in Amazon or whatever. I want to abstract that. That doesn't make sense to abstract that because it's just going to confuse the user. So in my opinion, this selector is just going to be extended to support more types. But I don't think that the user will need to say, I just pushed something, let me go figure out how it's defining in your system. And then let's go figure, you know what I mean? It's just, I think that we actually, making his life is harder. I don't know that we want to abstract that. That's my point. So it is like, yeah, but the selector will be able, you will be able to choose namespace, but you're also going to be able to choose a tag in a console if it makes sense. Okay, gotcha. Okay, yeah, actually, I think so. So let me try to explain that in my own words. If we're writing something or we are reading something, right? They work like something that we are reading, right? So like, you basically have this provider model for the concept of selectors in that different places where your workload runs, has a different concept for selectors or labels, and you plan on supporting that with one selector abstraction. Am I getting that right? I think so, yeah. I mean, and again, this is something that we would love to hear your feedback on it, but we were kind of like debating it, and I felt that if I'm the one who's using, let's say, Ashi, and I'm pushing it, you know, tag behaving differently, they have a different concept than labor and Kubernetes. I mean, I just felt that it wasn't right to kind of like abstract it, and I think that it will confuse the user more than it's actually helped. So we're trying to separate between the read and the write. If this is something that we're reading, you know, we got this feedback on glue. So this is where it's coming from. Well, in glue, we had this concept, we did try to abstract it. We had the concept called upstream. And a lot of our user comments said, I'm using Kubernetes. Why do I need to learn something new called upstream? Why do I need to look for my stuff? I already have service. Why do I need to do this? So right now in glue, we actually support it also that if you're using, basically we extended the sector, right? You can use service. You can use whatever the console like we want to do this and so on. And I think that this is feedback that will go from the community. But again, we can decide if that's what we want to do. That's, it's our decision basically. Yeah. And in this one- Is your question has been answered or? Oh, I have one more. Is that okay? Wait, wait, wait, but Christian didn't answer. So if you have other questions, I think you asked two questions and Christian was to answer the second one. Yeah. And your question was specifically around how it relates to traffic targets in SMI, I think. Yeah. How do you do per route configuration? Well per route configuration, right. So the access control policy, just like our traffic policy has either, you know, you can be very coarse grain in terms of how you specify the rules or it can be very fine grain. So you're selecting a set of identity workloads, workloads that have a certain identity and you're describing to what targets they have access. And if you want to get very, you know, very specific about which specific workload to which specific destination that the API allows that. So I understand the per workload, but I guess for us, we have the H2B route group SPAC which allows that per route granularity. And I just didn't see that in the docs. So maybe this is an offline conversation. Maybe you could point me to an example of that. I see your mouth is moving, but I can't hear you. So no. Sorry, sorry, sorry. We can take it offline. All of the docs, all of the protos for these APIs are documented online. I can, let's take this back on the slack and I can point you to the right direction. That sounds good. And then just to wrap this up, because I know we don't have that much time. I just, like I'm just bringing this up because I think it would be helpful for us to be in a situation where people are trying to solve the same problems, collaborate. So that's why I'm trying to expose this conversation and we should talk more about whether we want to go that route or not in Slack. Thanks. Okay. Thank you. All right. Thanks a lot, Ed and Christian for answering all of that. And if there are more questions, just put them in the Google docs and follow up there. And we're moving on to the next one if you're interested, okay? Like if you want more to talk about, I totally do it offline. Yeah, thank you. And next one is Bridget, right? You're gonna cover the blog post. I just wanted to bring to everyone's attention that we do have an smy-spec.io blog. Michelle and I wrote the very first post which was just, hey, we are a CNCF project now. But there is an issue. There is a link, I put a link in this Zoom chat and there is a link in the meeting notes. If you have opinions about what guidelines should be for community members to write blog posts, we have a proposed blog post and a few other ideas already. Let's get your ideas in there by the end of this week if you care. And whatever opinions we have by the end of this week, we'll run with them and we'll get that proposed blog post from solo out, hopefully. And then hopefully everyone else is too. That's all I have on that. Thanks a lot. And next up we have the spec conversion webhook. I think Lackey put that on and Michelle, do you want to? I don't think he's here, Sam and I. Yeah, I'll cover that one. So there's a few different things related to versions and conversions and all that other stuff. So let me start by the most high level conversation. We've had a lot of confusion around versioning. I think it's because at a high level, SMI doesn't have a specific version, like the whole thing. And then you have different parts of this back, like traffic policy, access control and metrics, which have their own APIs and those have specific versions. So as we've been changing the APIs, we've been changing, sorry, yeah, we've been changing just the API version. We haven't been tagging like the entire spec with a version. And so we changed what happened or what the workflow we decided should be and have been following for a little while now is you change the API, you change this API and the spec and you tag that with like a version. And so that might be V1 Alpha 1, V1 Alpha 2, V1 Alpha 3. And then you go to the SDK and you update the APIs there to actually reflect the whatever version it is. And then we have a release process of like, for the actual SDK. And we do update the SDK version, which consists of different versions of the API. Okay, so like that's a lot of versions. So I think what, is it Adam? Who submitted that question? Do you know Bridget? Yeah, so I think Adam suggested we should start by untangling this mess by putting the different versions of each of the components of the spec into their own directories so that you have like historical context on, you know, like the actual API versions. But I think that also, so there was this conversation in that thread whether we want to use release branches to like identify changes to the like spec. And that's something that we can talk about. Stephon, I know you're on here and you're a proponent of that, so maybe you can discuss that a little bit further. But I would kind of like to understand what that branch name would be like and what that process would look like. I still think there's this higher level issue of there is not a version on the actual spec. So I did put in that issue some prior art, like CNAP does it a certain way, OCI does things a certain way, TUF does things a certain way. So anyways, I just wanted to start that conversation here and see if there was some consensus on it so we can finally get versioning out of the way for like a year. Hey. Okay, so who owns that? The first issue is owned by Adam and Stephon has contributed to it and so has Shashan. Okay. Given that we still have two other topics, I just want to make sure that we are conscious of the time. So what is the outcome? What do you want to get out of like just awareness or do we have a concrete next step? Or what is the... I'd like to hear out, maybe we could spend two minutes just hearing our opinions on the issue and then we can take it back offline to the issue. So Stephon, do you have anything? Yeah, so if we are doing sample releases and we cut the version from master, I'm okay with having a directory per API spec and each version inside that directory. And when we cut a sample release, that's actually a branch, a detached branch. So we can look at that branch and see, okay, I want to use the latest or I'm having this version what API works with each other API. For example, we have HTTP routes and traffic split and you need to use alpha three from one and it's alpha two from the other. So if we can express these things by doing sample releases and having directories, I think that's the easiest approach and... So quick, quick stop all from the people who are on the call. Does anyone object to using sample here? Is there anyone like, it's like, oh, please no, let's not do that. Just to get a feeling. I mean, if not, then we can just probably move to that lazy concerns and say, yeah, unless we hear. Any objections on the issue? It's a little bit hard to use. Like we just need to clarify what it means to use some or like, because I understand how it's done in code but it may mean something slightly different for specs. So there's prior art and we should look at that a little bit. Is there, just to speed the conversation up, is there any reason we couldn't just do a PR that's got what the suggestion is and then review the PR and merge like, I trust Stefan and Michelle and everyone like, pick what you think is the right version strategy and let's just stop talking about it and merge the sucker. Yeah, sounds good, that's fine. So I already did that for the SDK. In the SDK right now, in each API spec has all the version inside because without it, you cannot just upgrade from one another. So we already did that in the SDK. We could go with the directory approach for the spec as well and synchronize the two. The problem I'm seeing right now with the conversion hook is the fact that except for the traffic split, all our other APIs, the specification is not Kubernetes compatible. We don't use the spec object as the top level. So we cannot do conversions. So first we have to do a breaking change at the spec top level to every single custom resource we have in there, modify the spec, tell everybody, hey, I'm sorry, we did the mistake at the beginning. We have a top level specs in some case, which is like, yeah, so we should normalize things and yeah, cut the release with a proper API that's compatible with how Kubernetes does it. I mean, the object interface in Kubernetes specifies that you have to have a top level spec and we don't have that except for the traffic split. That's a really good point. Okay, any more comments on that or can we use essentially GitHub and the power of GitHub to continue that discussion in code or the spec? Going once, going twice. Okay, let's move on to the UDP spec, Manuel. Can you give us a little bit of a background? Yeah, the background of that is that we're on Mesh, that we are now, that we implemented UDP support or are in the process of implementing UDP support and then in recent refactoring, we kind of went to like a feature like approach so you can now enable ACL or not in particular on our Mesh. And as ACL enabled means that actually everything that is not explicitly enabled is like disabled and there is no UDP spec as of now. So we couldn't enable any UDP traffic because like there is no way to enable it. So I kind of wanted to start the discussion on how the UDP spec could look like as a first draft and Thomas helped me on that one is that I basically just took the TCP because it's just raw traffic and took it for UDP. So now the question for me is rather, well, is there anything missing? Is there something like, well, what does it take to move that on, let's say? In general, given that we have GitHub and you can actually request someone to review that, I would really strongly encourage everyone to actually use GitHub in the way it is meant to be. So if you put something in, I mean, it's always good for awareness or if there is some architectural background that needs to be discussed to put that on the document. But if it's simply like, hey, I put that in there, can someone review that? I would say that just request, I don't know, two or three reviews. And then if there is like, you feel like it's blocked, no one is taking it up or it takes weeks until someone does it, then it makes sense to escalate that to the group and say, hey, well, do we need a different approach there or whatever? But is there anything contentious, is there anyone? Sorry, so a pull request on the SMI spec requests everyone to review it. This is done through GitHub. So you don't have to ask it because GitHub would send you a notification, hey, you need to review that. Why I didn't want to review it is the fact that if I'm looking at this definition like the same thing with the TCP route, it has no spec in it. It's just a method of the M&A. There's not even a Kubernetes object, right? So how is that a spec? If it has no spec in the site. Also, that is a valid comment on the pull request, right? We got the TCP specification in there that has no spec. So we need to figure out the TCP first, which is already in there with no spec. What are we going to do with that? What's the actual specification? Then we can go back and update the UDP spec to match the TCP spec and module. Does it make sense? Works for me. Right. What do you think? Let's do it. We need to talk about that and we should have an issue for the TCP spec and updating that piece. Absolutely. Stefan, can you create an issue and link it to that PR that we have to keep it on track? Yeah. I'll create an issue for the TCP one and I will refer the pull request for the UDP one to specify that it's on hold till we solve the TCP. Shouldn't be hard to just define something in the spec that type TCP or something, because this is just an object and we cannot react to it from a controller perspective because it has no spec. So. Sounds good to me. Cool. And we have one more topic on the agenda today and that is support for routes. Richard, you again. It is me again because I was looking at the issues and pull requests and the repos. I was excited to see there were a bunch of pull requests around this topic. And then I realized that only, I think Stefan and maybe one other person had even looked at some of them and I thought, I hate to leave these sitting here developing merge conflicts over time. So, Stefan, do you wanna tell us your thoughts on this since you have the most context probably since you've reviewed some of these route support pull requests, what do you think is the right step forward to get these moved along? As I said, last time I approved it but I'm not going to merge it until Thomas approves it as well because it has like the major impact right now the major, the only implementation of this spec is in linker D and a linker D member made the pull request and approve it but I need another linker D member to get the thumbs up. I also an SEO app on the page. Necessarily a linker D member but Lee, is that something you might want to have a look at or is that something you could manage? Yes, sure. Sorry for volunteering you there but you looked so comfortable. I thought I'm going to put you in an uncomfortable position. And no, the peer pressure was not possible. Yeah, I owe you one. Awesome, thanks a lot. So we have one more review there and then potentially can merge it unless there's something also happy to have a look at that. Cool, we have three minutes left. Any other business? Do we have any demos coming up? Anything you want to see us discussing in two weeks time? Any other maybe from our new members or anything? I'd like to put on the schedule for next week to follow up on the items that we discussed this week so we make sure we close things out. All right, I'll take care of adding a note. Anyone who didn't put their name on the attendance list please go ahead and add yourself. Oh yeah, good. I added a couple of things. Thanks for subscribing. Oh yeah, we also need volunteers for next week. If somebody wants Michael's job or somebody wants my job, go ahead and put a note on the doc or say something in the chat here in the next two minutes. We want to rotate this around. Cool, all right, well, thanks a lot and see you in two weeks time, right? Yeah, all right, let's keep reviewing. Thanks a lot everyone, cheers, bye now. Bye.