Kubernetes SIG Network, 5 Apr 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Network Policy API Bi-Weekly Meeting for 20210405

Description

Network Policy API Bi-Weekly Meeting for 20210405

A

Still new at this okay, hello, everyone, it is april 5th. um You are attending this sig network policy, api meeting. uh This is cncf sponsored meeting, so we are being recorded. So please keep stay nice between everybody and try not to use any curse words and yeah. Let's have a good meeting today. So we'll start by going through some issue triaging.

A

um So, let's see, I think, did that label pr merge yet ricardo or is it gotten any attention.

B

B

Come on jay, don't don't do that with me yeah, so I've sent the link to you on zoom chat and the last yeah. So the last the last issue that we've got it's three days ago and that and that's something about bypassing external firewall ports, aws.

A

That query, for some reason, is broken for me here.

B

Oh open that on yeah on the url.

B

I've seen to you yeah the not the filter. Oh.

A

How do I use zoom here.

B

Or let me send you the the filter yeah, so here we.

B

C

A

Okay, so yeah open three days ago is this the is this at. So this is all sig network um and then you look through the ones that are api or network policy related.

B

This is actually all I'll see, network themes, including q, proxy, but the the last issue that we've got and like it's this one and the other ones. They are outreach, or at least have someone assign it so yeah.

B

So this is the only one that doesn't have anyone assigned because because it doesn't add the the area network policy automatically. So we should. We should go through through the through the issues and and see if there is some okay.

A

Right so looking through the issues here, at least in the last week, they're all assigned, so we don't need to worry about them right. The only ones that seems like it's related to network policy is maybe this one yeah.

B

Okay, but I haven't, I hadn't read this one, it's strange because it it it says actually about hatzener, firewall, ssh blocking parts but cubelet, but I can't see like I have installed some sort of network policy or something like that free switch image. Oh damn microc, do we have anyone like with knowledge, sweet.

A

Whoa seep yeah: I've never heard of any of this voice. Free switch on kubernetes me.

D

Neither is always fun the protocol from hell.

B

D

I developed a sip load balancer a long time ago. That was not fun.

B

Yeah, so I guess I guess this is not related to network policy andrew so because it's like it says about dockercon balls host network tubeled. So I guess we can. We can leave this for sig network triage or maybe we we can take a look out of the out of the media. So I guess we can. We can move forward yeah.

A

Sounds good to me, cool, okay, um that sounds good to me. uh It doesn't look relevant and then I didn't see any other ones so cool. Well, that's a good thing!.

D

I mean, I think you can make it. If someone wants it to be policies, please send the policies like I I put up dddd, not saying what they are and I still can make calls like yeah right.

A

Exactly cool, so, let's keep moving through this. um I uh the two main things on the agenda today. Obviously I keep talking about v2 um and then also on a separate thread. I just wanted to see if there was a another closer scope network policy update, um we can do either or first whoever wants to hop in anyone. Anyone um vinay have you had time to talk to the rest of your team about owning this.

E

Yes, so we I did have, I did start a discussion and there is like a as you know, looking at the large company I'm having some consensus issues. So um there is like that. So just give me like, uh if you can indulge me for like give me a little bit more time. I think I'll try to come back with a more definitive answer, um so there it is. uh I mean, as you know, I don't know.

E

If you guys know this thing or not, but gobind myself and satish uh have been involved on the cluster network policy cnp and maybe so they're saying like well. Can we like look into that first before we jump on the youtube bandwagon? So again, it's all the question of like in the math of resources, how much time we have so in the meantime. Having said that, I don't want to hold people faster if anybody wants to run with it.

E

Please go ahead and do that and I and myself on my team from google, as in when resources get feed up happy to jump on.

A

Okay, yeah no worries at all um totally understand. You guys have a lot on your plate right now. um I think uh if you guys haven't been introduced yet uh andre uh fadet is also on. This call he's another red hatter who is kind of hopping on this effort with me to help out. um So I think we still have some more discussion to do offline, but we definitely might be able to by next week have an idea if we can take a more andre.

F

So we got in someone a new, a new, a new, a new person, that's cool andre yeah, how y'all doing.

G

A

Yeah, so so we might be able to you, know kind of take a more architecting role in this, or even you know, further help divide the work with you. If, if that ends up, you know that you can't quite commit.

E

Absolutely absolutely, and I think yeah yeah- I didn't say that enough. uh If you guys have any ideas andrew just go ahead and start it and we'll be happy to join as in when we get out.

A

Definitely yeah no sounds good to me. I.

F

Appreciate you handing the baton over and being open about that uh renee because a lot of times it's not clear whether somebody's owning something or not. So that's great hi, andrew.

D

I spoke on mute before a long time. Hi yeah hey there. How are you doing? Maybe I should turn off the turn on the camera as well. I'm good.

G

Yeah I figured that was you when I heard you uh talking.

A

Cool, well, that's good to know- and you know um I think too, like this is gonna be a large v2 is gonna. It's gonna be one per one, maybe group owning a document and then pushing everyone to cooperate right. This is not something that's ever gonna get passed or move anywhere without the whole consensus of this group. To the point that we can, you know, produce a document that is then presented to the larger group, but we have a lot of work obviously to do before it can even begin thinking about that um and.

B

And have you seen that we are on the correct timing right folks, because probably closer than cluster scope and network policy is going to to be on on v2 api? Also, there was a discussion lastic network meeting that it cannot be probably inside net networking case io slash v1 alpha 1, because the api is already stable.

A

So you're saying that we would have to build cluster scope network policy in under the network policy umbrella. No.

B

I'm saying that we will have to build, we are, we are starting. We are kicking off a new v2 api for both cluster scope with network policy and network policy video. So it's going to be we. We are probably going to have like a lot of space to work on on on new things.

E

Ricardo, when you say uh version two of cluster scope policy, I don't think we even have a version. One right I mean we're in the process of defining that yeah.

B

This is this is this is the discussion that that that has run on the cigna on last network meeting? I guess tim hawking was going to talk with jordan digit, because there is some.

B

Let me see if I can find it. Gobind was there. I guess he. He also listened about that. But there was some discussion about because, as we we already have networking kxio slash v1.

B

We cannot have a new, a newer kubernetes networking, kubernetes io, slash v1 alpha one again, because the v10 alpha one got already ripped off from the code, so this might get some sort of conflict with with client goal and other parts, but this was like something that even tim didn't know how to answer. So he he was going to ask for jordan. I guess.

E

H

I I think I I joined the temporary um for the sig network meeting last thursday. I still didn't tim say that he already talked to the api machinery guys- and uh I remember his own words- was that they admit this is sort of like a a problem, but they didn't know how to fix it easily something along those lines. So yeah.

B

It was something like that I was like yeah but yeah.

B

A

I mean, I guess, we've already presented once right, cluster scope, network policy to the networking group and they gave a bunch of feedback to you guys um yeah.

H

All of them are sort of like crv, spec related and the semantics related. They didn't really look closely enough to the to the you know, group. Until we opened up the cap officially and they and antonio stepped out and said hey, this is not going to work. You know you can't put a view on alpha one version on the stable um api group. um So that's when we came to to to sort of like figure out. This is a problem.

A

Totally I mean, and regardless of the apis api blockages, though I mean can't, we just do everything with crds.

A

For now and, like you know, I think, once you have a prototype working it'll be people will be more pressured to find a solution to these api problems rather than just say.

F

Yeah like yang, what do you think your andrea right? So if we did a crd with the cnp, you think y'all would adopt that, because then we would at least have one canonical implementation.

F

I mean adopt it as, like. You know, implement help us implement some of it.

H

um I I I'm not too sure about that. The answer to that. I, I feel like uh sure you know and as crd implementation is easy to accomplish, especially in chat, because you know I I I assume the point of uh we bringing cluster network policy to the upstream. Is that um most cni's? I think.

H

As long as the cns supports network policies, I would say most cnns has already got their own customer policy implementations and there are you know, nuanced differences, and the reason why we tried to bring up a cap on upstream is that we wanted to sort of like have a unified thing for every cni to implement no matter which cni they are so having sort of like a crd sort of like uh contradicts to that, because you know, as I said mostly because.

F

You already have a crd yeah, so it doesn't.

H

Really make sense to have another crd and say: okay, we're proposing the crd upstream, then every other cni can say the same thing right like.

A

Let's make our.

H

Cluster policy.

A

Standard so totally, but that crd would be agreed on by this group. Right I mean that's the whole yeah. That's.

F

Actually, a good counterpoint right is that yeah, like you know the step exactly it's that this would be a crd. There was a people at red hat and different companies that actually said yeah. This is valid.

F

A

Just trying to think about how we can get past this kind of roadblock right. So the problem is, we can't add cluster scope, network policy, an unstable feature to a stable channel right, so I mean it's: either you go to a v2 and we kind of roll it out while we're rolling out network policy v2 or there's another hack right. Those are the only ways forward right now and there's no pressure on anyone to really do it unless we put it on the the the thing of the crd.

B

Is that I I agree totally with yang that that we we actually are proposing to the upstream because everybody, otherwise we we we, we could use like the crd, 413 or from signal or from calico, but the crd approach, and this is what they are following with the serv with the gateway api as well, and what they are doing actually is creating a crd, that's under the kubernetes umbrella, but on a different api group, that's called x, kubernetes, dot, io or something like that, so it's founded by the community and then they are going to propose to move that to to inside the api.

B

Let me let me see if I can. I can find and show that to you just to clarify to you because yeah I.

H

I looked at the gateway api once yeah. I know what you're talking about.

A

um Because I know you guys have already done a ton of work on that, so it would be a shame for just to stall out, because we can't get past this um yeah sure.

H

That's a I, I think, that's a really valid point um I'll I'll. Do some research and uh bring it up with the with abc, who is also he's on opportunity leave, so he only joins our thursday meetings for the class. Now policy I'll definitely bring this this up for a discussion on our regular state meetings um and.

I

Sorry, I just wanted to be super clear, like are we talking about network policy v2 here or the cluster scope network policy? Because because I.

H

Know it feels like they're getting mangled the cluster scope policy because golden. If you see the uh recent comments on the on the cap, um there is one point that antonio raised, like the first few comments about. If we, whether we can make you know the cluster network policy, a v1 alpha 1 um into the network policy, dot io, because it's already v1, um so it doesn't- uh doesn't allow us to add a new view enough of one version of crd into the same group.

H

So- and uh this was somewhat confirmed by tim hawking, I think by last thursday, but they didn't provide a sort of like clear solution on how we're going to go uh work around this problem. Yet.

I

I see okay, so we're just thinking whether we need to use the v2 uh nomenclature just so we can actually get the crd upstream or something.

H

Not not exactly, I don't think I don't think this cluster network policy have to be tangled with network policy v2. It's just that we we need to um use another api endpoint, just like what the gateway api is doing, uh rather than try to squeeze it into the existing networking. I o api group that.

I

Makes sense my understanding.

H

A

I

I'm just trying to make sure that we're not like you know, marrying the two fates of like the v2 discussion and the questionnaire policy, because I think we we've already made a ton of progress and we should get that moving as quickly as possible for a cluster. Another policy.

A

Agreed yeah, I I don't think they should be tied together at all. um I just think some things you're going to have to do to get the cluster scope network policy in is going to apply very much to any v2 work. We do moving forward. So it's good to kind of think about both right now.

I

Yeah- and I don't want on that subject- sorry, uh I'm just trying to understand like I'm reading through the notes and stuff as well uh for the v2 conversation, um what what are some of the or maybe this is still working progress. So that's that's totally fine, but I just wanted to understand what are the the main goals of v2 policy? uh What are we trying to solve um and why does that necessitate a v2 necessarily.

A

So I think some of the guiding principles we we started discussing last week, a lot of people weren't here um and there is still not a clear dock that is owned by anyone that is describing everything. That's kind of our first goal is to get a get a doc. Answering all those questions very succinctly right.

A

um The main reason I think we kind of all started agreeing on v2 was you know, the existing implementation doesn't have a lot of flexibility right uh and anyone else can hop in here, but I think there's some features specifically on the docket, such as service selectors um service account selectors.

A

um Those are the two I can think of off my head build.

B

A

Node selectors, right um that you know it was the constant battle for those those features.

A

Do we go back and we try to edit and squeeze in these features to the existing network policy spec or do we you know, look into a v2 and that, along with the fact that there were some grievances against how it works right now, for instance, uh the fact that that all pods can talk to every other pod until any policy applied and then at that point, they're cut off by default, like that implicit behavior should be explicitly defined by a network policy. So that's like a couple of the reasons um so yeah.

A

That's what I think. If anyone else has anything to add there got.

I

B

The full behavior right, the default, the hitting the hitting behavior that jay always.

A

Yeah yeah: that's what I meant to say about that. um That's kind of the things that are pushing us towards a v2. Now you know with the v2 there's also all the complicated things that go with it right, yeah.

I

And that's that's really the conversation that I'm trying to have in my head, uh and you know it's good to have this sort of in the community as well, um because, if like, if there's like, like you, know, major sort of change in direction or some such or like, oh we're doing, I don't know l7 policy, I'm going to throw that grenade in there.

I

So um you know like um maybe then it could be like yeah sure, like you know, let's do a v2 and then there's a significant change in sort of the motivation and the scope of uh of what this api does. But if it's uh you know if it's mostly changing some of the semantics to make it more obvious or what have you uh or adding some convenience selectors um I mean I you know like, for example, customer policy is a huge effort on its own.

I

um You know, we've been working on it for several months um across several different. You know members and um like you could have almost argued that oh cluster network policy almost deserves like or will force number policy into the v2 land and we have to come up with a new api and define a v2 version of it, and even that we were able to sort of like you know, uh sort of you know uh ignore or slash. You know work around.

I

I should say um you know in the the v2 conversation and have it be interoperable. So that's kind of the reason I'm I'm wondering like what is the sort of ground truth and the principle on which we're basing the decision of coming up with the v2 api. And if it's well understood um you know it would be very well like it would be worth our time to like you know, do that before we jump into it.

A

Yeah- and you know we had brought this up a long time ago, and then it came up again two meetings ago, and that was the meeting where I think a lot of us agreed on. You know pushing forward with it. As you can see in the agenda, we were talking about service selectors and then all of a sudden it was like. Well, let's do this. Let's start talking about v2.

I

Let's talk about v2.

A

F

So one thing I I wanted to also just remember this one also andrew, I don't know if I suggest yeah. I think I've suggested it when you're here before, but there is one other thing that for the v2 stuff, which we could do, which I think requires- which I think the cool thing about it is.

F

It requires absolutely no cni knowledge whatsoever, which is we could build a set of common crds which express the v2 semantics but then generate under the hood v1 policies right and then we would prove out a v2 api which worked on any cni provider, and you know I I know matt fenwick has done some of this already right. He's demonstrated that you could do some of this. I.

D

Mean that might work on all understand.

E

It'll be generating like.

F

V1 policies right so matt's done it matt's got this really crazy api that he built. So it's doable right. I'm not saying it's like it's going to work for everything and and gobin's team already has that network policy l7 operator thing too right, so we've got pieces.

A

Yeah I mean we have a egress firewall that can operate on dns names right, but I mean that's kind of the l7 thing, but you know that a bunch of questions arise when you say okay, we can take anyway. I think that's a day, two conversation. We need to unite on the fact like- and I thought we did this two weeks ago, but now I'm hearing a little bit of contention- and you know I've had my own second thoughts again after thinking about it for a while. So.

D

When do you guys say layer, seven, do you mean just the url or are you also looking further into? I mean anytime? You do that in reality, you're looking at the layer 7 proxy right, because you cannot assume that.

H

A

H

A

My mic came my.

H

Understanding is that uh you know goldben and his team has a fqdm policy repo and I don't think it's truly l7. It's just that.

G

E

H

Yeah, I think it's just you know you can specify a fqd and then a policy and under the hood it translates the policy to ip addresses before using.

D

Dns resolution.

H

D

Ip block, then.

F

A

F

Like from an end user perspective, it is an l7 policy now from a implementation, whatever.

D

We could argue about that all day, right.

F

D

It does it updates if dns is updated.

J

A

D

A

J

D

External server then keep track of the that's. A pretty cool service.

I

Correct, oh yeah! Well, yes, thank you! It's actually open source on github and uh it's it's free for all of us to you know, uh add more stuff to it. So, um but yes.

F

I

F

I was just saying we demoed it once and one of the. If you want to see one of the youtube recordings from the last couple of meetings, it was actually yeah kind of cool. Just worked.

I

Yeah yeah, uh but I think I think the the only thing I'm trying to get at is and then obviously a v2 conversation is, is great and welcome. uh I just want to understand you know from my perspective like what what the yeah sort of motivation, the prime motivation for that is and, like you know whether v2 is the only answer because it with with a new api. As I'm sure everybody understands it, comes like the load of educating customers, migration to the new api and interop. With the you know, old api.

I

um You know so on and so forth, and- and I'm just wondering like you know, hopefully the value that we're adding is worth that effort.

A

I mean and you can mitigate all that right by failing, open or failing closed with v2, and we spent a lot of time talking about that last week. Right I mean if you apply a v2 policy to a v1 controller. What happens?

A

Is it going to work? Is it only going to work for some half of the feature set of v2? I mean it's all questions we started to ask last week. I think it boils down to the fact look. We have these new features we want to implement with network policy. We also have some grievances against how network policy is right. Now, what's the way forward, I mean.

F

I think there is no, I think overall, if we're all honest with ourselves, we're at a point where we just can't do certain things without doing all sorts of weird copy paste nonsense with v1 right, like some kind of weird like having a 20, you know meeting debate about adding a single field every time we want to add one because of this closed, open nonsense that you mentioned andrew right, that's kind of where we kind of all just it just the cognitive load at this point to add a new feature without breaking the v1 api is to the point when it's beyond any of our mortal brains, and now it's not that we want a v2 api for no reason.

F

A

And now there's also one other path that I was thinking about that and some people, like dan winship, pointed out to me I mean dan winship is obviously knows a lot about all this and he, you know said to me like the way it is right now makes no sense for some of the default behaviors and, and he doesn't like how network policy is right now and he's his idea was, you know, forget about breaking v1 forget about a relation to v1 v2.

A

His idea was you already have a cluster scope network policy in the works. Why don't you make a new object and call it like an application network policy right? So then you have one that's handled by administrators, more so and then another that's handled by application developers, whereas, like right now, network policy is mainly handled by by both, but application people can still go in and mess stuff up.

D

So I can ask a stupid question, so all this stuff I mean a while ago, so it's about nested namespaces, which will always obviously break complete havoc with all the selectors. So so it's almost pushes in network. I mean nested namespaces right then, anyway, all the policies needs to be redone. So is that ever going to happen necessarily.

A

I haven't heard.

D

About nestedness.

F

That what is the hierarchical name, space, hierarchical yeah? That's.

D

That's that's what I meant, but I mean if that comes in then another sudden you have, even if it's just one level right, the the the whole the whole label mechanism becomes much more complicated and the the policies are the stuff that I see will be hit hardest because your uh your pod definitions and so on, yeah. Well, you do it always from the relative point of the namespace, whereas the policies are so. The application policies could then work within sort of the top name space.

D

But I mean, if you do cluster namespaces cluster rules, you would probably more work on the top between the the different tenants name spaces. So um yeah, that's that's!.

A

A whole, that's I mean that's a good point too right of what, if something else, changes yeah.

D

A

D

So I have no clue I mean I can understand that someone wants it, because you want to be able to your for your customers to not have to care about what they call their name spaces, which is obviously the case now right that they have to be all unique uh and so.

A

On so I would say, nested name spaces, though, are is a feature that is probably less likely to get in oh yeah, then service, selectors,.

D

Yeah so yeah so I mean, but something like that will break the com will break everything that has to do with policies right and that's probably why it never will come in in that case or you would have to have a simple rule to apply them yeah, so it will still work yeah, no totally.

A

um So yeah I mean, I think, the question this group needs to come together on and agree to is: do we want v2? Do we start putting resources into it or is there another way forward?

A

Those the only two options- and I I think you know whether it takes I I'm how long it takes is up to the group, but we need to come together, decide on that and move forward um instead of revisiting it every three weeks and coming up with a different conclusion right.

F

F

So if we were to do a thing where we is the debate, whether or not we should do a v2, is that a debate or is that just a um kind of like a shocking revelation?

F

What I guess govind, I guess you're the one that brought it up so what's what do you want this to be a debate, or do you want it to just be like.

I

You know I I don't want it to be a debate if uh yeah, I think I was just looking for like the main reason or reasons uh as to why v2 is has to be the answer. uh Like literally, that was the only the only question and I didn't see it in the notes. um So that's why I was asking we.

F

Don't take very good notes here, sometimes no yeah.

I

F

Let's do this right, so how about this andrew? We can start a mailing list thread and um literally make this. An actual thing of you know, look we're at the point where to address gobind's question, because it's a good he's bringing up a good point here, which is that we never really.

F

I don't think made this case explicit. We just kind of all agreed that.

A

F

A

I agree, you know: goldman brought up some really great questions.

F

So, okay go ben, we hear you loud and clear and you are very correct. We never actually we just kind of got lazy and decided. We didn't want a 2v1.

I

I mean don't get me wrong. I think that I'm very enthused about the idea of like having an and network security that makes sense.

I

So uh don't get me wrong, I think it's all. It's all good. I just wanted to make sure that we have all the like the principles identified before we. You know jump in. You know head first. That was the only.

F

Yeah, I agree, somebody else would have said it if you hadn't said it first. So I'm glad you were the bad guy to say it because guess what somebody would have said it, and at least we did it within the group first. So now we got to put it in writing no you're totally right. So.

G

Shout out to goldman for.

F

For standing up uh and saying that right, like that's important, to be able to get us out of this thing, so, let's, let's get this done right: okay, cool yeah, yeah,.

A

And I think you know if we can get that written down that'll be crucial because that's been my kind of push for the past last two weeks. Is you know, regardless of what we want to do? Let's get it written down documented so that it's there for anyone to see, and we haven't done a good job of doing that. Yet so cool um and I mean regardless. We need to figure out a way forward for these new features. So.

F

So um how about I start a little google doc and we can work on this asynchronously, add links and evidence as to why we need this v2 um and andrew I'll just share it with you so so and ricardo and whoever else wants to just reach out um and.

D

uh And you can.

F

D

So from from what I understood from you before, right and a large part did not do it in v1, it's the struggle every time you want to change something. So if you would define it fs, it would be a v2. At least you would have all the you would be able to add attributes and all this stuff without much of discussion. And then you can have a discussion at the end, whether you go v2 or not, and if it's not 12, then you know what needs to go into v1.

F

Well, we have historical, we just, I think we have historical stuff. We just need to do the grunt work to dig up the github issues, dig up the meetings. You know what I mean, so we can just put the bullets in a mailing list thread and say a lot of.

A

F

A

F

A

I mean this is like answers a lot of the questions right and this document's from what.

F

All the way from 2016 or something like that yeah, so we.

A

Have this end of this was like yeah, we need a v2 basically but like, uh but then now we've gotten to the point where augmenting v1 also seems equally or more so impossible.

F

Yeah yeah the one of the real interesting things tim said, and I I dug this up in the mailing list once and I got to jump after this, but he said the biggest mistake the network policy api ever made was. I wonder if at some point I'm going to get in trouble for always quoting him, but I like.

A

F

Up his old quotes so but like yeah, he said this and it was like real interesting he's like well. The biggest mistake we made is not writing policies against the service right, not making that a first class principle right. So um yeah we're going to have to write this up. It's going to be a little work. I feel like andrew. Maybe.

D

Sort of services.

F

Services yeah, okay right, um I feel like yeah, let's, okay,.

A

If you can start a doc jay that would be awesome and we'll okay, we need to like everything gobind asked today. We need to have like solidly written down. If someone comes in and says it, it's like.

F

Yeah, because we're gonna, because a lot of people are gonna, say the same thing right, yeah.

G

Can I suggest you just put the link in the minutes here and then anybody can get at it that wants it.

F

Yeah yeah yeah definitely.

D

Yeah, it's not like, like I said I missed a lot. Is there anything in here now about the uh one thing, because.

F

I got a drop andrew. Can you just make sure you write in like bold, like next week justify v2 right? Like that's our thing for next week, we gotta do.

D

Is there anything in here now how to handle side cars and that when people just dump tunnels into the ponds.

F

Somebody asked for that in that link. Andrew has somebody did actually talk about something like that.

D

At least to be able to to serve someone okay, these are the rules you're supposed to follow, so you can have well-behaved side cars, but.

F

Check out this github repo pair, it has everything every idea that anybody has ever proposed um about network policies that we ever had and actually.

D

Has votes for them? People.

F

Voted on them, so yeah all right.

D

I will have a look.

A

Cool great awesome: well, I think that's pretty much all we have um you know and at on the same token, should we set. We don't even need to set a date, but we, I think our goal over until it's done is just to be like firmly all everyone in this meeting all in on v2 or if someone has a better idea to please bring it up like we still want to hear other ideas, but at some point we have to move forward with one one or something else right with v2 or so so it.

D

I would guess that it's a makes a big difference if you're someone, that's providing sort of the technology or if your user of the technology provide you're, probably all for a v2, because it's easy to add in your stuff, if you're a big user, maybe not so much.

A

Right and that that that can also be fixed or or annulled by how we design v2 in the sense that coming backwards compatible right, yeah. So that's open questions that will need to be decided down. The line for sure.

D

Well, at least I know exactly where I am so I'm very much on the provide side. It's.

A

No, it's a good point um cool great! Well, that's all I have does anyone have anything else? Any other questions for today or comments concerns.

D

Like, like, I said before at some point.

A

D

The so the world I live in multi-networking is a fact sort of that. There is many networks, many network attachments, many addresses and is one thing: what happens in the pod right, how you sort it out and there's another thing how the kubernetes framework can handle it, and um I started out believing that it couldn't work together. I changed my mind over the last six months. I think that kubernetes, I call it from the semantics and the bass has really no problems with with multi-networking.

D

Okay there's certain things. That's only provided on the first interfaces, but it wouldn't have to like network policies, there's nothing in the policies that really talks about an interface it does to assist us. This group of pods can or cannot talk with this other set of parts. I mean you have the angus ingress and the egress, and it says nothing about which interface it come out for the for the service is a bit, is sort of that there's so assumption that is at first, but it would be very easy.

D

The same thing say same thing, and I want to have a set of addresses that works on this network that should be able to uh load balance over another set of poor. I mean over another interface or network, so to speak, there's nothing in the semantics of how how things are set up that that stops, that so telcos and all of these that wants to run their 5g stuff, because 5g now is specified that it's going to use containers. So everyone has had their call it infrastructure as a service vnf.

D

So now they're going to move it over to containers first, they think they can just take them around them. That will never work, but I mean, even if you rewrite it, it's going to be multi-network and people are going to have to use vrfs in the containers and so on and sort that out, but what they do in the container doesn't really kubernetes as such. Doesn't care right same thing with the constant network orchestration kubernetes is not set up to handle, it should never do kubernetes. Can you can define a network?

D

You can match it to another network. That's outside of kubernetes system, and then you can make attachments, that's all it should do. If someone wants to do a router, I mean we have it.

D

It should not be some some call it openstack, like interfacing kubernetes will never work because it's in the hand of the call it service provider that provides this to do all this stuff, so it needs to be separated, and this is pushed now in undercut and so on and linux foundation and they try to build reference models and all this sort of, but so that's where I'm back here to sort of try to see.

D

How can we do this, but I do think sort of that it should be possible for someone like me to write network policies that works over multi-networking. It's simple to do. If you do it from the beginning, you think of it, and as long as it doesn't destroy right now, shouldn't say the story. It doesn't change the semantics for someone that doesn't use these things.

D

It shouldn't be a problem and sort of see if, if the kubernetes community is starting to get open to sort of see, that multi-networking is problematic because any multi-homing you never know which interface it goes out. But if someone knows how to handle that at least the framework shouldn't sort of stop it so right now and we have the call it the eth0 network and then we have the cni's only doing all sort of and every cni does it differently and it just doesn't make any sense.

D

We have annotations sitting in the pods, uh that's that's specified by network plumbing groups and multis, and so on, and it's it's there. So I think that same thing when you discuss v2 here, if you're going to discuss v2 for networking at some point, those things should go in there as well, but it should needs to be done in a way. That's not changing the base semantics of kubernetes and if it changes something it should be by extending it for those specific use cases not changing. What's there if it's not needed.

A

No, definitely I mean it's, you make good points um that it's obviously a big, a big, a big problem.

D

Well, you work in a company that also has a lot of telcos as your users right.

A

Yeah yeah for sure see it all the time, but definitely.

D

A

I did just want to before we hop off uh prasad. I just saw your chat um for sure. If you want to give us a do, you want to give us a quick introduction of who you are and why you're interested in joining.

C

This group yeah hi, my name, is prasad. um You know this is first call I'm joining and you know I work at juniper and you know I'm one of the uh current trial. You know initial members, if you know about contrail, and I help in I worked in openstack and those areas so right now, you know we are started looking into kubernetes areas so and I started looking into the network policies and uh you know wanted to help in this area.

C

Cool, great and also nadim also joined along with me. uh You know he's also one of my colleagues there. So we wanted to actively participate and you know start helping. You folks and you know, shape up the things on the network policies area.

A

Definitely well great great to have you hi nice to meet you great to have you both prasad nadim, uh thanks for hopping on so, as you can tell we're in a period of uh you know, a lot of new work coming down the pipe figuring out, how best to implement it. So yeah.

C

Yeah, it's a good.

A

Time to hop on.

C

Thank you, and is there a way you know like? What's the starting point, like you know, I mean I wanted to, uh you know, get onto the notes. Whatever happened earlier, you know maybe just wanted to quickly browse through um you know so that you know we'll get a little more. uh You know clarity on some of the areas which you are talking.

A

Yeah, definitely um our agenda has a lot of stuff. That's going on. um That's probably the best central place for notes. I would say right ricardo. um It should contain most sorry. I was looking to another screen andrew, oh no you're, fine, I was just uh um prasad- was just asking for best ways to kind of read up on what we're doing and where we're getting started- and I just pointed them to the agenda. Yeah.

B

Let me let me hold on so this is the.

D

B

I am bad at computers; they should sell coconuts on them.

B

Okay, so here here it is the the our agenda and everything that we've discussed in the past is already here. But now we are mostly focused on on discussing about the evolution of the the network policy decides with with what we already achieved. So we achieve it.

B

I guess it where some small goals, but really asked by the community about the port ranges and and selecting namespace by name, but now we are moving forward to to actually to extend the network policy api to some more selectors that we cannot do already and we are hitting some problems like fail, open versus fail, close and and and also discussing about the cluster scope of network policy, which yang is much more aware than me and vinai.

B

But there is some documents as well on the header of the of the of the this document, I'm looking at this document and I'm forgetting that I'm not sharing with you, I'm sorry, my screen, but anyway it's on the on the hitter of the document about the cluster scope and natural policy discussion.

B

Some slide that that they made some some old discussion with as well so, and you can feel free to bring me on slack. If you.

C

B

C

Thank you. Thank you, ricardo and thank you andrew, for uh you know giving the uh you know.

D

Are you in the same group suktor.

C

Yeah yeah. Yes, yes,.

A

Cool yeah no worries great to have you on board um great, so I think we have kind of a way forward. um I will keep in contact with jay and post the link to that google doc in the agenda.

A

Hopefully, next week we can come in with some more principles written down to kind of forward us into the next discussion on v2, and you know if anyone has time continue to. I can continue as well to do research on. Are there other ways forward? Besides v2 um and besides just extending v1 um yeah.

B

That's where we're.

A

At right now, I.

B

I I'm pretty, I am pretty calm this week, so if you want to ping me we can, we can do some research together. I can. I can help you then mostly I I have like emptied my pr queen. So I can. I can take a look into that. Yeah.

A

Cool, I can't quite say the same yet, but every week's.

B

Like that yeah, you have to make time. Otherwise, I'm looking at the cube proxy, the cupping thing as well right, okay,.

A

No worries awesome. Well. Thank you. Everyone on that note, we'll give you six minutes back for your day. I hope you have a good day and talk to you next week.

D

A