Kubernetes SIG Network, 1 Nov 2021

Previous Meeting Next Meeting

⏯

youtube image

►

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

Description

Network Policy API Bi-Weekly Meeting for 20211101

A

Okay, so uh welcome everyone november 1st 2021 meeting of sig network policy. um This is sub project of the sig network group and uh as a reminder, this is an official community meeting that we're recording. So you may want to not say anything that you don't want to publish be published on the internet.

A

uh We have a code of conduct which is basically just be nice and excellent to each other, and there are avenues for reporting, any misconduct that you might perceive with that. Let's get going.

A

I'll first start with just opening up to see what are the most important topics on people's minds. While I look up the sig network uh list of issues, so if you have a topic that you haven't been able to get onto the agenda but you'd like to cover it, uh please speak up now.

A

Anything from cnp side abhishek that you'd like to cover.

B

I see that rahul has added uh something on the agenda, but uh just a quick update on the cnp side is that uh we we've last week pushed a few comments to the uh cnp cap and between sanjeev and you and I, and we will uh continue to push more updates, uh hopefully before the next sig network. Meeting uh to to you, know solidify the to-do's that we had and uh and then let's target, to have the next signet of meeting as a call for review uh from other members.

B

But beyond that uh not much to bring up so that.

A

Let someone have any.

B

Questions sorry so yeah would.

A

That be the thursday after this thursday.

B

A

Okay, so we have about 10 days, so would be great for everybody to get your comments in soon so that we can have a couple of editorial updates within the within this week.

A

uh Rahul, did you have anything you wanted to add on cnp.

A

Looks like I can't hear you rahul, maybe you're, on mute.

A

Is it just me or we can't hear rahul.

B

Yeah, like I can't hear either.

A

I cannot hear him as well.

A

Rahul, we can't hear you in case you're speaking.

C

Hi, can you guys hear me now? Yes, okay, um yeah, sorry about that. um I was wondering: if uh do we want to finish issue triage before we jump into this next one? um I don't have a preference either way.

A

Sure uh let me open up the list here, so let me just share one second.

A

Sorry doing this, the first time for this group so I'll be searching my way around a little bit.

A

Okay, um so how do we I do? Do we just normally search for sig network issues with policy in them, or do we have a tag.

D

We have a tag um I it only is really applied by us, though. So what I normally like to do is just kind of scan. Any recent sig network issues see if they pertain to network policy and if and if so, uh triage them and add the tag, but usually.

E

D

Been um I just do a really quick skim dating back to when the last big network meeting was which was last week. So usually it's a pretty quick process.

A

Okay, I'm searching for issues that are open with sig, slash network and policy. Is that sufficient to see.

D

Yeah, if you want you can remove the label network policy in your query and then it will show you all the issues in sig network um and then you can just add the label to any that need to be added. But usually there isn't. There hasn't been any reason.

A

Okay, I'm just scanning here unless somebody else sees it. I don't really see any policy related issues here.

A

Okay, um I guess we can move on if somebody is aware of any network policy related new issue. um Please pick up it. Apparently there is none, so we can then move on to uh rahul. Whatever you want to bring up, please go ahead.

C

Sure uh so this this is a uh a pretty open-ended sort of question. Slash discussion. I was, uh we were having a discussion sometime last week um with uh tim hawkin um about uh the naming for cluster network policy, and basically he brought up the point that um if and when we start doing multi-cluster uh support for network policies, um we might end up with a confusing situation for like the name cluster network policy, um so he was just suggesting okay.

C

Do we want to rename the object to something else uh that is, you know, maybe feels more natural in a multi-cluster world. um He suggested admin network policy. uh I don't really have a horse in this race per se. I just figured I'd. um You know bring this to our attention, throw it out there see if folks have any thoughts.

A

um Good point: I actually had a detailed discussion with uh tim about multi-cluster network policy and um I probably need to put together a few slides and maybe share on the next call.

A

um Yes, that topic also came up, because when, if we are calling this as cluster network policy, when you have multi-cluster, it will be called multi-cluster cluster network policy, which sounds a bit redundant because you're going to get multi-cluster cluster network policy. So the thought was to call it. Maybe admin network policy so that in the multi-cluster world it would be multi-cluster admin network policy and in the single cluster world it would just be admin network policy.

A

um I think there are, um depending on what tim tim's guidance. We will actually go into more detail on multi-cluster network policy in upcoming uh meetings.

A

um Let's put a pin on this as as something that we might need to do, which is that we might need to call it something else. Instead of cluster network policy, maybe admin network policy, but I think the cap is still you know.

A

We've got two weeks on the cap, so hopefully we'll have a feedback from tim and when we bring it to sig network, we can say okay, we can continue to call it cluster network policy, but given that there is also multi-cluster policy coming up, if we want to change the name to admin network policy, that should be a quick change. So that's some context. I'm actually, you know fairly involved in the multi-cluster stuff, so I'll be happy to share more details. uh Maybe in a in the next call.

E

That sounds good.

A

To everyone yeah yeah, so there are multiple aspects of multi-cluster network policy. There are one that rahul just brought up right now is just the name because to start with, you don't want to call that multi-cluster cluster network policy so might as well right from the beginning call this admin network policy which applies for single cluster and when there's a multi-cluster version, you can call it multi-cluster admin network policy instead of multi-cluster cluster network policy,.

B

So, just just a clarification I think uh for when you say that when you're referencing this in the context of multi-cluster, are we are we talking about a new crd or are we talking about? You know just a policy which is stretching across clusters and we would want to reference it in some sort of that fashion, but it is still the same cnp crd that we are proposing. So I just wanted to clarify which.

A

One so this is very, the multi-cluster network process is very early. It hasn't yet been decided whether it will be a new crd. Potentially it will be in your crd, but it could be a v2 of one or more of the existing crds as well uh sort of like you know, and and in the case of cluster network policy. If cluster network policy crd hasn't been completed, and it could actually be added to this as well.

A

So at the moment it's not yet decided whether it will be a new crd or an existing crd, but just for terminology and naming convenience, regardless of whether that's a separate crd or whether that's a future version of one of the existing crds, the word having clustered two times seems redundant. So let's say there will be something called multi-cluster cluster network policy which may or may not be one of the existing crds. It could be a new cd, it could be an existing crd.

A

Still, the name is somewhat redundant, so tim's suggestion was: let's go ahead and change at least think about changing the name right away, regardless of whether the multi-cluster stuff comes at new crds or extensions to existing crds, so that we are not locked into cluster network policy, then we won't be able to call the other thing. Multi-Cluster cluster network policy, independent of whether it's a new crd or not, that was the feedback, and there was.

A

I had a discussion with them last week about this.

B

Well, that sounds good yeah from the top of my head. I think the admin network policy probably sounds like the most uh logical next alternator. I think, there's also. You can also think about global network policy, but uh but yeah we can. We can come back to it later.

A

So why don't we in the cap, just and in our next iteration edit update, um add a note here that we are also considering calling it admin network policy to avoid any naming redundancy with potential future multi-cluster cluster network policy.

B

Yeah we have a couple of uh naming things to be uh hashed out. uh This would be one. The other is still the uh the subgroup naming for the api group. uh So so we will I'll I'll. Add the to do.

A

Yeah, so I think when we update the rpg in all of us right, the set of open questions on which we need sig networks. Input should be clear and upfront, like you know, here's the current cap that the that the policy group thinks- and here are the open questions. You know naming one one two three, so that we clearly have the open questions right up there and we can get the result with input from sig network.

A

And the rest of the kept would be you know for also for the review, but whatever we think are still open questions. We can list them right up front. As you know, currently, current open questions and mostly it'll, be naming types of things, and and also we can, you know, invite feedback on that, whether higher priorities, larger numbers, higher priority or lower priority things like that.

A

Okay, thanks rahul anything else from you or suresh.

A

C

No nothing on my end.

E

Yeah I mean I don't have anything.

A

Okay, hey um so abhishek yang. You mentioned that. Basically, you know, we've got the updates going on there's still some discussion. uh Anything more you'd like to add.

F

Here from me um I was I was just you know, thinking about a problem that you guys just posted um some some opinion. From my side um I mean I feel like it somewhat depends on. You know, as I've checked mentioned, which way um the crd is going forward, for example, if the right now, the cluster network policy crd, is maybe going to be extended towards you know. Multi-Cluster use cases then agree.

F

um The cluster network policy is too ambiguous, the name it cannot differentiate between like in cluster, and you know, inter cluster, but we if we are doing actually doing another crd for the multi-cluster case, then something like a multi-cluster network policy can work right. It doesn't have to be cluster cluster, but I'm not I'm not opposing to you know changing the cluster network policy to a different name. I'm just saying that you know if we have two different crds, then um you know the current cluster network policy.

F

Crd naming sounds fine to me, but if everybody sees a need to change that, I'm totally okay with that, but yeah. That's.

A

It another thing to note is actually the multi-class discussion so far was both for network policy, which is the name space level network policy, but at a multi-cluster level, as well as potentially right in anticipation of a cluster scoped. So the thought so far is definitely to have the multi-cluster namespace scope policy, which would essentially be like netpole v1, but at a multi-cluster level.

A

But the thought is that naturally, one would probably expect also a multi-cluster cluster scope policy. So uh if you just put the name multi-cluster network policy, that would still be for the namespace version of the multi-cluster.

F

I see that makes that make solar sense.

F

Is there any sort of like preliminary? I don't know like sauce or slide x on this, because I'm curious to learn what are the multi-cluster um namespace network policy use cases yeah.

A

Just stay tuned for a week or two um okay, maybe hopefully, hopefully before next network. uh Okay,.

F

D

Yeah, I think, if there's enough overlap in the use cases, it'll it'll, explain, it'll, show us whether we need another crd or not. In my mind, multi-cluster for both network policy and cluster network policy are things that I mean unless I see use cases that signify other otherwise, it can just be built into the crd with maybe different applied twos, um but I do think multi-cluster network policy is going to be something best solved in v2 of network policy. um So we'll see how that pans out.

D

I think the most important thing obviously is ironing out the user stories.

A

Yeah so more to come very soon on that, but the heads up on that was at least think of the name: admin network policy uh for cluster scope to input policy, regardless of how the crds turn out um one other.

D

Yeah, I have nothing against that.

A

Yeah one other thing is that we've got two new attendees today, so I was hoping we could get to know them, vanu, verma and mark st john. Could you please introduce yourself and welcome to the group.

G

Hi yeah, my name is mark.

E

G

With satish uh and raul and bonna.

A

G

Was actually here last week as well.

A

Okay, sorry, I may have missed you from last time how about you.

A

Was that banu, or was that mark? I thought that was mark right.

C

Yeah, it was uh banu if you're talking, I don't think we can hear you.

G

I think he just got dropped.

C

A

I see him on the call, maybe he might be. I know you might be up.

C

Yeah, you might be muted or you might want to switch mics.

A

Okay, he has a comment saying I'm not I'm talking.

E

Can you hear me now, yes, hi uh sorry, I think I just switched mics and now I'm able to get my voice through hi. uh I work with uh gk network security team at google with uh raul citation mark, and uh this is my first time branding this.

A

Okay, hey welcome both banu and mark, so yeah we've had a great discussion with rahul satish, sometimes vinay has joined and others at gke tim has been interested in the multi-cluster style. That's another sort of new area which is getting kicked off, so there's a lot of things and they seem to be pretty relevant to the gk team as well.

A

um Okay, I don't know that, there's anything more on the agenda. We could have a early close today. Anything else that anybody wants to bring up.

D

I just want to say I talked to matt fenwick, the owner cyclonia. If some of y'all don't know what cyclonus is it's kind of a network policy, yaml analyzer to essentially kind of do some pre-analysis of a given yaml and say what explicitly that network policy is supposed to do. Think of it. As like a spruced up um uh cute cuddle described, uh I talked to him about the possibility of moving that into our network policy api repo, just as a cool tool that you know we could build some cool documentation around.

D

uh He was open to the idea, so that's something I'm gonna look to get help on or do in the next couple weeks. So if you do have some free time, I will post the link to cyclonus in the agenda. I might already have, in the previous one um and I'll, be working with matt to try to carry that over to sig network policy kairico. So if you want a good first issue or good first to do um that'll be awesome.

A

Oh, that's great, andrew yeah that cyclonus project has been waiting in the wings for a while, um so it'll be great to firstly, have that brought in and, secondly, either either integrated to end-to-end tests, or it has relevance for the status work as well. You know a few other things.

D

Yeah, it's already been integrated into, I think, possibly andrea and psyllium. I could be wrong. Don't quote me on that. I'd love to look at inter integrating.

E

D

Open kubernetes um so yeah uh this kind of goes in line for the newer folks. We have a new repo called network policy api. We haven't really done anything with it. I'd love for network policy related documentation. Additional, you know analysis. uh Maybe even real life customer use cases to live there, so that it can be a place just to kind of help. People getting started with our policy. They can go there and play around. So that's the end goal.

D

So if you have any good ideas, feel free to reach out to me, I'm always welcome to anything cool to put in there.

A

Yes, thank you, andrew, uh by the way that report that andrew referred to is I'm gonna just copy it to the chat here.

B

uh Did we get the sample workflows merged? In uh you know we were trying to put over some of the work from amit network policy recipes. I remember that.

D

Issue still hasn't gotten done, he did update the issue and say he was going to do it, but now it's been another month or two so.

B

D

Might unassign the issue and open it back up.

B

Yeah and let's see if we can merge that in that'd be a good good starting point, yeah agreed.

A

Yeah copy it here, that's the name of the sub group, so just for uh for the new folks, so network policy api is a subgroup under sigma network.

A

uh So they are our parent group and we typically develop things here and get approval uh from the parent group.

A

Okay, uh thanks andrew anything else from your side andrew.

D

I don't really have anything else, thanks for praying with me today. I had somewhere else to be during this meeting, but was able to hop in so, and I will be out next week. I'll probably still be in the meeting, but I'll be around feel free to ping me with any questions.

A

Yep sounds good and hopefully now I've got the hang of the the moderator link, so it'll be a little smoother next time.

D

Yeah thanks so much sanji.

B

Yeah, sorry, all right go ahead and appreciate it.

B

I just had a kind of like an administrative notice that this week is going to be my last week at vmware and which means that I will be taking on some other opportunity and some other space, but still in kubernetes space, and I still want to let you know that I will continue to work on the cnb cap for the foreseeable future.

B

uh It and you know- and once I join my new company I'll figure out administratively and with the new management, to see how much time I can dedicate towards you know upstream network policy things, and I will probably have more information in coming weeks. But but I will continue to be part of this group uh just that uh my time might be a little lesser I'll, be a little less involved, but going forward. I believe young will start hosting the uh thursday meetings.

B

uh You'll send out an invite this this thursday, uh starting for next week. But uh you know I just wanted to give a heads up to the group, uh but I will be continuing to be on the slack channel and I'll join for these meetings. And you know if things change in the future. I'll give a good heads up.

A

B

A

Best wishes uh yeah look forward to continuing to work with you abhishek and best wishes to your future opportunities.

B

A

So young yeah definitely we definitely welcome the fact that, firstly, it's been great working with you and we are just still early in the process of making cnp real, so look forward to working with yang, and you continues to continue working with you and also welcoming the new folks that are joining the community.

A

um Yeah this also, you know we we need to continue to reach out. uh We need to you know: we've had folks from juniper and and few other vendors you know come in and out so andrew. I think we should talk about.

A

You know broadening the outreach of the group so that we have more vendor diversity um yeah and we should all sort of have a view of you know the kinds of projects and interesting things that can be done um and and continue to work with sick network, so that uh you know, there's, there's always certain things that can kind of sit in multiple groups or subgroups. So sometimes we just have to work with sig network to figure out. You know the right place to do something.

A

Okay, um thanks abhishek and uh thanks everyone and we'll stop here. Thanks talk to you later next time, bye.

E

Thanks everyone, bye-bye.