Kubernetes SIG Network, 18 Oct 2021

Previous Meeting Next Meeting

⏯

youtube image

►

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

Description

Bi-Weekly Network Policy API Meeting for 20211018

A

Hello, everyone today is october 18 2021.. This is a meeting of the sig network policy, api subgroup to sig network. This is a cncf certified uh meeting, so please be nice to each other and let's have a good, quick meeting today.

A

Okay, so not much on the agenda, um let's open up the florida, whatever people want to talk about. I did want to ask ricardo since you're here, have you had people reaching out to you about the status cap? Yet I've had a few people tell me they were going to reach out to you. I just wanted to hear if that's happened. Yeah.

B

So I guess engine sanjiv or someone else reached me on slack, asking some questions, but nothing more than that. Okay, also I've been I've been pretty busy with other stuff and completely forgot to take a look into that. We just need to at least keep that not not stale, like probably the bot is going to put some stay or some stair life cycle in that cat soon. So right we'll have to remove that.

A

All right, okay, cool good to know, um I'd like to work on it too. Just same thing been pulled to other things. So maybe, um if we get some time this week or this weekend, I'll sync with you and we can take a stab at least keep at least keeping it not stale so that it doesn't get removed. Sound good yeah sounds good cool anyone else here, interested in working on that or want to be included in that discussion.

C

uh Two quick notes, so one is for cnp. We would want to introduce status right from the beginning, and at least the initial thought, at least from my side is to have just you know, supported not supported sort of logic, not necessarily whether it's actually applied on all the nodes, so that whenever we're introducing a new new network policy resource like cnp, uh not every cni will support every um feature or sub feature, so in at least in cnp.

C

We would introduce status right from the beginning and we don't have the api versioning issue, which is the question I was asking ricardo on the slack because with netball v1 yeah, even though it's status strictly speaking, that is a versioning change, even if you're changing status and even if there was no status before um but it's this is this falls into the gray area. Officially, this is a api change, but since it is status, maybe the q barge people can let it slide.

C

But anyway that's for netball v1 for cnp. We would want to introduce it right away.

C

B

Well, remember: yeah yeah, so you made that question and I have been andrea, seek him about that, and he told me that probably it would be a breaking change into tv1.

B

If so, my opinion is that if we change an existing status, it would be a breaking change, but but as we are adding a status which is a super source, maybe this is like we can discuss with the api, reviewers and and the sig network chairs about like hey. We are, we just want to add a status which is a non-existent field and which is known in kubernetes api as a super search. So we it have all of the all of the building blocks, separated from like the network policy spec anyway right, but yeah.

C

B

I remember right now: yeah.

C

Yeah so uh me, you may want to follow up with andrew or whoever else, um but that was the only point of asking you to check and then um on the cnp.

C

We would have and I'll we'll finalize this with uh abhishek meanings back next week, but we would have a goal of having a status which just says, supported or not supported, and at least that's a start and then we'll have opportunities as we go to alpha and beta to refine that further, because we don't have a public, we don't have an api versioning issue with cnp, so we have the opportunity to put in.

B

So if, if you have a proposal for the status field for the cnp and it might be applied to the network policy, my uh recommendation would be to maybe we can write that in the cab and being a team hawking, which is the sponsor of that status field.

B

I I heard the rebel here, uh which is the kind of the sponsor of the status field and asked us to to to make, and we can ask hey team. uh We are thinking about this for the cmp, and probably we will apply this for the network policy as well. So do you think this is the best approach or not because tim, usually he got some some good uh insights about that right.

B

I am like uh he he's a lot of time he's since the beginning in all of this, so maybe he can have a different view of my own. I don't want you or anyone to spend time like with something that it's not desired by zig network, so maybe just draw that for the cmp, and we can ask if this is the same. If this is something that we can bring to the network policy as well,.

C

Yeah, I saw his comments on youtube, but yeah we can do that.

B

Yeah, thank you.

D

Yeah can can you folks keep me in the loop about this as well? I'm I'm. I want to know about uh the status support uh like the supported, not supported thing, for the same reason that we wanted in cnp, which is, I was looking at fqdn and service selector for standard network policies and it's the same problem as if we have some way of indicating supportability.

D

It goes a long way.

A

Right, it's not strict versioning, it's like fail, fail, closed protection or fail. I I don't know what you want to call. It fail safe protection. So if the cni doesn't support it, they can just report that and say: okay, we're all right.

A

Yeah cool, awesome, yeah! Well, it sounds like it's moving along. I think that if we can hash out the status, it will solve a couple things so, whether we do it with a cmp first design or design it in the cmp group and then bring it back to ricardo's cap or vice versa.

A

I think that's all right as long as we have some forward progress on it so um happy to include others in that conversation. If I can get some time this week, I'd love to maybe have a chat with whoever's, interested and I'll post in the uh slack channel kind of an impromptu thing.

A

Any other questions there.

A

Okay, cool um sanjeev. I know you wanted to talk a little bit about um adding multiple applied twos in cmp.

C

Yeah, so yes, we've kind of occasionally touched on this topic, but uh as I was updating the kept last week, I thought it through again, and I just I just felt that it is definitely quite useful to add it. I had a quick chat with abhishek before he was leaving for his vacation and he said yeah. That sounds good. I think we should add it.

C

Some of you commented on the slack as well, but suresh had also one follow-up comment about certain providers having some some constraints, so I was hoping to hear from him or maybe rahul. You have his uh input there. um So do you know what suresh was referring to I mean I was going to actually just go ahead and add it to the cab which is still being updated, but uh rahul. Do you know what suresh's point was he said in general he said it's a good idea, but take note of something else.

C

Regarding providers wanting to have firewall rules only for one one resource at a time.

C

D

So, regarding multiple apply, to's in a single rule.

D

Right right, I don't remember what, like I remember him saying something, but unfortunately I don't remember what it was.

C

Yeah I was hoping he would join or somebody who knew his consumer going.

D

Today um we can yeah. If you want, you can pick it.

C

D

He can yeah, he can. He can get back. I think he's back tomorrow. Yeah.

C

So andrew I was updating the cnp gap. I was gonna, add the manifest and I had started adding it, but then I realized that okay might as well update it with the multiple applied tools as well. So.

E

C

uh I mean, since you abhishek and suresh are seemingly in agreement. Should I go ahead and update the manifest with applied tools, or should I do we need to have some more discussion with suresh or somebody.

A

Else I mean, I think it's all right. I haven't heard anyone reject it and it's following a pretty similar thing: we've done before, where we just make a single entry into a list instead, so.

C

Okay, so, as updates of the cap I'll go ahead and put that I mean we can always review it and provide comments later.

A

C

So, let's go with that track for now that we will actually add multiple applied tools into cnp. It gives it more flexibility and uh yeah.

A

You might just want to add a note like I know he added a couple notes in in the behavior of new selectors. We were adding with cmp, maybe just add a quick note about applied too.

C

Yeah, um the other thing is, uh I think, rahul the google guys wanted to also introduce additional selectors. uh Would you do you have an update on that or or should we discuss that in the future.

D

um I yeah I mean the the goal is to aggressively pursue service, selector or service account selector and fqdn. um It's both for cnp and for netpol. I don't have anything to update here. I think the next steps for me would be I I need to. I want to follow up with the cluster status thing and sort of based on what we do with cluster status. The goal would be if cluster status is workable, then we can consider adding these selectors into cnp and network policy at a later date and it's all fairly extensible.

D

If it's not going to be workable, if if the status won't be able to report sort of what the cni supports and what doesn't then I think we need to have. It would be nice to have a deeper conversation in the cnp side, because we have some flexibility in what to do, but on the network policy side we might have to kick around adding another cr crd or something.

D

While we wait for uh net pole v2 to roll around, because v2 is probably quite a ways out and it's unclear if we want to get new selectors on v2 right.

A

I will say the only the only other opinion there is. I we did talk a lot about fqdn selectors in the past and, like generally, the sediment at that time was we didn't want to move up any into any higher layers um like within network policy or cluster network policy.

A

um There's also some complexities with uh dns subtleties when we start talking about fqdn.

A

So it's something to think about like if we, if we bring that if we like through fqdn selectors in cmp, I think that would generate a fair amount of upstream of sig network uh controversy. That's for sure, more so.

D

Than like a service.

A

Account selector.

D

I mean that's good to know I mean I, I think I'll take what I can get. So if, if service account selector is you know much more likely to get broad approval, I'm very happy to start small work there and then fqdn. We can kind of have chugging along in parallel and just see if we can get traction as a separate issue, so it doesn't muddy the waters and slow us down.

A

Right- and I think you know right now- cmp doesn't adjust north-south traffic, so really it doesn't make a ton of sense to have uh fqdn in the current cmp cap. But I mean my goal and I think the others goal with cmp right now was to either look at in the future, adding some sort of way to address north-south traffic or adding a new resource that would act as a moat around the cluster, and that might be the perfect place to implement something like a fqdn policy.

A

So that makes sense.

C

Yeah, I think at this moment, in terms of additional selectors, the service selector and the service account. Selector are probably the two which will be a little bit easier. Each of them might also have some issues, but let's let them go to the end so and again, because cnp is still pre-alpha.

C

We have plenty of time to add new selectors. uh The time when selectors get frozen is when we are in beta, but of course, we'll try to do it as early as possible. Also, we did talk about having you know some kind of selector type in um in the in the spec, so that you can just just keep on enumerating newer and newer kinds of selectors in the future. So, even if you, even if service account does make it and fqdn, is something for the future.

C

It'll have a new, enum and you'll be able to handle cleanly um the supportability and non-supportability.

A

C

So please uh so quick note for now is uh we would? Would you be okay with us adding just a essentially a selector type penum into the spec so that we can keep defining enums for various selectors and that yeah that combined will uh will will saw, will address it because the status can report back? You know, based on the type of selector, whether it's supported or not supported.

D

So would the uh so that would look like. Basically, we have an enum which says here are all these possible selectors and then on the object when users configure it they're expected to provide a like either a single enum value or a list of enum values that they've used in that object. How? How does that work.

C

Yeah, so the initial thought again, I'm not sure whether this fits into the metadata api of the cube api or whether we need to put it outside. But basically you know when you're doing, let's say when you're doing an apply to and you're defining a selector. Let's say it's a part selector.

C

Maybe we have an opportunity to add not just the part selector, but the selected type enum. So you know that the selected type enum is two meaning. It's a part plus namespace selector. If the selector type is four, which means it's that future fqdn selector. But currently we don't support fqdn, so the cni will immediately know. Okay, I don't support selector type 4 and I can throw status saying not supported, even though I don't know what the future fqdn selector might look like.

C

E

C

That I support selectors one two and three anything I see other than that. I will, I will say, unsupported and you can add your own definition for selector number. Four in the future.

D

Okay, so so it's sort of where we'll wrap the like the pod, selector or like there'll, be a selector object, which has a type field which is like one of the enums and then it'll have a bunch of fields which only one can be instantiated at a time which is all of the selectors that it has, and we would basically add a value, a possible value to the enum and grow this object. Every time we wanted to add a selector.

D

Did that make sense? That's.

C

One thought we haven't quite finalized it because we have to look at whether this works with the cube cube, api's selector object because we are introducing a new field into an you know, something that already exists. So there may be an issue there or we might have to put it somewhere other than the.

C

One of the existing syllabus- that's just a thought for now, but for now you have time because cnp is not yet not even in alpha, forget beta to go ahead and propose new selectors and start with service account and services, and most likely they can get pulled into cnp even before it gets to beta.

D

That makes sense um just to double check um is: is the latest cap still 2522? um Is that what you, everyone's updating, um is 2522 the right number? Maybe the pr number.

C

um Go and check.

D

That's just the link. That's at the top of our meeting.

A

Notes or like I think, there's only one cup for cmp you mean the cup yeah yeah for cnp yeah uh yeah, that's there's only been one. I don't think. We've opened, multiple abhishek's been working on it from the beginning. um Okay, perfect.

D

Okay, yeah, I I yeah. I just want to make sure I'm reading the right thing yep. I just checked.

A

C

So if you're making any changes uh coordinate with uh some of us, because there's several people making cap updates right now and we're kind of doing it a little bit ad hoc.

A

I mean not, every everyone doesn't have the support. The only people that have supported make actual changes without approval is you me and abhishek sanji so couldn't he could open a pr against it, but yeah.

D

Make it make sense yeah, I I'd mostly just be reading and then I'd, probably ping, you all on slack. If I had a thought or something.

A

Yeah, please please do.

C

So that's all I had so essentially yeah looks like we will probably have multiple applied tools in the cmp and I'll update the examples to use that, and then we can comment on that.

A

Okay sounds good to me.

A

Okay, are there any other questions, comments.

A

I I think I will say the one thing with the status cap I want to read up more on before I talk with you. Ricardo is, is what what we do for conditions now and like how we could use the existing conditions object here. um I just am not up to date there so or else I would have that conversation right now with you. So um any other questions I did ask for the agenda to be added to our calendar. Invite uh casey has those permissions.

A

I don't think you do ricardo and just make it easier for people to use.

A

um Otherwise I'm going to be updating the user stories, cmp user stories in our signet or policy api repo, hopefully here soon, and we can start brainstorming about what else we'd like to keep there I'd love to have various documentations on network policy and other stuff there. So if people want to have their, you know, first pr to a kubernetes or repo that'd be a great place to do it. Let me know if you have any ideas.

A

Cool well we're 23 minutes past the hour. If there's nothing else, we can end early I'll, open the floor.

A

Nothing else well, does everyone will get some time back today? I hope you all have a really good week. The cmp subgroup meeting will still be on thursday, even though abhishek's not here so happy to answer any questions um and yeah. I think that's all I have thanks for coming today, thanks for the good conversation and we'll keep trudging along here, really appreciate it.

B

Dear folks, thank you.

A

Thank you, bye.