Kubernetes SIG Network, 29 Mar 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Network Policy API Bi-Weekly Meeting 20210329

Description

Network Policy API Bi-Weekly Meeting 20210329

A

Great so hello, everyone, uh this is sig network api network policy. Sub project today is march 29th 2021.. I just want to remind everyone that this is an official community meeting and we're recording here so don't say anything inappropriate. Please we have a code of conduct which is basically just be nice to each other. So let's follow that and have a good day, so we can go ahead and dive in there's not much on the agenda. For today. uh I don't see any new faces and it's pretty slim pickings today.

A

So the one thing for issue triage was, it seems, like uh ricardo and jay already went over and triaged everything for this week. So nothing really new. To note there. We were discussing briefly the possibility of adding a network policy label. So that's something I can look into doing this week. I don't know how to do it but can figure it out. I think that'd be good and easier for us to look up uh relevant issues in the kubernetes setup um there.

A

uh Next on the list is the network policy. I o event tomorrow. uh Ricardo just told me about that looks pretty cool, just um a place for it's, basically, a new resource for the kubernetes community to talk about network policy so pretty relevant to what's going on with us, and I assume if we want to bring up some stirrings about v2, that might be a good place to do it and get some more voices heard there.

A

um So I know I'm going to try to make it give that a look and then basically, if no one else says anything they want to talk about before. I think we can just continue. The discussion on v2. uh Maybe talk a little bit about next steps and uh what we want to do there.

B

Right so I think um last week I think satish and I we decided, we said we're gonna, um get it back to you guys this week about like an outcome, commitment and I think uh uh we had like. uh Unfortunately, we had like a day off uh on friday last week, uh global day off at google, so we we, we usually have our open source meeting on those days, and I was just trying to sync up with tim and others to like. You know, see what so I so.

B

The update is that we haven't had a chance to discuss it with other open source members in google to see like what the perspective was going to look like, but we are so.

B

I manage the group in google, which is responsible for network security and policy, not only for kubernetes level, but also for the gc firewall levels, gta 5, volt rules, and things like that. So with that said, we have a lot of interest and we have we are we. We will also be working with the vmware team, also in coming up with the cluster network policy that uh that happened in the past.

B

So we're happy to work on it, but just I just need to check with my peers to see that there is an interest working uh from. I just need to coordinate my other case. That's also. If you can give me one more week, I should have a more definitive answer, but you can put satish and me as that people who will try to coordinate the v2 proposal and I'm looking for anybody else who wants to join with us.

B

Then we can schedule like a 30 minute, sync up every week or every other week, so that we can make progress independent of this meeting, so you can set up those logistics once I get back next week.

C

I was, I was thinking you know if it's good for you, we can probably use this meeting to do that because, like this.

A

C

And then this zoom, and also with with google folks and instead doing every other week so because I guess we are hitting our wall here- that we are not going to evolve too much more. We, I think great specification right so.

B

So that that's okay in that case, that will save us one more uh meeting in the week. So, let's maybe what we can do- that we can spend the first 30 minutes or the last 30 minutes of this weekly meeting just to discuss about me to proposal and then use the other 30 minutes for, like you know, doing the regular business stuff like you're, taking care of triaging issues and bugs, and things like that. Does that make sense.

A

Definitely, I think, that's a good idea. um Okay and there's definitely some interest on red, hat's side of things. uh I I will definitely be able to help out a bit um so feel free to include me well.

B

I mean now I'm assuming it is going to be collaborative with all the folks and who are involved in the network policy. It's just like an as I think, jay was saying. Last meeting you need somebody to like, you know, play the quarterback like you know, we need somebody to you, know, organize meetings and have their proposals so uh satish and I are gonna most likely will take up that role and so just need one more week to let you know confirm.

A

Yeah, that's fine with me. um This sounds great. Does anyone have any questions so far? I think everyone that yeah everyone was here last week. So brief recap: we've kind of hit a stop point in the evolution of network policy with the api, as is so we've been talking about doing a network policy v2, um and that is what this is all in relation to.

A

So I think then, for today I mean last week we discussed a little bit about the possible. You know scope of v2, um but it seems like everyone's still kind of in like a holding pattern. We could go over uh some more questions with v2 or start discussing or even start a document on it. If that would help you veneer, I don't know if you want to sure yeah. I.

B

Think we can we can. That is not a big deal. We can start the document. I think what would be useful is to like you know, get some guiding principles agreed upon right. You know, so I think we all have uh some idea on what this v2 proposal is going to look like or what it's supposed to achieve. So I was thinking. Maybe we can use since everybody's here.

B

Maybe we can use this to like not come up with, like a three page, long guiding principle like just like a half a page of one page guiding principles like things like you shall not break the previous version right. You know if you use v2 if somebody uses like you know, the interoperability should just kind of think that you can just lay down. You know like it's like a guiding principles for v2. Then we can use that as a framework for what our proposal will come up.

A

Yeah for sure, let's start talking about some of those, and I can just record them in the agenda.

B

Are you now, can you can you present the doc? If you don't mind.

C

Maybe I would, I would think that we can. We can probably.

B

Yeah, including.

C

The agenda is what what yang questioned last week about what? What are we trying to solve here? Exactly like jay jay have some issue, and I agree with him with the with the hidden defaults right like you, don't allow, or you don't deny, so you don't know what the network policies they are doing.

C

The other pro that we are trying to solve is the expansion like of the network policy right. We want to add some new features and we keep hitting problems. So I guess this is a good, a good point, starting point for for us right.

A

Yeah, I guess analyzing some of the pain points. I know we've been discussing them, but I don't think it hurts just to throw them down while we're all.

A

A

So obviously we don't want there to be a breaking change um we want to be. I think we want to be a little more explicit in the behavior another. You know good route, I think I was talking to. I was actually talking to dan winship last week and and he his opinion from someone I guess, who's pretty experienced with network policy is like network policy. If you want is broken like there's a lot of weird corner cases, there's behavior, that's not explicit um and he thinks network fault. This is kind of a different view.

A

He thinks network policy should be able to be applied. You know at an application level and then an infrastructure level. So you almost have. This is totally different, obviously from the current spec, but you have policy that can be applied like by administrators and then policy that can be applied by developers, and you know that would involve he's his argument. Is it wouldn't be a breaking change because it would be a totally new thing, so I guess that's just something else we could throw in there.

A

You know the argument against a v2 for a totally new policy. Exactly.

B

A

B

Yeah, that's what I meant by saying like having guiding principles, because, or else if you elected our own devices like we'll, come up with our own set of guiding principles which may not be like beneficial for a larger discussion. Right.

A

A

So no, I agree so I guess for v2 guiding principles, backwards, compatibility, uh I.e. The feature set needs to just expand shouldn't contract.

A

B

So so so what we're saying is like you know, if you have a v2 controller and you supply a v1 crd, it should work smoothly.

D

B

A

No 100 and I.

E

Think that's kind.

A

Of the biggest thing we'd have to emphasize to the net sig network team as a whole, I mean that's going to be everyone's first concern like.

B

Okay right and then.

B

If you use a crd, which is defined with v2 constructs but you're using a d1 controller, uh can we also capture that the guiding principle? Second, for example the exact opposite of this right? So you know yeah, maybe add it as like. A higher level bullet item right and this is this- is taking care backward. But what we're saying is that if I'm using a v1 controller but the the user has accidentally, the user is using a v2 construct. In that case, do we want to like fail smoothly or like what right.

A

I mean, I think, obviously I think we would want to fail smoothly, but there might want to be some sort of message that just says: okay, uh v2 controller, being com, existing feature set being converted or something saying that, like right, yeah.

B

I mean we had the discussion and I think last week we talked about like if you use fail open. Are we, like you know, potentially, like you know, making the cluster a little less secure? Because if you fail, um let's say I have a v1 controller and I use a v2 crv.

B

Let's say: there's some terms that are used to define this network policy and it and v1 controller doesn't know what to do so. If you fail open, we are compromising the security rights as a result.

B

It is for us to say if that happens, if the v1 controller sees a v2 just barf straight away and fellow fail fast quickly instead of like you know, try to do some fail, open thing and then open some security uh host. So that was the thing I think we, I remember, we discussed a little bit at length in last meeting, so maybe we should try to, like you know, get consensus.

B

I'm again, I'm I'm okay with either approach, but I think maybe if we just fail fast, if you have a v1 controller and csv just here, he says I don't know, I'm going to mess it up, so I'm going to fail fast. So it just give the signal to the user right away instead of like try to do something clever on the on the back end and then end up, like you know, opening up holes so that so these are the two viewpoints I lean more towards like failing fast, but again, I'm open to discussion.

A

Yeah, you know it's it's it's a really. It's a tough part right, because, if you're failing, if you're failing close and we've kind of changed the api enough, that people are having to relearn network policy that might hiss people off. But if we're failing open, it's going to be way more complicated on the implementation side of things and there's definitely room for you know more room for security holes. I I think in general, we need to lean with network policy towards being more explicit.

A

You know I mean we need to define behavior and that that's the only behavior that the cluster is experiencing so that there aren't any holes. So I mean I would lean fail close as well.

A

um Just in this case I don't know.

B

Anybody have any suggestions, so this you have any uh comments on this.

D

So I think uh the second case right v2, crd working with v1. I think it's it's more or less a very common scenario. Right I mean because we introduce the crd, like let's say in 122, but the implementers are not ready uh or are not supporting v2 yet so I think it's a very common use case, so we need to figure out whether we want to do fail closed. uh Like I mean we need to figure out.

B

D

B

So we are asking you to vote, I mean, like you know. Basically, like you know what is your uh so we know that like two that feel open or I cannot fail first, I think so so yeah, so both uh I'm thinking and like the host is also thinking that you should kill close. So what is your opinion feel open or pretty close? I think it should be yeah very close, yeah, okay,.

A

D

F

More, I think, about.

A

It it's like, oh sorry, go ahead.

D

Oh sorry yeah, so just to add like when we say fail close, I think uh when they, when the customer phb to crd, we're gonna, say uh we're gonna uh we're gonna block them from creating such is sources. What's that.

A

D

A

What I would think- and you know they at the end of the day they, if they're using a v1 controller, they should only be using v1 crds, I mean, and if, if we're failing close and and they try to use a v crd on a view on controller, it will explicitly say like you're doing something wrong. I mean it's not, and I think that is safer, but that's a really important. You know that's something that we all need to agree on. I think right.

B

No, I I think so normally if it were like anything other than security, then we would have been more relaxed, uh not break the thing and have a fail open model. But I think, since this is this concerns security of the cluster and the parts, I think we want to be more conservative and say: okay, if something happens, that controller doesn't know what this constructs are. I'm going to fail because I'm going to mess it up, so I think, should we all agree on that.

A

Yes, okay, I think so, um and then I mean so with v2 crd on a v1 controller. We agree, fail, close and then v1 crd with a v2 controller. We should definitely not fail. It should work cool, so some other guiding principles. um I I would like to see that any behave, new behavior we define is, like I said before explicit so like we lose the. If you have a policy, that's when there's this hidden deny rule um shown. I don't know what other people think about that.

B

A

So right today, when we have a policy everything's allowed until any policy is applied and then there's a rule applied, but you, the user, defining that doesn't see it and I think it confuses a lot of people or this can.

C

Be something configurable by the cluster admin right. This can be something okay, you can fail open, but you are susceptible to uh cve is due to execute autism but to a security issue. So that's our call.

B

Now I think if I understand ricardo like he, what he's asking is for uh the change of the currently default behavior that we have right. If you have, if your network policy enabled, but you don't define the network policy, then everything is shut down. We are in isolated market, whereas, if you don't have network policy defined defined or like you know, you don't have anything set up, then everything is allowed.

B

I think is that is that what you're saying like you want to change that that behavior.

C

Yeah, I'm I'm actually saying that that this this could be something defined by the cluster admin. If you want some when something fails, that it fell, open or or it failed closes like. If, if you have like it's, I'm I'm trying to think how can this be useful or.

A

C

Is just something like some some some by chatting, but I'm thinking if this can be something like okay, the cluster admin can define this, so this can make like migrations easier and also what's the behavior between v1 and v2 as well.

B

So when you say configurable by cluster admin, so will.

B

Policies uh they're different than cluster admin right the persona for that would be different from the cluster admin, so we need to put it in a separate resource. Yeah.

C

Yeah, because I'm thinking like what what happens, if you use a cni that uses a new, a new selector that it's not like, we, we add a new, a new selector that it's not supported yet by your cni. What yeah!

C

So I I guess this should be a behavior that someone should decide if you want to like what the behavior you want. If you select something that doesn't exist, that it's it's new, but I I I might be.

B

No, I think so I mean that is something the underlying implementation does not have all the the.

B

The hooks needed to support some new constructs that can be defined in b2, then. In that case I would say.

B

It should parsing of that should fail right, meaning, like you know the lord reports, a problem saying that hey the cni are not able to handle that I mean. Why do we want to like you know, I mean again. This is my my friend.

B

Why give if you put too many configuration options like as it is they're very hard to manage that'd, be like 150 options that that users have to know about it instead, here, if you have um a mode that you're trying to run your cni doesn't support it, it fails and you'll see that it's not working, and then you either export metrics or look at the mark and say what.

C

Happened: yeah.

B

And then that will force them to, like you know, not use that stanza and the crd, which is uh triggering this failure in cnn I mean I would I prefer that be explicit and open now what happened now, if you give a knob, I think uh again, I'm perhaps showing my bias, like you know, dealing with like a huge number of customer issues, and I think you know if I give you.

C

You have expertise on that. I have only my cluster so yeah. I agree with you. Probably this yeah, but.

B

Again, I don't want to see. I don't want my opinion just because I expressed to be that no.

C

No, no, I I actually agree when you say that this is probably something else to be configured configured and something else like this. Can this can bring some more complexity to the environment.

C

You, you got my opinion at that point, yeah. So, okay,.

B

Okay, that was easy, yeah.

C

A

No, I mean I, I agree I in in terms of configurability there's. The last thing I want to do is confuse customers anymore. I'll. Tell you that much.

B

Exactly and I'd also used to fiction right checking fiction to using these features. Okay,.

A

B

A

Point with this was that basic thing it's like. It seems really weird to me that the basic rule of policy today is you know: pods are unisolated uh totally isolated until a network policy just points at them. At that point they become isolated like that, should be something that that you know, people or users need to explicitly define. So that's all I kind of meant.

B

No, it was, as I think, as jakarta was saying that it has to be not necessarily by the user, but I think likely by a cluster admin, but if you're doing it by cluster admin. That means the people who are defining the policy should not. So that means that information has to be stored in separate crd.

A

Yeah I mean is that something that should be picked up by. I guess this is a different conversation too by cluster network policy. You know because at some point are you guys the developers touching? You know people creating pot who are creating pods touching cluster scope, network policies, probably not so.

B

Well again, right so trusted network policy is optional right. We're not you're not requiring that all all um that, just because you're using network policy does that mean you have to use trusted network policy that decoupled at that level? So having said that, maybe what we should say what I I like the fact that having the cluster admin to specify would be great. Now, if we specify that in the cluster admin and then let's say the cluster admin cluster network policy, then we need to agree on what the default behavior should be.

B

So, let's, let's so, let's assume that we have is now to say what the default behavior behavior is. You know like isolate by default, isolate all parts by default or not. uh We can. Let's say we have that knob. So then, what is the default? We're going to use.

A

I mean I first if.

B

It's not defined by the.

A

I mean the default period for networking. Kubernetes is just what the spec lays out right. All pods should be.

E

A

With all other pods, I don't think a default behavior of network policy should break that default. You know you have like two layers of defaults right. Why not? Why not? You know have have in the network policy, the user or whoever's making the network policy has to explicitly say. I do not want to allow traffic here, but, except for these things, okay, so.

B

So yeah yang is also on the culture yeah and feel free to step in any time. So again to me, like you know, um if we wanna change the behavior saying that I'm gonna like make it configurable how the cluster admin be able to set uh the default behavior. If no policy is specified, it's like an isolate, then um then we again, we need to figure out where we're going to store that option.

G

One thing I want to say is that I agree that you know the default behavior for pauses shouldn't be changed. Anyways like it should allow every part to talk to each other by default when the cluster is brought up. That's that's the one thing I I would say it's not open for discussion. Otherwise, it's we'll create time.

B

G

No, I think yeah, but um but for for the network policy defaults, um it really depends on how we sort of like want to design the crd for for the v2, because um how you frame that will sort of like uh lead to what the what the semantics is. um I actually wanted to sort of like do some a little bit of um like experiment on my own on the cluster network policy um proposal.

G

I actually wanted to see if we should uh for the default network policies, which is uh like uh underlying um layer for the network policy that creates the cluster admin creates for for the like the the cluster defaults uh in that resource. I actually wanted to see if we can change ingress, egress rules from the front and two keywords um to only two and only from keywords, so that only thing um makes people think. Okay, I'm only allowing this, but the everything else was denied. So.

A

G

The like isolation becomes more explicit. I was trying to propose this and I I received a comment from uh I don't remember it's from andrew or or or something someone else saying you shouldn't do this right, because um there are two or three network policies which can be applied to the same parts and if you say only to, and only from that's a lie, because other network policies can actually add to this role. Addictively and you're not only allowing this, because some other network policies could potentially add new things to to the allow list.

G

So so only to an order from is a lie. Basically and there's no easy way um in the current network policy. uh Sort of like semantics, where you can you can uh hint user about the default isolation behavior very easily and that's, I think, definitely a problem that we need to solve. If we wanted to do a v2.

A

That's a really good point.

A

So, like you know, trying to become more explicit but we're kind of getting shot in the foot, because it's hard to be explicit when policies are overlapping.

A

I don't have an easy. You know. I'd have to think on that. I don't have an easy way forward with that, because that's a hard, hard thing to escape the additive feature of the policy.

A

A

That's a really good point.

G

Yeah, I didn't, I didn't think on that as well until someone sort of like slapped me in the face. With this comment, I was like yeah he's right um so.

A

I mean at some point, though you do have to rely on the intelligence of the user right to know. Okay, I've implemented three network policies in this name space. How are they interacting? Because I mean we provide no mechanism to show how they run.

B

So but at the end of the day we still we own some uh amount of responsibility of making it easier to adopt right. Like so again, that's the reason. I'm like I'm, not a big fan of making our features so complex that you need to, like you know, lead up to like tons of documentation before you can have your first network policy established.

B

So that's the reason, I'm thinking um so again, there's no clear answer for this thing, but so we are saying that are we going to have this or not like the trusts are admin? So where do we stand.

A

I think I think, with this we need to decide is default, deny behavior something that is tunable one and b. I think we've already decided if it is tunable, it's not going to be tunable within network policy. It's going to be tunable, yes, something else. So I.

C

Think that there is something that we should use, we should probably be aware is that v1 is going to keep existing right.

C

So if we decide that the behavior of v2 is different from the behavioral behavior of v1, it's up to the if again to the to the cluster admin to migrate to v2 and the cni's will need to support steel, v1 and v2. So so this this can be probably a behavior of the of the cluster.

B

So in that case yeah, so maybe it says: okay, yeah yeah go finish. It no finish.

C

Yeah yeah, so I was just thinking like I'm, I'm thinking my experience as a user, so when, when you, when you decide to to enable something in google cloud or in amazon that changes the behavior, you got a warning about that. So probably it's it's! uh It's uh it's up to the cni providers to say: okay, do you want your cni provider to be compliant to v1 or complying to v2? So if you change to v2, you are going to have uh uh default deny between the pods.

C

I'm not saying that this is something that we we will not do, but this is like like a a possibility. We are not going to get rid of viewer because it's a stable api. I don't think we can. I am not the expert on the on the api machinery thing, but I guess it's going.

F

To be there it it's not not just it's not going to be evolving, no we'll never get rid of it. I mean people are still using kubernetes. You know, 1.1 exactly all.

A

C

F

So so my point.

C

Is that we we can probably be? We can probably break some things or some assumptions here, but we need to make sure that we warn the user about that and the closer I mean about that.

B

Right now, so the other issue that I have, I guess my concern is like: if you have the the knob that specifies the default behavior, the knob could change the default behavior. The network policy allow all to let you know isolate.

B

If it is sitting in a different policy, then what happens is that from a troubleshooting and debugging perspective or like you know, it also becomes a little harder right like now. You define all your network policies here, but nothing is. Nothing is like you know, you feel, like you know, hey. You have expectation that it should be.

B

Traffic should work because I haven't defined any policies, then, but the way it was defined in the cluster network policy by cluster admin. Everything is like in the not working so now it becomes a friction point for the user. To like understand that, oh I need to go look at it and this becomes a little uh so so I would rather have everything that uh controls the behavior of a crd all within the same cr, without necessarily having to have one bit outside somewhere else, which tells what the default behavior should be.

B

So I think, that's that that is a little bit of a concern for me because, again, from a usability point of view again from a user's friction. This is something that you would like to see if you can find a better way of doing that,.

A

Yeah- and you know the more we- I don't know where the right answer is here, but the the more you go back to it. It it makes making a new resource and saying leave v1 where it is, don't make a v2 instead yeah, I don't know instead make an application network policy and a cluster scope network policy, but for for now I think we have some good points here in terms of guiding principles. uh Can.

F

We think of anything else.

C

Getting getting the hook that of what you said andrew and about your conversation with them windshield, I guess it's, uh it's a pretty important that we define the in the in the constraints.

C

What are we going to touch with this new object if we are going to keep in layer, 3 or not because like we have the expectation of folks from cedium as an example that network policy controls layer, 7 like http, get and http post, and I guess we we could like limit this into having like this resource, is going to deal only with layer, 3 things tcp things and service account being converted to like to the pod ip.

C

In the end of the day, everything is the pod ip and the destination, or no, we are going to dig deeper and say: okay, we are going to deal also with from layer 3 to layer, 7.

B

Right, so what you're saying is, if we have do, we want to keep those two policies separate or do you want to like? Have them uh evolve?

B

I think, if I understand you corrected it, whatever you're saying do you want to like see if there is a path, first of all, to be too intellectually not only healthy, but also.

C

Yeah, if, if we wanna, if we wanna, have like a network policy or if we are going to deal with something broader than network policy, that something like traffic policy.

B

C

Yeah, I guess that's a.

A

Whole other thing.

C

Yeah, if you ask my opinion, I guess dealing with network policy is hard enough for us, and actually this keep this. This will make harder to the cni providers like to to implement this, but I guess we can like we can think of. If someone wants to own the traffic policy thing, the application policy thing has then propose it, then that I know.

B

C

Proposal as well.

B

So so why don't we do this? Why don't we just list it out saying that you know it's like this is where I think you can go investigate, spend more time trying to get feedback from folks like the question is whether it's only l3 l4 or we also want to introduce, is also l7 in scope. Just if you can write that thing down in the notes, because you can follow up on that now. um So one of one other suggestion that I was thinking was, um do you think it makes sense to.

B

Have a survey from our either on slack channel or, like you know, from our users about we give them a specific set of questions. Hey, like you know, do you like the default isolate model?

B

You know ask questions which are very specific and solicit feedback from end customers. Do you think that there is do you think we should try doing that or is it going to be that award.

C

I guess you can do that. I will just be careful about about the amount of feedback that we get versus what we can actually do, because we tried to do that on the beginning of this group and we got a lot of a lot of user stories. But the end, but by the end of the day, like some user stories were just for one or two users and were too hard to implement.

C

But I guess we can. We can make a survey we can. We can take the evidence from tomorrow and ask like some some some marketing from israelites and thomas graf, but asking folks to be like how can I say, not transparent but not not related to what celium does or or what kaliko does, but what they expect the community to do right right. Otherwise, we are going to be, as do be as it to just to, and it's going to be hard for folks like andrea or kaliku to implement that as an example right.

A

Yeah, I agree the too many voices thing is going to become a problem quickly because I mean at first my mind was like: oh, let's go to the total networking, the sig network group and just propose or get questions back, but I I think it's going to be overwhelming. At first.

B

Yeah. Okay, um I mean this is a question that we need to like definitely like, so this is going to be some of the effort that we'll have to uh pull together. So um all right, um I.

A

Think the next thing, too, is like taking some of these gliding principles, putting them in a document and also taking the initial features we want to see and putting them in a document together and starting to think like. Can we apply these principles to these features? You know as we develop like.

A

Is it possible um and then I think, that'll answer all the questions for us there at the end of the day, you know my goal with all this is for a customer or a user to be able to write a network policy without with very little kubernetes experience. They should be able to read the gamel and get it it should. It should be explicit and it should also encompass the new features we want to see right. So can we do that with a v2.

D

So so one of the other things I would consider is, uh I think, uh j j shared a dog, I think uh they've actually historically, the last yeah, so they have actually gone through a lot of bugs and list down some interesting things from users.

D

So you should take note of these two, including v2 or like, or keep in back of our mind like while we decided to, I guess right.

A

Yeah and here's a reference to l7, uh we should. Oh sorry, we, oh glitching. uh We should look at l7 as a coordinate case which likely cannot be solved by this api. I totally agree, I think, on the implementation side of things. Cni providers are just not going to do it. I mean it's a pain in the pain in the butt. um um Here's some good things to think about for sure.

B

So, okay, so, okay, so basically what we're saying is we should look at l7 as a corner case which, which likely cannot be solved by the city. So this comment is basically saying that so I'm not getting a feeling that we should look at l7 or not. What does a corner case mean?

B

A

B

A

A corner, I think he just means here a corner case- is saying uh very few. People use it so that we shouldn't we really shouldn't even address it.

B

A

And I don't think we should.

B

I say: okay, okay, he's saying that, since l7 is something that very few customers usually want. Okay,.

A

But um I guess that's more part of the feature set, so that's almost a totally different conversation. It's like what.

B

Okay, so okay, I'm perfectly fine with that, so we can maybe have a line in the sand. Saying that you will not look at l7 will just say three or four for the time being yeah. I can then the ip addresses imports and we use various kinds of selectors to pick using either using services or service accounts and hard labels to pick those pods. um But I think we can just keep it healthy, we'll be okay with that.

A

Yeah, no, I I totally agree um some other. I hadn't even looked through here yet, but.

A

It's a pretty interesting document. I think this has a lot of this answers. A lot of our questions from you know, they've had we've had this discussion before right before I was here.

A

A lot of us were here, um and it always comes back down to the end of the day like this is going to be really difficult to get everyone on board, but I think before we even bring it to anyone vinay, I think you know you go back to your your group and start talking with them about what they think and then we're writing a document. That's like not too long, not too short that just cuts a line in the sand like this is what we're trying to do.

A

You know here's our defining principles and here's our feature set right, so I think we're mostly getting there.

B

So what I can do is like, if you can um uh so you have, you have you're taking all these minutes. So what will do that? You know satish and I will take that and then I'll put it into like a. um Would you prefer prefer it over like a github or like a doc discussion.

B

The only problem is you put it in the github discussion becomes a little harder to like you know, at least in the initial first few days that the comment resolution takes a little longer.

A

Yeah a document would be easier for me to go and just comment on if you should right.

B

So, let's, let's so, let's do this so we'll! uh If you want to start the document, that's fine, you know, or you can start the dock and just put the salient point in the uh like you clean it up. So we'll use the dock to the point. Where that you know initial comments are going to be fast and furious, so once you start dying down that we can migrate it to get help.

A

Yeah sounds good to me.

B

A

Cool does anyone else have anything to add from this conversation, I'm sure we'll get more voices next week. Actually I think next week is a holiday week for a lot of people um or in europe at least.

A

I have another light super light day, so maybe we'll think about canceling next monday for ricardo, but we can have that discussion on slack, um it's it's it's holiday on year, roll and you're in europe yeah. I guess we don't really have any european we're, not a good at a good european time. Here I didn't even think about that. Yeah we tried uh yeah. I know I tried nobody wanted. Nobody came cool um well, if no one has anything else to add, uh we can go ahead and return 10 minutes uh vinay.

A

If, if you want to just make that document um and then throw it in the channel in our slack channel, I think that'd be the easiest thing uh and hopefully, by next time we meet. We have a little bit tighter thing and jay will be here and we can have a conversation on what's already on the on the paper you know, um but I think this is a really good start and I'm looking forward to it, but anyway I'll go ahead and stop sharing great cool.

A

Well, I hope everyone has a good rest of the week uh good to talk about the day and, uh talking to you again.

E

Thank you, folks have a nice week bye. Thank you.