 All right. So thanks everyone for joining this SMI community call today September 30, 2020. And let's see I can't see the full participants list but if you are new to the meeting and would like to introduce yourself please go ahead and feel free to do so. Take silences this is in the team for a while right. Okay. Let's not get into the agenda. Oh yeah and before I forget yeah if you are on the call, please go ahead and add yourself to the attendees list so we can just know that you were here. And thanks Lee for taking notes. The toughest job with these meetings. Let's get into it. Okay, so first item on the agenda. This is going to be from Patrice to speak about aligning traffic split with traffic target. Patrice. Yeah. May, may I share my screen. Absolutely. Yeah, go ahead. I will stop sharing. Share this so you can see the issue 190. Yes, great. Yes. And I can. So the, I would say it's, it's two things. One thing was that I wanted to see if we can extend the traffic. The traffic split with a source. But before that's what I realize and maybe this is what I want to discuss first is that the traffic target is referring to services. The traffic plate. No, sorry, the traffic target is referring to service account. The traffic split is referring to services. And the traffic matrix is referring for instance, off pod. And they all do that with with in a different manner. Like, if you look at the traffic target, the way you refers, you refer to, to services via this under this destination and sources, you have this little structure where you provide the kind, the name and the name space. And the specification mentioned that today we support kind as service account, but maybe in the future, we can refer to other object and service account. When you look at traffic split, the only thing you are referring is to service and it goes directly with with this service element that we have here and here. And with the traffic matrix when it refers to a pod, you see that it's also this structure of kind name and name space, but this time under a resource element. So, and here, what I wanted to do is to extend traffic split, but before extending traffic split, I wanted to know if it would be not a good idea to align the way traffic target and traffic split refers to other objects. Question mark. Can you still hear me. Yeah, that was I think everybody thinking trace. Okay. So what is your I will ask a question unless somebody else wants to jump in what is your ideal outcome here, Patrice. Hello, my idea is that I kind of like this this kind of of way to refer to another object where you specify the kind, the name and the name space. Basically, what I would do is to use it for the traffic split in the same way that it's done for the traffic target. And then it, the traffic split will look like something like this. So forget about the source, which is the one I would like to add. If we look at the traffic split today, there is a rule and destination. Yeah, you see here. This one is without any rule unfortunately and destination and instead of having service, and then just the name of the service we can have within the traffic split the destination with the kind service the name with the name of the service and then the name space. And then we would have a traffic split which is aligned with the traffic spec. And so. So why are you referring to splitting traffic across namespaces. Is that the functionality you want to enable splitting traffic. No, no. Here is it's not about functionality. Before talking about functionality. I just want to talk about alignment of the, the structure alignment of the syntax. Yeah, so like, so like truck target has source destination rules. And so you're kind of like looking at maybe having the same pattern in split for it to be like more intuitive. Is that correct. Yes, that's that's also one of my goal. But before that, the very first thing is to have this kind name, kind name namespace structure. Instead of just service. Oh, I see, I see. Oh, that's interesting. Okay, got it. Um, Sorry, it doesn't make sense to me. So traffic between what. No, no, no. Let's not, let's not talk about what traffic split in doing and traffic is. So let's not talk about functionality at all. Let's just talk about. I have, I have a resource that refers to another resource. And the, the structure to do that is within the traffic split, you see that traffic split can refer to a service, just by using this simple structure. While the traffic target can refers to service account, but using that structure. Yeah, because the service account. So yeah, but this one here, I can also use it like this one. I mean, I mean, so wait a second, if you, if we allow people to specify namespaces, that means it's across namespaces and in the traffic split specification. We have specified that splitting works in a context of a namespace, not across namespaces. You cannot talk about, okay, let's change some type without referring to how every single implementation shouldn't change it. Because that's a major change you allow splitting across namespaces. Okay, then let me, let me rephrase that's what I would then want is to just to change this service website into this structure and let's forget about namespace, if it's not relevant here. That's kind of nice because then you're like abstracting the like back end kinds. And so we basically say that, you know, back ends are Kubernetes services, but in this manner, it would make the spec a little more flexible. And if like down the line you wanted to support more than just Kubernetes services. Exactly. And that's what has been really nicely put for the traffic target that for the moment the only kind you can put here is service account but maybe later we can have access control based on something else than service account. Yeah, and same thing here for traffic split we would have the ability to and it looks nicer also to be honest to me. And it's like the feet some of the feedback that I've gotten is also like people get confused by like service. Just like this notion of services it could bring any services can it be something else so this make this would make it a little more explicit and and like make it consistent make the pattern consistent across that's that's what I was looking for. And I don't know if Stefan is there, but I also looked at the canary CRD from flagger to have some some inspiration from other CRDs. And they are also using this kind name structure. Yeah, but no namespace. My problem wasn't with specifying like being more verbose and instead of saying service name, saying something like kind service and name. My, my problem was the fact that if we if we allow specifying the namespace then it changes everything in terms of how you actually implemented because then you allow traffic splitting across namespaces which is Okay, so for the traffic splits, let me do it as we speak. You would be so here I have a kind of name, a kind of name. And it's the namespace that I provide at the top, which is relevant for the whole traffic splits. So let's have a quick look. So here is one second if we want to go fully verbose we should also specify the API version, because I don't work for service and service account where they are stable their view on. But for example in flagger I had this problem when I built flagger deployment wasn't on apps V1. Right. And it was important when the deployment was upgraded to V1 flagger to know, okay, now I have to talk to a different API version. And if we are thinking in the future to allow other things besides a Kubernetes service, then those other things should be versioned. So we can have the API version inside the traffic split as an non required field as an optional field, and by default to just assume V1 because service, but when it's not a service then people should also specify the version. You, you put it as required. I'm really glad you are here because I wanted to ask you should we not extend it to API version. I like you did here. And yeah, for me that would be even better. Yeah, I put it required because yeah, migration was was such a pain and I decided, okay, I want the API version every time so I don't have to deal with with API discovery called the discovery pf Kubernetes to get all the versions then to get the prefer version. I mean, trim down the API calls flagger has to do to know what what kind of version has to deal with. Okay, we got Michael see your hand raise you want to chime in on this. Sorry, I think you've been waiting sorry to see you. Yes, I, I had two comments but the one was already addressed. I think the other one, besides also in agreement definitely make things explicit the default so defaulting in general confuses especially newer users. But one thing, if you wish a meta comment is that I don't know if everyone is familiar with how things work in itf, like rough consensus based on an actual implementation, and I'm fully aware of that we, if we look at that as my and everything. We are more from the other side we're more Greenfield implementation following, but as we see more implementations and good folks from from Azure spearheading the way with open service mesh, and others potentially to follow the more I think we should actually be implementation and essentially see what different implementations do and document that and, you know, standardized and document good practices amongst that to ensure interoperability. And I think you also mentioned or will raise another related issue of the trees and I have essentially the same comment in the same direction there right it's like, let's, let's make it more implementation that's the bottom line. Can you say that again. Let's, yeah, I'm not kidding. Let's make it more implementation driven so you just, Stefan just gave a great example right you you gave this background. The reasoning why you made a certain field required, right. There is a certain thing that was not stable at the present time, and in order to force it in order to make it clear to what kind of version you're, you're talking you made it explicit you require the version so that it's explicitly there and And, which means in when when if we do such a thing if we say it has to have this field, and these are the expectations, it is implementation driven right it is driven by the experience could be positive or negative that a certain implementer made in this case you This is for me a good practice we should be doing that, rather than, yeah, I like it like this and you know, bike shedding preferences for whatever reasons implementation whenever we can point at the implementation point of implementation experience. That is to me, the most valuable one. And can I say that my, my input was absolutely not implementation driven, but thanks to Stefan, it has been transformed into implementation driven. Yeah, my, my main concern is, if we make the selector like a full selector where we can say API version kind namespace, then we, we somehow enforce on all the implementers to be able to deal with multi cross namespace split which is something that is not currently implemented by anyone. No, the namespace is gonna. Okay, okay. But that that was my, my initial thought that, hey, we shouldn't we like like Michael said, let's, let's wait for someone that actually has a solution that's cross multiple namespaces and they want to implement SMI and then we can discuss it. We should add it or not, but since there is no one that does that, I don't think we should have it in the, having the kind and the API version feels, feels good to me. And also that something is not implemented. We call it an MSN we call it not dogs not whistling or dogs not parking. But it's also signal right it says, maybe it's not needed maybe it's something we should review at regular cadence and drop because nobody's implementing it. This is also a very strong signal in itself. When you say when you say implemented because that that will be my second request that here I have added this the source which is not in the traffic split. And in terms of implementation of course there is not an implementation that supports that as the DSMI. But if I have an implementation which is supporting the functionality but without the SMI interface, will that count for you sources is a different topic. I don't think, I mean, no other service manager does that you shouldn't be enforcing sources in a traffic split. If you enforce something it should be a firewall rule and that's in our case, traffic target right. Okay, but if I come with an implementation example we can discuss. Okay. Sure, but out of the I like but but not with I like it. Yeah. Okay. What why I would be against specifying sourcing a traffic split is because then you'll be overlapping with traffic target and it doesn't make sense in my mind. Traffic split entire traffic target should work together with traffic split you say I want traffic to be routed to these endpoints and with traffic target, you say, Okay, but this traffic can only come from these sources and have to have this identity and have to match the color identity and so on. Right. It's like, it's like Kubernetes with mixed network policies inside the service definition. I will come with a use case. All right, I want to be mindful of the time here we got a couple of other items but yeah this is this is some good discussion. Okay, but I can to conclude I can come with a pool requests for the API version kind name and namespace if applicable and not with namespace in applicable, not changing any functionality. Yeah, that's a breaking change to the API. So, yeah, we should discuss it. Okay, but I will make it more concrete so we can follow the we can continue the discussion. Thank you. Perfect. If you just want to update your issue there. Be careful. Okay, let's go ahead to the next item here I'll go back and share out my screen. Next we have. I guess we're still talking to you, which we should talk about the back to CRDs should they move to the SMI spec repo. Okay, but maybe we can have this one at the, at the end because I do not want to. Okay, that's fine. Thanks. The next we have Michelle. I'm going to speak out. We make the focus the next week's whole SMI metrics. Yeah, I feel like I'm, I don't know if that's Michael's issue. Sorry if I accidentally jumped to you. But yeah, could we make the focus of next week's meeting SMI metrics. I just would love to have a focus conversation on that. If it's okay because one of our teammates John implemented SMI metrics in OSM and he has like a bunch of lessons learned to share and I think it'd be nice to like, have just a concerted effort but it's going to take like, you know, the whole time so would it be good to have another meeting for that or do we want to take like the next like regular SMI meeting to talk about that. It's okay if we want to just do a separate focus. Are you, are you suggesting like a working group or like what is it more like a task force, like, and I'd love to have dedicated me I'm just trying to understand it's like a one off thing or is it more like. Yeah, just a one off focus conversation around metrics just because like I know, like Stefan and I had a conversation about metrics. I know Linkardy had some issues with right and say some issues with us my implementing SMI metrics, and then we had like hurdles to so be really great for us to have like a more in depth conversation about it. Hi, we can do that in two forms. One option is to have like an hour long or 45 minute long conversation. That's like a separate meeting outside of the regular SMI call or should we replace the stand up with it. I would like if there is a vote or straw straw ball I would definitely go for dedicated additional one hour, because I guess the 30 minutes won't be enough to go in depth and it is really important one so I would certainly volunteer to cover an hour for that if there are others willing to. Cool. Anybody else have some feedback. Yeah I think a dedicated meeting should be fine. I'm going to schedule it for maybe next week same time as stand up. Richard just just suggested the same that we use essentially next next week. They said not normal slot for full hour. That sounds like a really good idea. Oh, thank you. Awesome. All right. Thanks. Next image nine. Please come forward. I would slightly so that's mine. Okay. I would like to prefer to push that back to 14th as well because I was expecting a colleague of mine. It is, I might fall up in between with with our pseudo scribe for today so I'll get back to you Lee and report back. Okay. All right. And now we're going back to trace you want to talk about CRDs and to the SMI spec. Yes, so unfortunately, I was not there last time but I watched the recording. It was quite frustrating to watch the recording and not being able to talk at the same time. The, the CRD I was thinking that that CRD is a good way to convey a spec express as CRDs. So I'm still not understanding why those CRDs are not into the SMI spec repo. I think they just like get automatically generated rights to fun. Yeah, so we should be switching to the controller runtime library. So when we change the API then we change the SDK and part of the SDK release we automatically generate the CRD validation YAML. Yeah, with a GitHub action we can actually copy that the YAML spec that contains all the API validation to the spec repo. It should be fairly, fairly easy. We do that in, in, in the complexity or we copy all the CRD specs from everywhere we transform them in a nice markdown format and then we publish them on our doc site which is yet another repo. So, I already have in place all these GitHub actions and what we need to do is move to control runtime from our current client go SDK. All right, so we need to like would you mind opening an issue on the SDK repo. Okay, cool. And then we'll also need an issue on the SMI spec repo. So Patrice have you already opened that one is that I can, I can do so. But then Stefan if I understand it well because I was not aware of that still new and rules things. Your workflow is that you you make the code and then the CRD is generating out of the code. You do not write the CRD. Yeah. And we avoid several things so in the past we, we, we modified something in the SDK. Let's say we made a few required, but we forgot to do it in the CRD YAML because we, we don't automatically generate it we made it by hand, we made a release then someone noticed and went back to the release and so on. Having this thing automated means that the SDK which comes as as a follow up to the to the spec release, then the SDK will generate the CRD and the CRD will be as as the spec. But it's just that with with my background I was expecting the generation the other way around but I'm learning. What do you mean. I was thinking that you, you set up the standard meaning that you write the CRD and then from the CRD you generate your, your code or at least a skeleton of your code. No, no, no, no, no Kubernetes doesn't work like that. Okay. Everything is go all the other things should be code generated. Okay. Thanks. All right. I think that is everything on the agenda. We got just a minute left. Is there anything anyone else wants to chime in on before we in the meeting. Yeah, so there is a poor request I made a long time ago around modifying the, the routes and traffic target. I don't know why people to comment on it. There are some limitations. Maybe we're okay with it and more GTS it is an iterate over but I don't think the we, we signal the right stuff by having that for months in there. I think we should come to a conclusion. We have the issue that pull request number. Sorry, just want to make sure we had that up. It's, it's about, yeah, we can, we can get that offline. 185. All right, you have two LGTMs, but Patrice has a comment as well. So we can address that. Oh, but I think we need to core maintain our LGTMs right. As I've mentioned, my, my common is something that can come afterwards. I think it's indeed better that you, you merge and then we carry on rather than, than leaving the things open too long. Yeah, that makes sense. Cool. I will hold my comment for a post merge. Sounds good. Yeah, I mean, I feel like it's an advancement of what we currently have. Of course, it has some limitations in a way that you cannot match ports to HTTP routes. If your service has exposes different type of traffic like UDP and TCP, both of them, you cannot create a specific rule for only UDP, and so on. But I feel like this is an extreme edge case. And adding ports instead of just one makes the whole spec way easier to adopt, because right now in the current state, if you have two ports, you have to create two separate traffic target objects instead of having one with an array of ports. I feel that the change, even if it has some limitations, it's better than what we had before. If we, if we merge, if we merge this, I will not make an SMI spec release. I would also rename the traffic target and then do a release, like Michelle proposal to rename it. I think it's, it should, it's a, it's a good proposal to rename traffic target. I think Patrice also volunteered to help us with that too. So you might want to coordinate. All right. Also, I had mentioned, actually, I'm going to continue the traffic access conversation on the issues since we're out of time. Okay. All right, that'll wrap us up. Let's say next meeting. Well, the next community community meeting. That'll happen on the 14th. I think we will have the discussion just next week about the spec for the traffic split. Is that correct? Will someone send out an invite for that? Yes, I'll send out an invite. Yeah, same, same meeting. And we still need a dedicated note taker who is willing to dive in on the 14th. Isn't that Lee? He has to be out that day. Oh, and then then I do the note taking it somewhere else. I don't mind. I can, I can no take for you. Okay. Okay. All right. All right. Thanks everyone. Thanks a lot. It was next week for that spec discussion and the week after on the 14th, the next community call. Thank you. Thank you. Bye bye. Bye.