 All right, welcome to the SMI community meeting for community, that's a hard word to say, the SMI community meeting for September 16, 2020. Today, we have a few items to discuss. And then we have a few people who, you know, haven't been in the meeting for a while maybe have things they want to say. So, when we show the floor is open after the few items that we want to discuss. The first one on the list is Michelle was saying we needed at least one more reviewer on the TCP UDP routes additions to traffic specs. Michelle, do you want to do you want to take that tell us what's going on with that. What are you looking for people to tell you about their thoughts on it. Yeah, it's Stephans. I think that was Stephans PR, but it just needs one more review one more LGTM from a maintainer. I didn't see any issues with they look straightforward to me. I think the only thing that you might want to consider is calling out in traffic split that since traffic split supports traffic specs that this would mean that implementations support traffic split via traffic. Oh, God, all these prefixes. traffic is all meaning at this point. Yeah, that we would support to see pure out. Okay, okay, good. Alright, so hopefully get somebody else looking at that real quick, you know, you can get that in, which sounds awesome. Can I, can I say something. Hi. Sorry for not being able to attend the last meeting I was on vacation vacation is great. So there is a comment on the issue. Not being able to one second off. There is a, yeah, there is a comment on So on the pre-quest could be ambiguous between TCP and HTTP routes. So there are some situations where the current proposal doesn't, it doesn't take into account. So let's let's put that on standby and discuss the issue. Okay. Okay, so we think more discussion is needed on the issue specifically. Yes, thank you. Awesome. Alright, what is your comment are you referring to do mind dropping a link. Yep. Great, thank you. Okay. Anything more on this topic before we look at the next topic. Okay. I did mention on slack that he was confused about where to find information about CRDs, because CRD info is under a language specific location that being the go SDK and so I wanted to open it up to the maintainers and have them discuss, should we have a pointer in like the main spec read me saying the CRD info is over here is there a better way to handle that what do people think. It seems very simple to me. It sounds about right so that people don't have to browse the repos to, you know, a repo overview is kind of a nice thing. Yeah, I think that the confusion was because if you don't want to write and go, then you're like, why would I look in the go SDK for something about how Kubernetes CRDs work and so it's kind of a scoping issue of like where we have it conceptually but I also don't think it actually necessarily belongs directly in the spec repo as suggested that's why I was like, I don't know. Yeah, it's like the CRDs get updated when we update like the go SDK. So first like the spec gets updated. So we couldn't like put in the spec document a link to the CRDs because they wouldn't be updated. You know, so like, we just, I think in the read me in where it says SMI documents or something we could maybe like link to the SDK repo CRDs as not like the best way. I mean that's a great place to start I feel like yeah okay if we want to do giant repo reorganization sure but like let's de confuse people to start with so I like that. I guess we don't even like reference the SDK on the read me so that might be a good, good place to start. Yeah. Yeah, I can help or I can, I mean I can, I can add a link that's fine I just didn't want to add links in a way that would confuse people but now that I have general lazy consensus that we want to do that then yeah, let's do it great. So under SMI documents we can put a second for SDK. Thank you. Awesome. Okay, cool. That is a nice action item for me. And we had Lee have some ideas he wanted to talk about with the ongoing work on conformance. Yeah, and actually just to confuse I should have spoke up a little bit earlier on the PR that we were talking about it this is comment is probably not useful but I guess I can is. Okay, so this is going back to for note purposes we're going back up to the traffic spec discussion. Okay, is like we're so. So from my perspective net positive that HTTP TCP UDP and that the support for those explicitly is there. Yeah, as an aside like HTTP sort of runs on top of TCP. And so, like, technically like one is a subset of the next, although probably, and this is why we're saying it's probably not a helpful comment is like, probably doesn't really matter that much. It's probably easier conceptually to, to grok and just sort of see that they're all equal. Sure. I mean, I'm not, I'm not positive I understand what the best thing for us to do is are you saying that we want to make sure to special case HTTP as like a special case of TCP or. Like is there action for us to take in terms of making sure we clarify that. Yeah, or just to throw out that thought that. Yeah one is HTTP is a subset of TCP and as a point of 32nd reflection does, would it be looking forward with that be helpful to us as we potentially identify support for other TCP based other TCP based like in terms of not repeating ourselves. Do we have certain certain based level parameters or metadata around TCP and then as a g RPC and Nats and HTTP is like subsets of, you know, of TCP, or just hey that's fine we'll just there's not much repeating going on we'll just have them all as first class citizens or speak top level. I had me understand that partially for describing reasons but also for like logically reasons, your argument. I think I understand your argument in the sense of that, if the one is the subset of the other, then we can kind of like reuse things. But what I don't really get is that would only be valid in a regime where you have kind of like the semantics would would inherit stuff like, do we actually have that. I don't know that we do. I just a sort of occurred to me that like, oh, if this hasn't been a consideration, maybe it's worth mentioning and I don't really have a strong this isn't necessarily a strong argument, or this is clearly not a strong argument and isn't necessarily a suggestion that we go and define inherent inheritance and the question is a matter question question is, does the way how we specify it allow us to benefit from inheritance. And I think the answer is no. One second. What TCP to HTTP means in our context here is the fact that you specify the port, the list of ports, and those ports apply to the HTTP filter. So we can just add a list of ports to also to the HTTP definition and then there is no relationship to TCP anymore. I understand that the question is still for me, like, how do we how do we express these constraints how do we express that using CDs right. Well, right. So if you look at the way the communities model is, does it allow inheritance. Does it allow to express that because then it would make sense to say like TCP and then you have HTTP and other TCP based protocols that inherit stuff from the base class TCP. I'm pretty sure it is somehow would work for protocol buffers but I'm not sure how to express that in the resource in the communities resource model. You see what I mean chef it's not about the concrete case it's just how do you express that in YAML you could it can be expressed but Michael you know better than I actually for sure. Like whether or not that's an easy expression to realize or manifest inside of a custom resource yeah I don't I don't I could be wrong but I don't think so like anyone correct me I don't think so that that's what I'm like, how would you actually write that right. Okay, so it sounds like that's something we're not going to solve on this call but thank you for bringing it to our attention and we have some notes and then if we can put more of your thoughts on as another comment on that issue that would probably be really useful. I did definitely commenting on 185 as well yeah let's let's continue it there. Good call. Okay, because yeah, is there anything else we need to talk about about that lead before we go back to your actual issue. Nope, yeah thank you for doing it. All right, let's get back to your actual SMI conformance topic. Yeah, which is to say that there's a design spec out there for SMI conformance and we talked about it a couple of kind of gone over it a couple of times. It only had near as I can tell from some of the input from some on this call and some not on this call that the skeleton of the bones of it are decent or no one has said otherwise and and as we've demonstrated and sort of implemented it. It's only, there's some flesh or there's some meat that's left with I gotta choose a different analogy but that is yet to be defined and it's the specific tests. So that there's a few examples of tests to be, you know, conformance tests to be run and what those tests assert must be true in order to, you know, pass or fail. And so this is a call for consideration a call for others to come to express opinion or come to bear or help define what those tests, you know, are would be. There's examples in there so without like it's just to save time and things I think that they're relatively straight straightforward the assertions that are being made. Is there a plan to like implement one, like a test for like one API or the other. Like are you going to start with traffic target just so I can prioritize. And the framework accounts for testing against each of the specs, the examples that have been done thus far, if I recollect it's, I think they're. There might be like a dish or so total a couple a few for traffic access and a few for traffic metrics. And then no particular priority, you know, beyond that. Okay, I think traffic access is the easiest one for me to digest so I can start there. Nice. Thanks yeah that was mostly it is just sort of more with it's time it's right it needs to be beat up and holes poked in it. verified and validated sounds good. Okay, I want to make sure that anybody who didn't add something to the agenda but wants to talk about something gets a chance. And while people are thinking about that. Our next meeting is September 30, and I would love to have somebody volunteer. Who will be able to be here on September 30. I mean I plan to be here but somebody volunteer to do what I just did and somebody volunteer to do what Michael just did. So yeah, I dropped something in the chat or speak up or add your name to the doc whatever makes you the most comfortable. And by that you don't mean that that by Michael what Michael did to derail the conversation and. That's a good point you inscribed just the note just the note taking just the scribing. But if you want to also add insights as Michael did that is fantastic but I don't require that in terms of setting up for not taking. I do have one question. We don't necessarily have to discuss it now but I'd like to raise it. It's again, essentially, do we have anything planned around the upcoming keep calm. North America being beginning November. Do we have anything as a, you know, CNCS project that might be an opportunity to do something. I want to say sandbox projects are automatically given sessions. So, unless somebody submitted something I don't think we have a session. Project office hours last time were a thing and I think we didn't do any so that's a, that's a good note that if we want to think about running some project office hours time concurrent with the upcoming come with America. Those would probably be early to mid day for us and later in the day for you. So, yeah, perhaps. Yeah, I think why don't we make a note. And I'm, I'm saying, you know, make a note but like I could make a note as well but um, yeah, Michael if you want to make a note that what we should do is pick sometimes during coupon with America, that it would be a great, you know, run an open, open drop in office hour of the project office hours that the CNCF, like they publish, at least for the last one so I assume for this one to they publish a list, and people who want to go to a project office hours can like show up and there's usually a couple of maintainers who are taking questions from all comers. And that went pretty well I was in a couple of those for the helm project and, you know, like 30 or so attendees would show up and really want to talk. And then it pick about one specific PR or something is not like that it's more, I really want to understand more about where this is going or where that's going. So, nice. Okay, and we have volunteers for next time, at least we have volunteer from Lee for notes, thank you. And bad jokes too if that's. Oh, those are always a good choice, because strangely enough, whatever I mentioned. All right, whenever I mentioned on slack that this meeting is happening people jump in and look at the notes and they don't all come to the meeting but I think people get interested to get a chance to see what's discussed. So, alright, is there anyone else, especially people who come from time to time or haven't spoken up yet this meeting is there anyone else who has something they want us to know about to talk about. Tell us their thoughts. I do. There's, I need to go, I need to circle back with the conversation that I'd had with privately with engine X of a couple of them as did anyone catch the. I barely caught the announcement, but I've been waiting on it for a couple of months. The engine X has a new service mesh. I hope I'm not breaking like I saw somebody published on DevOps.com. It can't be secret if they put it on a website, right. Yeah. And the API is entirely SMI, like, or like, SMI is the API, you know. And so, but cool, really, you know, really awesome. Also astounding that they were, I think just sort of in general that they were able to do so without asking a question. Or like, you know, it's a either attribute to the docs or it's a tribute to them to like, you know, anyway, anyway, it's an exciting thing for the project I think it's super cool actually. And the SMI conformance, I think helps reinforce that like, hey, or are they or not. Any chance that we can get them to write a blog post like, you know, essentially saying like, look, you folks did such a great job spiking it that we didn't even have to bother you to implement it. I mean, like, seriously, can we get them like, given that you have a channel there. Yeah, I will. There's three things that I'm, I'll be after them or now three things. I'll ask them that directly. Yeah. Lee, do you got a link to that? I just added it to the notes. Okay. Oh, you got it. I got it in the notes and I'm dropping it into the chat for this meeting as well. Thank you for bringing that to our attention. Okay. Thanks, Bridget. Great. Charles, you're unmuting. Does that mean you have something to tell us? I, this makes me smile. I'm sorry that I'm joining, but it's good to see you all. Before I worked at point, I was at engine X. And so I was very close to the first two iterations of their service mesh, which kind of drove me towards this whole space. So that's what they come out with. One of my former mentees was working on it. And so I know that they're using BPF for it. But that's about all I know. So I hope it's not an engine X plus only project. That would be a bummer. But we'll see anyway. Oh, it is. Yeah, no, but it's not, but it's not as a shit. Okay. Yeah, I guess now that it's open, it's fine. It's based on engine X plus that said licensing isn't, it's not that licensing isn't such that you need licensing is different. It's not go by a thousand engine X sidecar service proxy licenses for your thousand service system. Licensing is something else I haven't, they, they, they weren't sure what it was going to be. And so maybe it makes sense. The first iteration was this fabric model that they worked on. I'm sorry if I'm digressing a little bit here from the topic, but this fabric model where it was all a bunch of engine X proxies with really no control plane. So I'm curious to see what the control plan is. Anyway, this is very exciting. I'm happy to see this. Yeah, that's great. So if you know either Lee or Charles or whoever wants to talk to them and find out if they can, you know, look into writing a blog post about their experience of implementing as my that would be fantastic. Because that's the kind of stuff that I feel like in Michelle is raising her hand. So I want to make sure we hear what Michelle has to say, but just to finish up, I'm really happy that people are implementing it. Michelle, what's up. Hey, yeah, I get asked like probably like one or two times a week if we have anything like keali. And so I just want to like shamelessly bother maltron again. If there's anything we can do on SMM metrics, if you want to point us in a direction would be happy to help with that. Well, one of the reasons I'm here Michelle because I'm so interesting in the SMI. The first assessment that I did in SMI six months and something that I learned in my job is things change very rapidly. And I'm really happy for you guys to deliver the open service match. So I'm still kept in track of the SMI progression and trying to sell internally with red hat. But as as it now we have very deep committed with Istio and until something changes is going to be hard sell with the SMI. That's cool. I understand that you have my vote. Awesome. Good to hear. So, John, who's on this call and on the OSM team has been working to implement SMI metrics. And he's done some really good work to extend on boy to give us some custom metrics, and then that allowed us to implement him to implement SMI metrics and I think he's going to give us kind of like a lessons learned next meeting. So maybe that might be relevant to your team in particular. Thanks. Thanks for sharing. Okay, awesome. Do we have anything else we have four minutes and I could give you all four minutes, or we could hear something else exciting going once. And yeah, lucky pointing out that that blog is short of details. You know where a lot of great details would be awesome is on the SMI blog. Just saying. Yeah, I couldn't find anything. Sorry, my camera's not work. I couldn't find anything like it must have been a very soft it looks like somebody was in a meeting and listen to a paid event and wrote a blog based on that blog that you were in there is like, I attended their sprint developer call. So I don't know if anything more public I wouldn't check their website I haven't. Yeah, I don't. This is why I was a little bit hesitant because that didn't really feel like what was supposed to it's not look doesn't look like a song it looks like you know I heard somebody talk about something and I wrote a blog. So it doesn't look like it's official at an engine next level yet I don't know. And they're ready when it is official we would love to hear about it. Yeah, I just wanted to learn, learn more about it but yeah that's Rio did the same thing so Darren shepherd we spoke to him and he said I could implement SMI wholesale without needing to talk to us either. I'm missing a little bit. Hey Lee. Could we like, are we gonna. Is the best place to come back and sync on the conformance stuff at the SMI call next week or next time or is it at the CNCF signal working call like where y'all go into detail about this because I do have some detailed scenarios that like for us to consider. Yeah. There's a signal work called tomorrow. That would be, let's do it like that would be the answer is like there isn't kind of one and but waiting for two weeks probably isn't what I want to do. And yeah, that'd be a great topic there. Awesome. It's almost like we're all running into each other at the hall in the hallway at kube con and coming up with things that we should work on and discuss. All right. Well, I have someone to take notes for next time. I will leave. Yeah, and I will find someone who is not me to be moderator next time. And I look forward to chatting with you all in two weeks or at other things. Thanks for chairing Bridget. Nice to see you all. Bye bye. Bye bye.