Cloud Native Computing Foundation Service Mesh Interface, 30 Sep 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: CNCF Service Mesh Interface 2020-09-30

Description

CNCF Service Mesh Interface 2020-09-30

A

B

A

So thanks everyone for joining this smi community call today september 30th 2020.

A

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.

A

Take silences: this is been the team for a while right.

A

Okay, let's not get into the agenda.

A

um 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.

A

A

And thanks lee for taking notes, that's the toughest job. With these.

A

Meetings and let's get into it, okay, so um first item on the agenda, this is going to be from patrice to speak about aligning traffic split with traffic target patrice. What was yours.

B

uh Yeah, may I share my screen.

A

Absolutely yeah go ahead. I will stop sharing.

B

Okay screen share and then move to this, so you can see the issue 190.

B

That's great yes, and I can so the I would say it's it's two things. One thing was that I I wanted to see if we can extend the uh the traffic, um the traffic split with a source, but before that, what I realized- and maybe this is what I want to to discuss first- is that the traffic target is referring to uh services, the traffic's pla. No sorry, the traffic target is referring to service account.

B

The traffic split is referring to services, and the traffic matrix is referring, for instance, uh off pod, and they all do that with with in a different manner like if you look at the traffic target. The way you refer you refer to to services via this under this destination and sources.

B

You have this little structure where you provide the kind, the name and the namespace, and the specification mentioned that today we support kines service account, but maybe in the future we can refer to other object and service accounts.

B

When you look at traffic split, uh the only thing you are referring is to um service, and it goes directly with with uh this uh service uh element uh that we have here and and here and with the traffic uh matrix when it refers to a pod. You see that it's also this uh structure of kind name and namespace, but this time under a resource element.

B

So and- and here what I wanted to do- is to extend um 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.

B

B

Can you still hear me.

C

Yeah, that was, I think, everybody's thinking. Okay,.

B

C

So what is your? I will ask a question unless somebody else wants to jump in what is your ideal outcome here? Patrice.

B

Hello, my idea is that I I kind of of like this, this kind of um of way to refer to another object where you specify the kind, the name and the namespace.

B

So 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 uh something like like this, so forget about the source, which is the one I would like to add. uh If we look at the traffic split today, there is a rule and a destination uh yeah.

B

You see here uh 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 namespace.

B

And then we would have a traffic split which is aligned with the the traffic spec and also okay.

D

So why are you referring to splitting traffic across any spaces.

C

Is that the functionality you want to enable splitting traffic.

B

Here is it it's not about functionality? Yeah? um I I I before talking about functionality. I just want to talk about alignment of the the structure. Alignment of the syntax.

E

Yeah so like um so like 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.

B

Yes, that's that's also one of my goal, but before that uh the very first thing is to have this kind name kind name, namespace, structure,.

E

B

Instead of just service.

E

Oh, I see I see. Oh that's interesting, okay got it.

D

Sorry, it doesn't make sense to me so.

B

Would you split.

D

Traffic between what no.

B

D

B

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.

B

I have a resource that refers to another resource and the the structure to 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.

D

Yeah, because the service account.

E

B

Yeah, but this one here, I can also use it like this one I mean.

D

That means so wait a second if you, if we allow people to specify name spaces, 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 should change, because that's a major change you allow splitting across namespaces.

B

Okay, then, let me let me rephrase that what I would uh then want is to just to um uh change this service website into this structure and, let's forget about namespace, if it's not relevant here,.

E

And 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 in. If, like down the line, you wanted to um support more than just uh kubernetes services.

B

Exactly and that's what has been really nicely uh put for the traffic target that for the moment, the only kind you can put here, a service account, but maybe later we can have access control based on something else than service account.

E

B

And same thing here for traffic split, we would have the ability to, and it looks nicer also to be honest to me.

E

And it's like the fee, some of the feedback that I've gotten is also like people get confused by like service, um just like this notion of services that it could bring any services can be something else. So this may. This would make it a little more explicit and and like make it consistent, make the pattern consistent across well.

B

That's that's what I was looking for, and I don't know if stefan is is there, but um I I also looked at the uh the canary crd from from flagger to have some some inspiration from other crds and they they. They are also you using this kind name structure.

D

Yep yeah, but no name space. My.

B

D

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 a namespace, then it it changes everything in terms of how you actually implement it, because then you allow traffic splitting across namespaces, which is okay.

B

D

B

Splits, let me do it as we speak. uh You would be so here I have a kind of name, a kind of name.

B

And it's the namespace that I provide at the the top, which is relevant for the the whole uh traffic split. So let's have a quick look so here.

D

Is one second: if we want to go fully verbose, we should also specify the api version, because.

B

D

For service and service account where they are stable, they are v1 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.

D

We can have the api version inside the traffic split as a non-required field as an optional field and by default we'll just assume v1 because service, but when it's not a service, then people should also specify the version.

B

You you put it as required. I am really glad you are here, because I 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.

D

Yeah, I put it required because yeah I 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 uh with api discovery, called the discovery api of kubernetes to get all the versions, then to get the preferred version, I mean trim down the api calls. Flagger has to do to know what what kind of version it has to deal with.

A

Hey we got um mike, I see your hand raised you want to chime in on this.

A

Sorry, I think you've been waiting. Sorry to see you in the.

F

Yes, I I had two comments, but the one was already addressed. I think the other one besides also an agreement, definitely makes things explicit. The defaults are defaulting in general, confuses especially newer users very, very much, um but one thing if you wish a meta comment, is that I don't know if everyone is familiar with how things work in iatf like rough consensus based on on actual implementation, and I'm I'm fully aware of that.

F

We, if we look at smi and everything we are more from the other side, we're more green field implementation following, but uh as we see more implementations and and good folks from from azure spearheading the way with open service mesh and others potentially to follow the more.

F

I think we should actually be implementation driven and essentially um see what different implementations do and document that, and you know, standardize and then document good practices amongst that to to ensure interoperability um and- and I think you you also mentioned- or will raise another uh related issue, patrice and- and I have essentially the same comment in the same direction there right it's like: um let's, let's make it more implementation, that's the bottom line.

D

Can you say that again, let's.

B

Yeah, I'm not getting it.

F

Let's make it more implementation driven, so you you just uh stefan just gave a great example right. You you gave this background, the the reasoning why you made a certain field required right. There is a certain thing that was not stable at the point in time and in order to force it in order to make it clear to what kind of version you are you're talking, you made it explicit.

F

You require the version so that it's explicitly there and there's there's no issue right 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 hugh stefan right. 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.

F

Whenever we can point at an implementation point of implementation experience, that is to me the most valuable one.

B

And, and can I say that my my input was absolutely not implementation driven, but thanks to stefan, it has been transformed into implementation, driven.

D

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's not currently implemented by anyone, hello.

B

The name space is gone now.

D

Okay, okay, but that that was my my initial uh thought that hey we should we like michael said: let's: let's wait for someone that actually has a solution, that's across multiple namespaces and they want to implement smi, and then we can discuss it if we should add it or not. But since there is no.

B

D

That I don't think we should have it in there having the kind and the api version uh feels feels good to me.

F

And, and also that something is not implemented, we call it in amazon, we call it not dogs, not whistling or dogs, not barking. um It's also a signal right, it says. Maybe it's not needed, maybe it's something we should review at regular, cadence and drop, because nobody is implementing it. This is also a very strong signal in itself.

B

But when you say when you say implement it, because that that will be my second request that uh here um I have added this, this source, which is not in the the traffic split and um in terms of implementation of, 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.

D

Sources is a different topic. I don't think I mean no other service mesh. Does that you, you shouldn't, be enforcing sources in a traffic split if you enforce something, it should be a fire or rule, and that's in our case, uh traffic uh target right.

B

Okay, but if I come with an implementation example, we can discuss. That's that's the okay you're, not out of the I like, but but not with. I like it.

D

Yeah and okay, what why I would be against specifying source in a traffic split is because then you'll be overlapping with a traffic target, and it doesn't make sense. In my mind, I mean traffic split. Entire traffic target should work together with traffic speed. You say I want traffic to be routed to these uh 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 caller identity and so on right.

D

It's like it's like kubernetes would mix network policies inside the service definition.

B

I will come with a.

A

B

A

All right, I want to be mindful of the time here we got a couple of other items but yeah. This is. This has been some good discussion.

A

Let's, okay, but.

B

But I can to to conclude: I can um come with uh a pull request for the api version, kind name and namespace, if applicable, and not with namespace in applicable, not changing any functionality.

B

Yeah, that's a breaking.

D

Change to the api so yeah we should discuss it.

B

Okay, but I will make it more concrete, so we can follow. We can continue the discussion.

E

That sounds good. Thank you. Perfect.

A

If you just want to update your your issue there, which is be helpful, okay, let's go ahead to the next item here I'll go back and share out my screen, and next we have.

A

uh I guess we're still talking to you patrice. You want to talk about um the back to crds. Should they move uh to the s my spec repo.

B

Okay, but maybe we can have this one at the uh at the end, because I do not want to.

A

Okay, that's fine thanks! uh Then next we have uh michelle. Do you want to speak about? um Can we make the focus next week's call smi metrics.

E

Yeah, I feel like um I don't know if that's michael's uh issue, sorry, if I accidentally jump to you um but yeah, uh could we make the focus of next week's meeting smi metrics? I just would love to have a focused conversation on that um if it's okay, because one of our teammates john implemented smi metrics um in osm- and he has like a bunch of lessons to learn to share- and I think it'd be nice to like- have just a concerted effort. But it's gonna take like you know the whole time.

E

So would it be good to like have another meeting for that or do we want to take like the next, like regular smi meeting, to talk about that.

E

It's okay: if we want to just do a separate focus, are.

F

You are you suggesting, like a working group or like what is it more like a task force like I mean I'd, love to have a dedicated, I'm just trying to understand it's like a one-off thing, or is it more like.

E

Yeah, just a one-off, uh focused conversation around metrics, just because, like I know like staphon and I had a conversation about metrics, um I know linker d had some issues with ran into some issues with us implementing us my metrics, and then we had some like hurdles too so it'd be really great for us to have like a more in-depth conversation about it. I we can do that in two forms.

E

uh One option is to have like an hour long or 45 minute long conversation, uh that's like a separate meeting outside of the regular asmr call, or should we uh replace the stand up with it.

F

I I would I would like if there is a vote or a straw struggle, I would definitely go for a dedicated additional one hour, because I guess the 30 minutes won't be enough to go in depth and it is really an important one. So I would certainly volunteer to cover an hour for that. If there are others, also willing to.

E

Cool anybody else have some feedback.

D

Yeah, I think a dedicated meeting should be fine.

E

Okay, great I'm just going to schedule it for maybe next week same time as standing yeah.

F

Richard just just suggested the same that we use essentially next next week, not normal slot for full hour. That sounds like a really good idea.

E

Okay, thank you. Awesome.

A

All right, thanks for chilling next uh mh9 any plans for extending please confess.

F

I would slightly so that's mine um and which one is short for.

B

F

um I would slightly prefer to push that back to 14th as well, because uh I was expecting a colleague of mine. uh It is, I might follow up in between with uh with our pseudo.

B

F

For today so I'll get back to you, lee and report back.

A

All right and now we're going back to patrice you want to, you, know, talk about crds, and should they go to the sms spec.

B

um Yes, so, unfortunately I was not there uh last time, but I I watched the recording. It was quite frustrating to watch the recording and not being able to talk at the same time um the the this year. I was thinking um that that crd is a good way to convey um a spec uh express as crds, so I'm I'm still not understanding why those crds are not into the smi spec repo.

E

I think they just like get automatically generated right. Stefan.

D

Yeah, so we 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 and yeah with the github action. We can actually copy that the yaml spec that contains all the api validation to the um spec ripple.

D

Okay, should be fairly fairly easy. We do that in in in the flux, cd org we copy all the crd specs from everywhere. We transform them in a nice markdown uh format, and then we publish them on our dock site, which is yet another repo.

D

So I already have in place all these github actions and what we need to do is move to control runtime from our current uh clango sdk.

E

All right, so we need to like, would you mind, opening an issue on the uh sdk, reba, okay, cool and then we'll also need an issue on the smi spec repo.

E

um So patrice, have you already opened that one is that no.

B

But I I can I can so, but then stephanie if I understand it well, because I was not aware of that still new in all those things, your workflow is that you you make the code and then the crds is generating out of the code. You do not write the crds.

D

Yeah- and we avoid several things so in the past, we we modified something in the sdk. Let's say we made the fill required, but we forgot to do it in the crd ammo, because we we don't automatically generate it. We made it by hand, we made the release, then someone noticed and we went back to the other release and so on. Having this thing, automated means that the sdk, which comes as uh as a follow-up to the to the spec release, then the sdk will generate the cid and the cid as as the spam.

B

But it's just that, with with my background, I was expecting the generation the other way around, but I'm learning.

D

What do you mean.

B

I I was thinking that you, you set up the 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.

D

No, no, no, no, no kubernetes doesn't work like that. The other one.

A

B

D

Go all the other things should be code generated.

B

A

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.

D

Yeah, so there is a poor request. I made long time ago around uh modifying the the routes and traffic target. um I invite people to comment on it.

D

There are some limitations, maybe we are okay with it and more cheat as it is and iterate over, but um I don't think the we we signal the right stuff by having that uh four months in there.

D

I think we should come to a conclusion.

E

Do you have the ish or the pull request? Number sorry. I just want to make sure we had that up.

E

Yes, it's spell uh yeah, we can. We can get that offline.

D

Okay, one eight five.

E

All right, you have two lgtms, but um patrice has a comment as well, so we can address that. Oh, but um I think we need to core maintain our lgtms.

B

Right, as the stefan mentioned, my my command is something that can come afterwards. uh I think it's indeed better. That's that uh you, you merge and, and then we carry on rather than leaving the the things open too long.

E

Yeah, that makes sense cool.

B

I will hold my comment for a post merge.

E

D

Yeah I mean I feel, like it's an advanced one um of what we currently have.

D

Of course, it has some limitations in a way that you cannot match ports to http routes.

D

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 uh and adding ports instead of just one, makes the 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.

D

So I feel that the change, uh even if it has some limitations, it's better that what we had before. um 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 uh initial proposal to rename it. I think it's uh it should it's it's a it's a good proposal to.

E

D

Rename traffic target.

E

I think patrice also volunteered to help us with that too. So you.

C

E

E

All right also, I I had mentioned actually I'm going to continue the traffic access conversation on the issue since we're out of time.

A

Okay, all right that'll wrap us up. uh Let's see next meeting well, the next communion 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.

F

Will someone send out an invite for that? Yes,.

E

I'll send out an invite.

F

Yeah same same.

A

E

And we still need a dedicated note taker who is willing to dive in on the 14th.

F

Isn't that lee.

E

uh He has to be out that day.

F

Oh and then I I do the no taking in someone else, it's also funny.

A

I don't mind I can. I cannot take for you, michael okay,.

A

Okay, all right all right thanks. Everyone thanks.

E

A

That was next week for that spec discussion and uh the week after the 14th for the next community call. Thank you.

C

Thank you. Thank you. Bye.

C