Kubernetes SIG Network, 21 Oct 2020

Previous Meeting Next Meeting

⏯

youtube image

►

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

Description

Network Policy API Bi-Weekly Meeting for 20201021

A

Okay, there we go hi everybody. uh This is a this is the uh sig network uh network policy, api sub sub project, and this is an official kubernetes cncf meeting, so everybody be nice to each other and now ricardo. Take it away all right.

B

Thank you jay, so we have an agenda here uh with the first 15 minutes to pass through the cap and issues that we have opened to the port range in the name. Space selector. I don't know if abhishek wants also.

C

B

Pass through the the cluster's corporate network policy, we have uh I've left 30 minutes to discuss the the document from andrew about the summarization and and the user stories that were left behind in this first pass. And then we have 10 minutes left for ideas and next steps and discussing anything else that we want. So if anyone wants.

C

To propose anything else.

B

Please put here in the agenda before the last 10 minutes and I'm going to share my screen. So here we go.

B

Where is it, let me close everything yeah so uh so we have started to discuss about the the port range cap, it's over here and andrea abhishek and also then winship. They have.

D

C

B

Discussion of the of the cap and andrew have asked me has asked me to write a document, so we can discuss about the the syntax and the localization.

C

Of the and the location of each.

B

Of the of the fields before uh doing another commit into the into the cab, so here is the document we we've got the original proposal and I honestly I can't remember why why I wrote that I just wrote anything that came to my mind and then andrew and abshak. They have.

C

B

This this syntax having a port range field whenever this field is going to be with a from and two and a single port specification. If you want to specify a single port or different from into and the exception being a singular, an array of singular parts being excluded from from this port range. So you might have a from two and the exception field, or you might have only.

C

The part the single part view.

B

And we have, we have some something to decide here about if, if we want to support named ports like http, port and https port, for whatever cni supports this, if we want to use single port inside the port range inside the port range spec, if we went this inside the port range wait, why would you why would you want to support a named.

E

B

E

B

Range, I don't know we we already supported in the in the in the service and the endpoint api. So I thought that, like someone.

F

B

Ask this because.

F

Some sort of cni supports limit part, like seems like that's a really weird, because it's like not a quantitative thing, yeah like so.

G

I think it it makes sense if we are also going to support single port.

F

G

Also not putting so single ports in the same struct, uh then maybe we can have a validation wherein, like you know, the the name port is uh available only if it's a single port field or other the field type could be interesting, just just to be similar to how the current ports are.

B

Like http, instead of the name, instead of the numbered part right, I'm sure yeah.

G

Yeah, so the type could be like a intro string here.

B

Yeah, I I agree with that. I think I think you might have like a a case where a cni or an enterprise pharma or anything supports an import reads from etc. Slash services- I don't know so maybe this is this- is something we need to look at.

H

So just a question here: um you you basically have a port range for this field right, why you have a single port here, I'm a little confused. What's the difference of this one, this is the one above says: port 6379,.

I

Yeah I had the same question like why: why do we have both.

H

I mean, I don't think I have a single point.

G

Here so when I I think suggested was, uh I think, ricardo also had the same thought process was that the port and protocol are existing fields today, and if we want to have a single field to for all the ports, then maybe we deprecate the existing field, but still support it and then internally convert it into the new struct.

G

This is similar to how uh for pause. You know you had multiple pod ips that were introduced. We still have two fields, one pod ip and one for ips and the pod ip is internally converted into the power ipc until we uh deprecate and delete the old field, and that was my thought process, but I could be wrong.

H

I was thinking that you, you want to add new fields right so maybe just add a poor range field instead of obsoleting the old one. Basically, then, you have a backward compatibility.

H

Because right, um so, if you say okay, if you do a single port, you just program port. If you have a proven you program programs, will that be good enough or.

J

G

Yeah, I think that also makes sense.

B

I

By the proposal we can remove this from here, right and and in particular like I think, if, if we were to go with the the other proposal, which just puts port ranges in its own field, not under reports, then I think it makes more sense. Yeah like in this scenario, I think it even makes makes even more sense to not have port in four ranges.

B

Okay, so you are saying that we might have only ports or port ranges in.

I

C

B

A

Are these are these two proposals like logically equivalent- and it's just the data structures we're debating here or is there some fundamental thing that one can do that? The other can't.

B

Actually, this was the second decision jay like about the location and naming if port range for trains was going to be inside the ports or if port range was going to be part of ingress and agrees and not part of the parts.

A

Yeah, that seems like there's this difference. It feels to me like there's some kind of different story that one would support over the other. That's why I'm asking, but I just can't think of what that would be.

I

Yeah, I think the biggest thing is like it: it'll change the way the validation happens um because now you're inspecting like, if you put port rangers as a top level field in ingress, you just have to validate one or the other, whereas if it's embedded in just ports, you'd have to go through every port and then validate against each. But I agree like it's not a huge difference, but I think it's worth squibbling over and seeing which one looks better, at least in yammo and whatnot.

A

Well, what I'm saying is, I don't know if it's a difference or not, but if it's not a difference, that's fine. If everyone else agrees, I'm just not sure I just want to make sure.

A

At least one of us is sure that it's you know not going to logically prevent certain things from it.

A

Can you go back up? I want to see the other one. It seems like semantically. It's confusing to keep port and port ranges right, because ports are like kind of like a top level thing as it is.

I

Sorry you're saying so you're saying not to embed it into ports or you're, saying to keep them separate.

A

A

I guess I'm kind of saying that.

A

Right now, ports.

A

Like I guess they need to it's almost like yeah, the best thing would be to have them. I guess I don't know what I'm saying, because I'm not sure what's better. I can see.

I

Yeah, so I'm starting to think that the the distinction that we have to make to make a decision is: will there be network policies where you specify both single ports and arrange, and I think yes, there are and based on that like which, which one makes more sense, maybe the first one in that case.

B

This one right, like have important port ranges, and you and you can like exclude one from the other.

I

I think so maybe.

B

Yeah I was, I was also thinking that the single port proposal just makes sense in this case here like so we are moving to a port range. You can use a ports or port range, but if you want to use port ranges with a single port, you can. You might have this like like here as an individual field, but I agree that this for the first one here is much more clear, clean.

A

Yeah, that's the one, that's intuitive, because it's not trampling the logic of the old one and it's.

A

H

There is another choice: I'm not sure if it's better or worse just to provide it that if you don't want to do anything change, then it's just like you use a port before as a number. But now you change that to be a string so that it could be either port 6379 or port 30k to 30 20k.

A

Yeah, I really like that. I just knew that it wouldn't get accepted because it's kind of a little hacky, but that's totally what everybody wants right. That's what we all do on ec2 right and that seems like, like.

H

The easiest way and then it's very natural unless you want to accept all things, because it's only one dimension, you don't need to accept yeah.

A

H

Cut the rest, yeah.

A

This one is awesome, there's no debate that this is the best thing. It's also totally impossible for either.

H

It's different from the first one, though for original proposal, though, because that way you have a list of words right, because the original way of doing this course is, like you have a list of protocol port local port right. So we do. Maybe we don't want to change that. The only thing we can is this port could be either a single port or a wrench. It's like separate.

H

You see what I mean.

I

So saying you're saying like instead of a new port range field, we're just adapting the existing port field to like parse different forms of strings that can exist. Yeah.

A

Yeah, that's what everybody really wants.

H

Yeah and then you just change that tab instead of an integer, you can be introduced in detail.

A

How likely is that to get completely rejected if we tried to bring like andrew, like what do you like? Would that just get completely shot down? If we tried to push this up to the broader thing.

I

I don't know, I think I think it'd be helpful to put examples like here. What that would look like.

I

H

Think is it basically.

I

This one like, is it basically like what we have right, what required to put here for port range, but it's just on the existing ports field or saying: did you mean this? The syntax will look different too.

H

I was thinking that it's on the simple field right, so it's like this and yeah yeah yeah yeah, and then you can have next one with another dash protocol tcp port. I mean it's the same as currently run yeah and then that one could be a single port.

A

Anybody else have an opinion on this. Does this seem particularly intuitive to anyone else here? I.

H

Mean yeah, it's really dude.

I

Yeah, I think it is intuitive, but I I have like I feel like on the api best practices world. There's going to be something around like you. Shouldn't modify like interest string values into, like you shouldn't, like add more meaning into existing inter-string values.

H

How about how about reaching that portugal rent so that it's also a new field? But it's just a string. So we don't do that complicated from two except.

A

To pick on it still, but it's slightly harder to pick on then.

B

The problem of this one was was the exception right. The exception inside the range.

I

Right, okay will look ugly if you have like, if you have multiple exceptions in a large range, then you end up having like the like. The value of the port ranges become weird because they cut off at some point and then the next range starts at a it. It's hard to read you.

A

Have to have a comma in there or something or a colon or something weird.

H

Okay, well yeah, I mean either way. I was just thinking that it looks like pretty complicated for a simple requirement yeah, but I I I totally understand another cool reason. I mean this is a one-dimensional plan right. So, unlike ipa address, which.

B

H

Have to discuss.

B

So I'm okay with both proposals.

I

Can we can we write? Can we write it down like? Can we can we write down what things proposal is like? If I have let's say I have a port range like between 30 000 and one thousand, and I have exceptions at like three thousand one and or three thousand one, and you know somewhere in the middle and, like I have five exceptions between that like would it be hard to read just a moment.

A

I feel like you might just do like three port ranges right, like port range, port range port range.

H

Point range port rings right I mean that.

A

Called a separated list right.

B

Look at me jay now I'm a google docs engineer. I know you're getting good at this man.

I

Well, I think what zane was saying is that it wouldn't be comma separated. It would just be multiple ranges where the exceptions are just cut out of each round.

E

A

Let's see, let's do it probably.

B

So like this one, two 13 39, but I want to skip the 30.

E

H

Way right and then, if you have a single one, you just do port.

A

H

H

I mean it, it just looks much shorter. I don't know.

B

What why can't we have exceptions?

B

Oh, never mind? I was going to say like this one like when you want certain it might be tables but we'll break things so.

A

Yeah, I mean, I think, the extent of like ethical hacking. The api we can do is have that one dash. I don't think we can make our own.

I

I think I think even the dash will be a bit like like contentious like do. We have any other anywhere else in the api where we have like a dash to to indicate a range or anything like that.

H

We can also have an array there, just to say, like um you will have a bracket right like.

A

An even numbered array.

H

Well, just two: it's like this, like you, have a um square bracket.

E

H

Yeah that that is another way, but I don't know.

B

But I think that's uh that's pretty confused. That's.

H

Working when you.

B

Put that in the api spec, how are you going to say that the first field is always the two, the the from and the second one too.

H

That's that's true, not very cool. I.

C

H

Just around the ideas, maybe.

C

Yeah yeah go ahead.

B

H

It's confusing, I agree, yeah the record.

F

Separating with two points, yeah.

A

So I guess the real question is: do we want to pursue? We all, I think kind of agree. This is an interesting thing. Is it's something that we want to pursue as something we don't care enough to like worry about, because I agree that it would be really cool. I just feel like probabilistically.

A

Is there any way we're going to come up with a good syntax for it? That's terse that we think has a high probability of being accepted.

H

One thing I could feel difference is which way is easier to validate with a schema um like, for example, your fraud needs to be smaller than two. All your acceptance could be in the middle.

I

Or even like parsing, the cena has to parse that range and like do a string, parse and find out what the front and two is.

G

I think it will be the bonus of the in the api that we need to add this validation on it, because this is a string. Then we need to figure out whether this is a import or this is a range of parts. So there's going to be a lot of email.

A

So it sounds like everybody's basically saying it's a cool idea, but there's probably no practical way. We could get it through.

H

Okay, so if that's the case, then, probably with you still to the original proposal with from to accept the lessons.

B

I I I just don't don't understand why this is this is not viable like. Can we do just the streaming sponsor inside the api and check if this is like a an array of two.

A

It's viable for us, but it's not going to be viable for people that review apis really.

I

Well, no, like so from the implementation of the um from a cni implementation perspective right. The cni has like we're offloading complexity off of the api and telling the cni's to be like parse, this string in this format, and if it's not in this format, then you know unknown behavior.

A

It's less self-describing, it's less declarative, it's not type safe, there's all sorts of computer science and sort of things, but.

G

I I think the validation of this will not be in the cnn. This should be in the api server itself or in like kubernetes aka repository as well, because, similarly, because even for the ip blocks, the validation logic is present in kubernetes.

I

Right but they still have to parse it right.

G

I

J

Like someone should at least.

I

Validate that, like someone, should go through the cycles of like asking some, it may be one of the api approvers and seeing if it's actually a crazy idea or if we're just kind of making things up.

B

Okay, I might ask this in the api machinery.

A

Yeah, I mean it's kind of an interesting thing just to know whether we maybe I'm glad you brought that up zang, because I was thinking the same thing, but I was afraid to say anything because I was afraid everybody would just say I was crazy, but maybe there's like a one percent chance that we can keep the stream yeah. So.

B

I'm gonna put this as.

H

Maybe let's just put this as an option and then just um talk with api guys to see which or talk with him to see which way he would prefer. I mean.

D

Out of curiosity, did we agree that the validation should be on the api and not on the cni, because if there is no validation on the api, the cni can have different restrictions right everything I can have different.

H

I mean it would be nice if we can put the validation to a schema.

J

H

I mean I mean for this, the middle one right, I believe you can. The only thing I wasn't sure is um the schema. Validation. Probably cannot tell you that our from is smaller than or except must be. In the middle I mean this kind of cross-field.

H

Validation is pretty hard with steamer, but schema can't tell you, um for example, there's a dash must be the stream because it must match up pretty uh rejects that one is easier to do, because it's a single file think about it right. It's hard for the schema to do cross check across different fields.

B

Okay, so just uh just as a decision of this one, I might bring this to the api folks and ask them if it's valid, to make this. This sort of validation inside the api machinery is that, okay for everyone.

H

E

H

Also know that, for the current, for example, ip block right, we have a requirement to say that except needs to be in the within the ip block, but in practice you cannot validate that in schema thing. I provided just skip that, except if it's outside of the range.

B

Okay, and about about the exception field is everyone? Does everyone agree that we might have like the exception? One inside the the port depart like not declaring this in the part range or anyone had have some strong feeling that we need also to have an exception field here like having this inside.

C

The part range.

B

Like having another exception, feel that if port range is declared, this one is also an array of integers.

A

Or whether it should be whether exceptions should.

E

Yeah like having.

B

Instead of having this, we declaring this.

A

I mean it feels to me like the the way I would do it is. I would first check to see whether that dash is reasonable at all, and then I would then I would kind of probe that stuff, because it's like there's a million things you could do for the accept.

A

Okay, I don't even know if it's worth it to worry about it until we, because this whole thing they may just say no right, but I don't know, that's just my thought.

B

I

So, let's move forward because I.

B

Like spend 30 minutes in this one.

I

The other thing to follow up um we could do it like asynchronously, is whether ranges whether we have to validate like ranges between each other, like if one range overlaps another. If that should fail, validation.

B

Yeah, the location inside the ports having a port ranges for you. The first one is that, okay to you, andrew, instead of having like a ports and a port ranges.

I

um I don't know what do other folks think I'm I'm not sold on either one yet I think I need to think about it. More yeah just.

I

But it seems like the group is leaning towards having port ranges in the current ports field. Maybe just call it range instead of port ranges, because it's already under quotes.

E

B

I'm just okay, so this is a range right.

G

This is good to me.

A

I kind of feel like the overlap thing. As far as that goes, I feel like that's a no-op to me, because I feel like if somebody wants to redundantly declare that a port, a port is allowed that's kind of okay based on the allow semantics, but it would be weird if somebody allowed a port in range in one declaration and then disallowed it as an accept or another, but I feel like there's a logical order, that's happening which is kind of the overriding way things are done.

G

Range and then the same port number same port number in the exact range. uh As long as there is an allow.

H

Yeah, that should be a union if you have conflicting, because we are doing white lists here.

A

J

Yeah that makes sense.

B

Okay, so by now anything else in this one folks, now, let's move forward one, two, okay, so jay, do you want to present your dog, your dog space selector? Do you want me to.

E

Open here or do you want to share your screen uh yeah? I can share it okay, so let's stop sharing. Oh, I guess you're already.

A

Sharing, oh, never.

A

A

Okay, there we.

A

A

Okay y'all see my screen.

B

E

E

A

There we go there, it is okay, so I copied gobind's proposal and I just like redid it that way. I feel, like that's kind of the new thing we're doing, and I feel like it kind of makes sense to do this. Can you zoom.

I

In a bit, it's a little small.

A

E

F

Actually, we are seeing your whole screen jay. That's! Oh yeah! That's why? Okay.

A

Well, either way I'll just make it bigger. Is that good.

I

A

um All right so.

A

Now this is spread across two pages, but I can just put a page break in here, so this is roughly I mean we all kind of know what this is.

A

So I I mean I guess it's worth slightly going through this, it's kind of like so I spent like I spent like four hours the other day like three or four weeks ago, like reading everything I could find about how the api evolved- and I dug this one thing up- we have a page about this, and actually so this goes back all the way to two 2016 when they made this api.

A

They were saying you know, I don't know if we should use labels and so there's a recent network issue that came up again about this and um it was. It was pretty clear that, like I think, there's a lot of you know people that just want to be able to select by names to the labels.

A

So I feel like the argument we make for this is not going to be particularly difficult.

A

So then, the only question to me that first came up and anybody can interrupt me here right, like I'm just kind of spitballing, but the first thing that came to me was like um cardinality was what I was thinking of right. So, like you know right now, you can have a namespace selector and the namespace selector can select multiple namespaces because of the fact that it uses labels and there's a many to one relationship between labels and namespaces right.

A

So you could have the same label in many namespaces, um and so um or maybe it's many or many, I guess but anyways. The point is that you kind of need it to be plural. I guess so it's not really a namespace's name, it's more like a namespaces, his name. I guess, um but I think it's pretty self. I don't.

A

I don't know I feel like it's pretty self-explanatory. I wasn't able to think of any wrinkles, but I admittedly have been a little distracted lately. So is there much more to it than this? I don't know. Let me know I still. I feel like it's the same thing like we just mentioned before. As far as you know,.

I

Well, yeah, I think I think this is pretty much what I think this is pretty much what we were kind of saying like instead of namespace selector, um just a list of namespace names. I think it would have been great if names does the field. Namespace selector was a top level field and then it had like a label field and a names field, but we can't that would be a breaking change to change like name space selector is already a label selector, so we can't do that.

I

So I I think this is the next best thing to do and seems pretty reasonable.

A

Yeah, so I was thinking about that and dan winship, I think, mentioned something and the other day about how, as long as you don't break the yaml, it's not technically a breaking change is that true, because you can do an api conversion between or no.

I

I think I think so, but then it's it would be a code breaking change for like cni implementations of it. Maybe so that's a good point like I think, there's a way to do it, uh where you don't break the yaml, because you can just wrap the label selector under another struct, that's embedded and then you just add the names feel to it.

I

A

If we could do that now, I guess it's a question for abhishek right, so you work on a cni right. So what do you all do to parse these? Like do you? It would break your little golang struct that parses things right.

G

We kind of like uh rely on the fact that the name selector is a label selector, and then we use all the package and figures or methods and functions that they provide the library uh yeah. You move it to a different kind of struct and then they might. We need to have that kind of quote and I guess there will be code changes required. Yeah.

A

So it's practically a breaking change, but not theoretically.

I

And it's not actually.

A

I

If name space selector, so if we had a wrapper struct and the label, selector was uh an embedded field in the new struct. Would that still be a breaking change.

G

uh No, I think, as long as we should be able to still access label selector as us, I think uh it should not. Now now I see what you're trying to do you're trying to embed that into a new struct and uh add a new match name or whatever names.

A

Inside as a field.

G

Probably that should work.

I

See that would break any controller that has to construct construct a network policy, though, because they have to wrap the new field, but yeah yeah.

A

I feel like yeah, it would wind up with.

H

There is, and I mean I'm, throwing out another idea, I'm not sure if you might want you guys to answer so since we already have a namespace vector. If we instead of match labels, you have a match name and then would that work there or.

E

H

Right and then now you can see, you don't need that it just dashed name right: that's backhand dash! It's an origin, yeah right.

H

You can you can do a you are array there. You can just.

A

Well, but that's the one: that's the pod selector, though right.

H

Well, when you from a namespace is what and is that the path selector? No, we actually have a from name space director. So basically your name space vector can be under past vector or be independent. I think.

E

H

I'm looking at this example of narrow policy right you.

H

Yeah, it's not underpass. Actually, it's a separate namespace selector.

I

Yeah, I think what zanga is suggesting is instead of namespaces it. So that would be that would go back to the original namespace selector and then under namespace. Selector is match names right.

H

Yeah, I mean that's just another choice here,.

G

uh But here again, if, if you need to add that you, you need to edit or modify a matter of even label selector right.

I

Yeah, I think it's the same. It's the same as like we'd have to wrap the name space selector in a new struct like we're, saying before and add a match name skill to it.

G

Yeah, but then also, then, restrict uh other types of selector to not use it right. For example, if pod selector is also okay. Okay, so you are only changing the name space selector to the new new app.

H

Oh, so you are seeing on the line that sharing the same structure.

G

The label, metal, even label selector.

H

Oh, that could be.

G

But but then I think I think what andrew was suggesting that we create a new embedded type and only namespace selector references that embedded type, while the others still remain with the metadata label. Selector.

A

Yeah, so it would be in this at this level, this level you can do it see yeah.

H

uh So you are this: okay, that's a good point. So it's already tied to a label selector. That means you cannot add a actual field. Okay, that makes sense. Okay, yeah! Basically, you can expand that one.

I

Yeah, I think that's what we were discussing before is: if, if you keep the json tag the same, can you extend it without breaking it and I'm not sure yet, if that would be considered breaking.

H

I feel like okay.

A

H

I think that makes sense. I think we can just switch back. Sorry, sorry, I think no.

A

That's good zayn you're, coming up with all these crazy ideas today that might work who knows.

I

Like I do like this better, like I like namespace selector, with match names and match labels, if we, if we didn't, have to worry about breaking changes like, I think, that's much better api design, I.

A

I mean, I think this is just again something we should follow up on as a like, a team or whatever we should know like. We should probably have a good feeling about these things and how they work, so maybe I'll try to hack around with that just to see if I can get it working. So I think it's a good idea just to think about.

H

Yeah, but I think if we went back backwards, compatibility right and we need to make sure that the new, basically, your controller needs to be able to pass both the old version and the new version.

A

Yeah, it's gonna work.

H

So then that means you cannot extend the existing file. You can only add right. You cannot change the type so when I agree thing that we can just do a from namespace yeah yeah.

A

Yeah additive is always safer right right.

H

Yeah yeah, I think that makes sense.

A

But you know, I think this is going to get more. These things are important, though, so this is great, because the reason I really appreciate you bringing this up zhang is that I feel like at some point we're going to hit a point where we have something we want to do, maybe where we really maybe want to stretch what we can get away with in the v1 and still call ourselves v1, and so, if we understand how to do these things, better it'll be good for us. I think.

A

I mean this is it I don't have anything else to say about this. I didn't really find that there was a lot of corner cases here so.

I

Your note of your note below around regex's- I I don't think we want to. I don't think we want to support that at all, because then you could like create. You can craft your own name, space, matching the regex and do stuff yeah. That was zang's idea too.

H

Okay, let's not make it more complicated, we can remove, rejects yeah. The only thing, though I the only thing that actually reminds me. Another thing is I actually, in a practice, actually hit one case where we talk about namespace. Is they want every namespace except someone.

H

Like, for example, you want some policy to apply to every namespace except coupe system- oh yeah yeah, because then every new namespace is automatically applied.

A

Well, over you know, over a previous place I was at I I remember. There was name spaces had names that were predictable, so people didn't just go, make random name spaces like they were prefixed and so there's a couple of. I think these user stories there so.

H

When we we had these cases because we couldn't predict what user is going to add right yeah, but we want some parts to be applied to that namespace. Whatever is there so we were like accept this cube system. Everyone else needs to update that. So do we want to consider that case?

H

Oh, do we think we agree.

K

Sorry, uh I thought that would be a good case for cluster neural policy. No.

H

B

H

Could be yeah yeah that could be.

G

It can be useful.

H

You you apply some diarrhea or restrictions to every non-privileged namespace.

K

Yeah correct so it's kind of like a for loop that just you know, uh applies a basic policy to you know all all namespaces that you yeah so yeah. That could be a cluster in our policy use case. But you know if anybody has another opinion. Here's to here.

B

Yeah, I was thinking about this saying like how much is this related to cluster network policy, so I was ready for that.

A

I mean if it's in the from.

A

You're, not it's not changing the to me. It's not necessarily cluster because well, I guess it's well. I guess once you once you have a port ring you're doing something weird with the data model already, where you're starting to expand to you know.

A

I don't know I I mean I feel like you're when you have a label selector you're already allowing people to select multiple namespaces.

A

Now we have a port range, we're allowing people to select multiple ports, so the uh I don't think that this increases the cardinality of, what's being selected against in any fundamentally different way than what you get with a label selector. So I I'm not sure to me. It doesn't feel like it. It's like it doesn't feel like we're, cheating and making a network a cluster network policy by using the projects. It feels.

B

A

It's a natural thing to do, but I don't have a strong opinion. I guess I'd be down to pursue the regex.

A

But I don't think I don't think we have a strong enough strong opinions.

H

My feelings we may not need to, we, we don't need to support, rejects which so too complicated.

C

H

We might at least support all like all namespace, except.

A

Oh and accept okay,.

H

It is right, so um so, at least for that particular case, we are able to address it. I mean I agree that it can be just in class on our policy, but we probably eventually need to solve it there right. It says every namespace, except the good system can talk to external, for example, right.

A

So then we'd have to do like a all which would be like a boolean or or we do an all, except that would be hard to express any ideas. How you expect express this I mean like you, can do all namespace.

H

You can use this from not namespace, for example, so that or name or namespace exclude. I don't know, what's the better name.

A

Thank you. Well, you could do an exclude.

I

Exclude namespaces, probably.

H

You say it's crude namespace.

A

How would you express all.

A

I guess that would work because that well but exclude, doesn't so would that satisfy your kube system. So this thing comes up and it creates explicit from rules for back end involved and then what does it do? It doesn't exclude namespace, so it makes an empty. It makes a.

I

Maybe we can't support regex, but maybe we can support like wild card as a special case.

I

Like a prefix yeah, we can literally that that exact character as an all yeah, like that character, or an exact name space only. You know that way.

F

I

They using regex, if you do that, but.

H

But yeah I don't know, another question is: how does this interact with namespace spectra.

I

I would think they have to be mutually exclusive, like you have to use the label selector or this one. I.

A

Was thinking it would be additive yeah right, because why would it not be right like the namespace selector, as is if I have a namespace, with a million labels on it and one of them and I and I'm only selecting for one of them? So if I have an empty namespace, selector or you know I mean, then it selects anything right so.

H

That's actually a rubber wheel, for example, if you have a name, space here says allow from back end, then you have another one says from namespace selector, back-end and patch, that stays there, like whatever label. What does that mean? Are you going to allow every pass from that namespace or you only allow the path with selected label in that namespace, and I got a little confused here now.

H

Okay, if it's a union model, that means once we write here, everything inside that namespace is about.

A

So what what's the what's the question.

H

Okay, my question is: okay, with this schema right, how do we express that? We only want to allow part with selected label in namespace a? How do we do that.

I

Pods with so so we're not changing pot selector right we're only changing name space.

K

What is it right.

A

H

J

Is a question about? Can the namespaces still be used in conjunction with the path selector.

H

Right last one, I guess the answer of that should be: yes. Is that right, so a path selector can can use can be used together with namespace or namespace vector.

B

Yeah, I think so I think they are not mutually exclusive.

I

Yeah, what we were saying is before we were saying that whether it should be like whether name spaces and namespace selectors should be mutually exclusive, but I think I don't think we're going to touch pod selector.

H

Okay, so basically, for example, when you have this, when you have the current configuration that um and jay is doing here, what does it mean? It means it can be talked means from a yeah go ahead.

A

So in this one you have a pod and a namespace selector, so you're going to need basically namespace with a1 or any namespace named backend or vault plus the, but with the exception that in those name spaces they the pods that you're talking to need to have the label b2.

H

No, that's not plus right when you have you when you have an array here, it's not part. It's all.

A

J

H

If you don't have the dash this end,.

A

Oh yeah, okay,.

H

Right I mean, if you don't have that um two of them, I'm not saying that you remove all of them right.

E

H

uh Then put that dash on the first pass vector.

H

Right yeah, so if you do this, this end.

A

Yeah, that's what I meant to do right, yeah.

H

Right, but I think this actually is.

J

Yeah, this is really confusing. If put it this way. This is very.

H

J

I feel like in this case name three selector and namespace should be mutually exclusive, like you can only expensive one sort of sort of like the the port. uh I don't know it's not a it's a good analogy, but you know yeah in this case, I don't think.

H

Yeah, it's mutually exclusive: okay, okay, I think that makes sense.

A

I'm fine with that. I don't, I don't think, there's anything wrong with that happening.

A

It feels like it.

I

Doesn't need to be, but if it's easier to do it that way, fine, you know what I mean. I think, if name spaces is gonna support that wildcard character, then it definitely has to be mutually exclusive. But if it's only names then I I could see it working with both but.

A

Yeah, you can't.

I

Have wild card and.

A

Have all that other crap, so we're looking like something like this, I.

I

I'd say I'd say we should run with mutual exclusive for now and, like you know, think more about whether they can be together but, like, I think, that's a reasonable starting point.

A

Yeah, I think it's I think it's I think we should just I don't think, there's any there's no value in supporting both together, because there's no way to clearly define what the hell exclusive exclude name spaces is applying inside.

G

So do we still explore the path of uh like having this single type with the namespace selector and try to have match names with as part of match labels do? Are we still gonna explore that to see whether it's technically feasible?

G

I think that would be the best.

I

I agree: that's like zang's suggestion with match. Names is like the most elegant solution. We just have to explore if it's actually a breaking change and I I think it's worth. I think it's worthwhile to do. I'm thinking about the exclude.

B

Namespaces also excluding the matches from labels and.

I

Not only from names.

B

I don't know if you have discussed about that because, like it makes sense if I want to match any namespace with a sort of label, but I know that one specifically, I don't want to match so I will exclude that name space by name.

A

Sorry, I'm gonna. I want to make sure I get the schema down for zayn's.

A

Before three minutes um yeah, we got it again.

E

A

No, but what was it again? Zayn you want to type it in here. I forgot.

H

uh Yeah I I can't I can try to type there.

B

And reward me, I've made you make the document for today and you're not going to pass through it today. Sorry.

I

Yeah no worries.

B

You lost your pto.

I

Doing that sorry, no, no! I um we can, we can do it offline or we can do it next week. It's not a big deal. Yeah.

A

Show people where is it so andrew did some did some pto work for us. So thank you. Let's see what is it or I guess we shouldn't encourage that, but anyways I don't know where is it.

I

Yeah, let's just wrap up the namespace selector discussion so that we have. We know what the next steps are and we can just. We can go over that one next week or we can do it offline, like people just review yeah, basically just.

A

Fyi is here so if anyone wants to look at it, he's kind of, went and clarified the ones that we were actually talking about into some sustained paragraphs, which is really cool. Okay, um I think this is it. It means five o'clock, so I think saying if you've got that in there, I can noodle around with how we might be able to implement that.

H

Yeah, I think I already put it here and take a look to see if I'm missing something.

A

If there's a way to yeah.

B

All right, one last thing, andrew: if you can team or or maybe casey, I think.

C

B

Answered you better than me to ask them for this like channel, because they think that we can. We can arrange this as a synchronous in slack.

A

B

A

Bring it up in sig network on thursday, it's this thursday right.

F

Yeah, I did but got no answer.

B

So I'm going to to send you the the pr and if you can ping, team or or anyone else, because I think that they probably they got a lot of things to do. Also so or we can move that to see cloud provider because android is a sickly there and he can approve to us. No.

F

I don't do that.

B

Okay, folks, so I think this is it for now and we are going to make this the review of these dogs. This doc has the first thing in the next meeting andrea's documents. So thank you all and have a nice week all right. Everybody thanks! You.

A