Kubernetes SIG Network, 12 Apr 2021

Previous Meeting Next Meeting

⏯

youtube image

►

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

Description

Network Policy API Bi-Weekly Meeting for 20210412

A

This is a cncf official meeting, so network policy working groups uh subproject.

A

So please be nice to everybody and let's get started it's april, 12 2018 21.! So okay go for it. Andrew.

B

Okay, cool: um I want to go ahead. I know, there's I think, is there some new people? If there's some new people here feel free to introduce yourself to the group, um no particular order just hop in and say who you are and why you're here.

C

Okay, first time here for me, I'm steve wong work for vmware, I'm uh not new to kubernetes. I've been working on that since about 2016, but I probably know just enough about networking to be dangerous.

C

uh Yet I've been pretty active in the andrea project, just trying to coach them along on building an open source community over there, and I got invited to join this meeting today by jay and matthew. So that's why I'm here.

B

Sweet thank you very much. That's awesome anyone else. Let me give a quick.

B

Intro, okay, cool, no one else will speak up today. um Moving on through the agenda issue triage, I just looked, I didn't see any issues that were pertaining to us. However, I can share my screen. There are, there is oh shoot. I thought I was host, but it won't. Let me share screen I gotta go into this happens to me every week.

B

What do I have to do is share screen ricardo, even though you made me host.

D

I do not know how to use it. Your host permission, jay at ed.

C

Yeah, it looks like you're not host according to the attendees, so.

D

Jay can make him co-host.

A

Okay, I'll make you co-host.

B

A

B

The share screen button, I will, I tried it won't. Let me.

A

No, I can I can. I can make him co-host. I know how to do that. So now I go to a stoichis and I make him co-host there. You go.

B

Cool, oh and now I took over the recording interesting so like I said there isn't really any anything pertaining to us this week in terms of network policy, but there is a new issue open in regarding new positions.

B

Oh wait! That's the wrong one! More rolls yeah! So like more positions within civic network overall, so if anyone's interested, they can check this issue out. It's three two five, eight um they're just looking, basically for a couple couple: new rules in the main sig network group to uh be filled, so I thought I would just point that out.

A

um Oh wow, these are all new are these: like? Did we introduce like 10 new roles to upstream.

B

Looks like we did four one, two, three, four five wow. So people are raising their hands over there already, but I thought I'd point it out. Otherwise,.

B

Nothing really popped out to me for sig network policy. There's, I know, there's still the pr filtering through from ricardo to actually have a network policy label that'll make things a little bit easier for us in triage.

B

Usually we just look at all the sig network issues but yeah cool um and if no one has anyone else, I will gladly pass the mic over to steven vlad and matt to give us a uh overview on sono buoy.

C

uh Vlad couldn't make it to this meeting, so vlad is tech lead of the sona boy project uh in case people on this in this meeting, aren't even familiar with it. Sona boy is an open source, kubernetes compliance test suite, so it's years old and it is used as the de facto and I think, official standard for whether somebody's kubernetes distribution is um is um compliant uh for purposes of claiming that you're a cncf compliant kubernetes distribution um most, but not all kubernetes distributions fall in that category.

C

So I don't know I haven't looked for a couple years, but I believe there were over 30 that passed the conformance suite. So it runs through tests that check out how well implemented the kubernetes api is on. Whatever your distribution is, and if you get a passing grade, then you sort of get qualified for a self-certified badge to say, you're compliant and then there's a lot of plugins and collateral tools for kubernetes that make a statement that they should work with any compliant kubernetes. So um yeah that that's what it's been used for now.

C

If vlad were here, he tell you this because I know this because I talked to him just last week that it was originally created with this mission of just testing kubernetes.

C

But it's had kind of an undocumented plug-in uh interface, where the test suite is really just a pod that runs under kubernetes and that it is possible to run other forms of compliance.

C

So matt developed a network policy test suite, and I saw a demo of it a few months ago and was pretty impressed and it's occurred to me and a few other people that there might be great value in extending this sona boy test suite to go beyond just testing kubernetes itself.

C

You know kubernetes initially was just kubernetes, but they've gone with plug-in architectures, where you know, I think the container runtime the cni uh more recently the storage plug-ins uh they're well in underway to be kicked out of tree and moving to a csi, plug-in architecture and there's a lot of these collateral things with kubernetes. That could call for a compliance test suite and then, if you even wanted to take it a step further, you could go beyond compliance in the sense that some of these plugins have optional features.

C

You know like with c I I'm very familiar with csi and storage more familiar than I am with networking plugins, but their csi has evolved for in kind of the initial releases, just basic functionality and they've. Incrementally added features that first get enabled in a spec document, then in an api, and they first get enabled in cni itself, which in theory is a broad storage plug-in that goes beyond kubernetes.

C

It was architected to also support docker storage and apache mesos, for example, so the spec first goes in csi and then kubernetes has to implement it and then finally, individual storage, plugins of which there are well over 20 implemented themselves and when new features are added like, for example, snapshotting a persistent volume when it's first released very few, if any implemented, and for some of these plugins it might take years before that optional feature is implemented.

C

Maybe some of them will choose never to do it just because they're a plug-in for some form of storage hardware that just isn't capable of supporting the underlying feature. But there would be. The storage sync has been kicking around the idea that there would be great value in putting together a compliance, and you know optional feature tester. That just gives a hey. Is this feature present or not uh kind of thing, and it seems kind of silly for each of these groups to go off and implement their own thing rather than you know.

C

We've got this existing sona boy test suite with a plug-in interface, and it would seem to me that, if I'm an end user, I don't want to deal with a bunch of individual test. Suites that evolve separately, maybe work differently.

C

I'd rather just have one place to go and get it all done and have some kind of a consistent expectation of how these things would work. Log the results- and if you look at sona boy as an example, this thing is useful to a user. Just to see you, you can use it to test that your distribution started out of the gate compliant, but in many cases it's possible to misconfigure them so that they no longer work right. So there are users who use sonaboy just as a daily compliance check.

C

uh You know, maybe they run it once a day, just in case somebody messed something up or did some update that broke something, and this would give them a warning that hey this has happened, and uh so there's an aspect that it can be used by publishers of open source to make a public declaration of their compliance and have a means to prove they're compliant.

C

Then it can be used later by users who might run it at their choice, either one time or really just run it. You know on a scheduled basis, because you know, as your production kubernetes goes on with its life, things could go wrong through an update or a misconfiguration, and if we have this one base that would maybe go beyond kubernetes into networking storage.

C

um We've even kicked around the idea of possibly uh using you know. The extreme end of this might even be to allow application vendors to write their own test compliance suites. You know certain applications. This might be overkill.

C

You know if you look at something I don't know like a web server. You could probably ping the thing to do a test. Even then, it should be easy to write a plug-in, but some of these things, like a clustered database, a consul, cassandra mongodb, typically go out there with multiple nodes behind a load balancer and it I've heard.

C

Many users complain that they wish they had a thing that would police this for a health check, because it seems silly for every user to have to come up with them this on their own and even if the publisher of some kind of open source, I don't know service or app called blah or foo, was to do their own.

C

It would be way better if there was some kind of a consistent framework for hosting these. um Anyway, that's just the background of this idea. We were taking around, I think, matt and jay, and I had talks on slack with vlad and a few other individuals. It's still very early stages, so we haven't fully established whether this is feasible. Although there's strong reasons to believe it is uh matt already did this without sona.

C

Without sona boy, but it just strikes me that having a home for this to live in would be a good place, and we could take this pretty far. You know right now, even though sona boy is like the official cncf standard, I went and looked at the project and it's open source apache license, but it goes back so far.

C

I think that nobody ever bothered to go put this in, like cncf, stan, sandbox or incubator status probably qualifies, but I think if we were gonna today to take this bigger, there's other issues where we really want this to be an open community effort.

C

Therefore, we should put it under the cncf and start hosting community meetings and things, and this thing has kind of just been living along on inertia based on it worked okay before this kind of whole community thing got big and nobody ever went back and took a look, but I think we've got some broader issues we have to take on with it. So anyway, that's my intro.

C

I'm not really prepared at this stage to go into like deep dive architecture diagrams or any of that, because I think this is work that we still have to do so. The the talks we had about putting this together with sono boy, just started like in the last couple of weeks, so real early stages, but I am interested in people's thoughts on you know whether this sounds good, bad or indifferent and anything anybody would like to contribute on things we maybe haven't thought of, but should yeah.

E

Yeah, just um I hacked on this a little bit over the weekend and uh it got a got a plug-in put together for sona bowie cyclonus. So you can run those network policy tests through sonobuoy. It looks like it's pretty straightforward. It doesn't seem to be. You know, any anything that needs to change on either end. So I'm pretty you know, I'm pretty excited about that. So now it's just yeah. I guess it's just sitting there. It's ready to go at least that first step of cyclonus and you know having a plug-in and stuff.

E

um You know if there's any, if there's any more steps that people are excited about. I don't know if I'll be able to do those myself but, like you know, if you want to leverage cyclonus or something to do that, definitely happy to help out or you know, give advice or whatever but yeah. It definitely looks like it'll work.

A

Can you put the link to that in the zoom here? That might be the next step, stephen, it's just. We can test the sony plug-in on andrea calico, make sure it works.

E

C

Okay, let me ask you something: matt. I saw your demo at the andrea community meeting a few weeks ago and I know that it checks out network policy. But what about base functionality of the cmi itself? Is that something that the test suite does or not? Because.

F

C

I I think, if I'm a user, that you know, I realize it's lower level, but that would be of some value potentially.

E

Yeah yeah that'd be cool, but yeah like right now. Cyclonus is 100 network policies that hasn't branched out.

C

Does anybody know of an existing open source test suite that would try to do that like? Is there a test suite for cni compliance at all? Well, we have.

A

You know we have all the sig network tests right. So when you run conformance alone, you get pretty good verification of your cni. You've got as you know, 300 tests there and then, if you extend past, what's in conformance you get, I think I think we've got 150 or something like that. Sig network tests- um and you know, there's five thousand total upstream ginkgo tests that you can trigger through sonoboo.

A

If you want- and I think the thing that we always do in sig network- is we kind of fiddle around with them to get the right filters in place, and so I think what you're suggesting is a extended networking, uh yeah.

C

Well, maybe these are already in sona boy, but it might be nice to call them out. You know into a kind of a network, specialty area or summary, because I know the storage stake is taught. The storage testing for csi is definitely not in there now, but they'd like it to go in there, and uh you know to broaden this out that that would be a, I think, a valuable concept so that the users get a breakdown if they find that their installation isn't compliant.

C

Where do the issues arrive? You know where do they reside? Yeah yeah.

G

Yeah, so my name is sanjeev. I'm new to this group quick thought here. So there's kind of kind of couple of dimensions. Here one is sonoboy for conformance testing, perhaps in context of the end-to-end testing. That's already done right, there's already an end-to-end testing suite right.

G

um Does that incorporate sauna boy as its subset or what's its relation to sono boy.

C

You know, I don't honestly know I I wish vlad was here and but it's a center. I want to.

A

C

You more than I know.

A

So sono bowie, what sonogui does it just bundles the entrance the upstream end to ends so the nice thing that sonically gives you like, like steve mentioned, is it um it runs all the end to end tests in a pod and then inside of that pod? You can you know what I can just you can just jump in and I can show you also. I have a cluster here and I'm actually running sony blue right now.

A

um Let me see here.

C

Yeah, okay, I'll just jump in.

A

um Yeah good, so what we do um and what most people do you all see? My terminal right is, you know typically the way I use sonogui and is you know, you'll do like coop ctl create well you'll. Just do like something like this. So I'll do like you know, sonubui run and what I do is I tell it what ginkgo tests I want it to run right. So, for example, this one networking should check coupeproxy, urls right and so say I want to name run in this name: space s3, let's say right.

A

So um usually I just do this and then well, let's run it in a different name space, because I already ran it a different one in that name space. So let's make a new main space here. Okay, so now there we go now I do coupe ctl get pods dash, n s4, okay, goop ctl logs. Now what I can do is I can go, and I can look at this job dash ns4, and this is running my upstream e2e.

A

So if I just go in here dash cd2e right, I can just see them and I could see the tests running. I could grab the logs now. This is the end-to-end test. Already do all this, so the question is well why you sonaboo? Well, the nice thing is sonaby wraps it all in a pod for you and when the test is done, I can say sonobuoy status, dash, ns4 right and it's complete right so and in a second after sono buoy finishes. uh Bundling those results. It's now passed and I can do sonaboui.

A

um Why is my thing I like lost my terminal connection hold on. Let me get back in here: yeah, okay, cool, oh weird! I can't type in this terminal anymore.

G

So I guess my um I guess the point here is that if, if the sono boy is essentially an umbrella for running end-to-end tests, then we should look at whether the end-to-end tests need additional network tests and so on will automatically quickly automatically pick it up, but it'll also be available to anybody. That's using the end-to-end tests, with or without sonaboy.

A

Yeah exactly yeah, so that's I guess. The point is that yeah, so sonography gives you life cycle around the whole thing and um I think um matt's stuff is not part of upstream e2e. It's it's like a separate project called cyclonus that we just kind of have, and it runs hundreds of gen automatically generated network, false tests as opposed to what we have in upstream, which is 30 or 40 of them.

A

So yeah, um I guess what we're talking about here is, and I don't think it would here's the thing, though right so this is where it gets. Interesting sanjeev is that it might not be the best thing in the world to put 400 network policy tests into upstream k8s, which is why steven's idea uh well, if we integrate this into sonobuoy as a plug-in as a good home, it's kind of a good idea, because we could then have a sonography plug-in that managed these tests um and if we wanted these to, you know.

F

And eventually,.

A

Maybe there could be some kind of a strategy wherein we up landed this stuff upstream or had a you know, there's a lot of ways. We could go with it. So, okay, yeah.

G

um And the other thing is so yeah, that's one sort of thought to think about uh you know and sonoboy versus end-to-end, suites and and what coverage is already there in terms of just network tests as well as network policy tests, um and maybe we can develop a develop an opinion and and share that with sig network uh yeah. Definitely sonubo is a very good project and it's been very popular for a number of years. um It's everybody uses it um the other. The other point was uh network policy tests.

G

G

Is is there with the goal being some kind of compliance that, if, if you've, if you've got a dist, if you've got a cluster, that that claims to support network policy here are the mandatory features it better support, maybe or maybe priority one versus priority two kinds of network policies? Some some of them may support, for example, ingress policies, but not egress, and so on.

G

Is that the goal to sort of develop a metric uh to describe the.

A

Degree of support this goes back to dan winship's cap- hey, hey andrew whatever happened to dan winship's cap about this whole thing of of like sort of uh gradient support. Remember that, like the thing of like having.

B

Micro versions and all that wasn't that related to network policy plus plus there's like a readiness flag. I I'm not really sure I'd have to go, dig it up. I.

D

I've put something there also like a last comment that why we need some some versioning as well, but got no answer.

B

A

um I can go.

B

A

That was an interesting kept because the whole idea that was the whole idea behind it, was so this all this stuff sort of comes together right, which is why I'm glad you kind of brought it to the table, stephen and matt- is that all this stuff comes together, which is that we've got cyclones, which we can give you a very precise definition of what net netpol apis you support. Then you've got this whole thing of um this other thing of like sort of dance cap of supports of micro versioning.

A

So the difference in eyes can have different levels of support and.

C

As an outsider, let me just make a suggestion, because I gather that maybe somebody has already proposed that for policy there might be, I don't know, call them t-shirt, sizes or gold, silver, platinum or something, but looking at what goes on over in the storage plug-ins, it isn't that simplistic where you've got 30-some hardware storage devices with drivers, but some of them just used such a different architecture that there's whole classes of features that they just can't build, because it you know, would defy the laws of physics based on how they built this particular storage.

C

So you need that flexibility where there's maybe a dozen of these features where it truly is an option. They're binary: it's either there it's not, but it's not considered this gradient of having it is better.

C

You know, puts you in a specific class and you're. Only reque you're only allowed to have three different combinat combinatorial permutations. You know. Ultimately, this could be an infinity of different features which some some plug-ins have and some don't, and even if that's not the case now you should architect it. So you could support it. If you need to go there yeah, I think this is story. Three.

A

Here right understand whether new features are supported, so it's the combination of I think.

B

Story, three and- and I think with network policy too, like it's at least for now, it's it's. It would be good to have. I know it's somewhat rigid, but it wouldn't be the worst thing to have gates where, if someone wants to use kubernetes- and they have no idea what cni they want to use, but they want to look at a features they want to use. Look at based on feature sets like this is a pretty important feature set.

A

Yeah, what was your githubs check out? What are you s wang? Is it that's wrong with your github stuff.

C

Oh mine, it's can't be wrong.

C

A

It can't be okay, I I just see seed you on that, so we should yeah. We should think.

C

A

C

And, and also you know, it's it's potentially a little pejorative to classify these as, like. You know, platinum, gold, silver, because there's valid reasons why certain things don't implement every feature in storage. It relates to price, where you know it's valid: to have a low cost storage that doesn't implement every feature with kubernetes itself.

C

I happen to be tech, lead of the kubernetes iot edge working group and when you try to take kubernetes out to edge where you have low resources in compute, you know you've got things like k3s and micro cades they intentionally leave stuff out because they want to run it on raspberry, pi's and intel nooks and I'd. Imagine that there might be some sort of a case for a low featured cni by design just because it's lighter weight.

C

I don't know if there is such a thing, but it you know we we definitely don't want to preclude it and by putting this label that one's not better, rather than just taking a step back and say: look you have this feature or not, but it's we're not going to consider it a low quality implementation. Just because you don't have this feature it, it may well be a conscious choice and that some class of users actually prefer. You know, because there are trade-offs for where you save resource by leaving out this feature.

B

Yeah, 100 and- and I don't think that's what it should ever be- is like a gold, a ranking it's more just like these are these options. These are what they support on the network policy side, but um yeah. I think it's a really cool idea and also in this cap j is like the thing I knew about. What I was talking about is a basically a status for network policy.

B

So, right now, when you, when you implement a network policy, the cni sees that and then it takes, however, long to actually implement that policy, so that status flag would just allow the cni to come back and say: okay, the policy's implemented and ready to go. So I guess that's the status part of it. I guess you kind of bundled that together, um but it could be useful for us in a couple other things as well.

C

Another thing that might be useful- and I don't know if this is already built into sona boy- that you know of jay, but in a lot of cases. Some of these things are feature gated. You know by throwing alpha beta flags and things, but there might be some value in having an option to run the test case in all these different versions.

C

But I just don't know that you have to whether you have to opt in when you, you know pick a cni for kubernetes, whether those typically are feature gated and if they are, whether you only get one shot at making your choice or whether you can flip that to take multiple test runs.

A

Yeah, when you add a new api, what happens to feature gate ricardo if we added your port range, it's it's a feature gate, it's feature-gated yeah. So it's so that the api server won't accept it. If the feature date is alpha, I think.

D

Yeah, I guess it, it drops the field. I I can't remember. I need to check the code, but I guess it dropped the fields if the feature gate is disabled or yeah, it's not used in the validation it's used on in prepare for, create and prepare for update. So it's it's dropped. Yeah yeah.

C

H

C

Results that would be a nice embellishment to say, hey. We didn't even bother testing this because of the feature gate setting or whatever, so that you don't get false positives or negatives when you wouldn't even expect the thing to be engaged just kind of brainstorming here on trying to you know, do this the best way we can.

B

For sure sweet well, thanks for all that work um and matthew feel free to keep posting about it. So I know you said you, you already made a plug-in for sono boy um if you could just throw that on the agenda or yeah on the agenda, the link to it unless it's just built into the cyclonus link, um sure yeah, that wouldn't hurt to throw up there and take a look at it, um but I think it brings up some good points that we should keep revisiting.

B

I mean ci is something and testing is something we should constantly be thinking about. So.

A

Yeah, I'm happy to help test this stephen. If you want me and steven work together, so stephen, if you want to just ping me tomorrow, I'm happy to like hack on that uh plug-in and see if it works for us on some of our internal clusters. Just let me know: okay, um I'm down to that yeah.

B

Cool great, thank you guys. um So, let's keep moving on. I just thought: it'd be good to we've been having a lot of discussions in the past couple weeks about v2, um and you know looking into stuff like that, but I noticed abhishek posted a pr for the cluster scope network policy and I think a lot of stuff they're gonna end up doing for that. New object is going to be what v2 ends up following following.

B

So I thought it would be a good chance to kind of get an update on that from abhishek, real, quick and then maybe talk about some of the main comments that we got from sweet network.

B

If you want to just kind of take that over, I wish I could just give us a status on how you think that's going and what we need to be doing.

I

Yeah guys yeah, I I see young and satish also on the call, so maybe you guys can feel free to interject uh whenever you uh want to. um Essentially uh you know, we, we hold a separate cluster network policy, focus meeting every thursday and you know just to make sure that we are all on the same page and continue the work, uh and you know make sure that the kepler is progressing.

I

We, we invited thomas graph from psyllium and.

F

I

From calico and antonian from uh in korea to talk about, uh you know get some perspective from different cni's, because these are the cni providers who have network policy crds which extend the extends to kubernetes network policies. So we got a lot of good feedback from all of them, and we've incorporated that. So at the at the moment, I would say that the majority of the or the or the the main comments to resolve or address would be. First of all. Where do these crds live?

I

And I guess there is leaning towards us opening up a new repository under kubernetes sig, uh similar to the gateway api. uh How those folks have are evolving those gateway, api crds in a separate repository instead of you, know, directly merging them in in the networking group.

I

So so that is what I guess we will also be heading towards, and I think it makes more sense to have a more generic uh repository instead of a cluster network policy focused uh one because uh you know, since we are talking about v2 network policy, which will be an object in itself and nothing related to the existing v1 policy. So so it makes more sense to have a generic repository, so maybe we can kickstart that discussion. I I just left a comment this morning.

I

So so perhaps you know we can move in that direction. So that was one of the uh major you know comments uh the other couple of them are, you know, I think it's more towards. um uh You know how how to handle. uh You know the defaulting of policy or rules for the cluster versus the strict rules. So uh you know some people are against the 2cid approach.

I

Some people are for the 2crd approach, so you know this is where we are getting more feedback and you want to see what makes sense for the users is too many kinds. A lot of you know new things for them to learn, or they are okay or users will be okay with two separate crds, whose job is to do define policies uh for different use cases. So so those are the kind of feedback that we are still trying to receive from the community and at the moment we still have it as 2cid approach.

I

But we welcome feedback from this group, and you know anyone.

J

I

Users who who are interested in cluster scope policies, I think it would be great if they can uh come and uh review the cap.

I

I think, apart from that, there are a few other uh technical aspects that we want to hash out, um so I'm perhaps young and suspicious. I have more to talk about because you know I'm on a I'm an opportunity, so I'm not following it as much as you know, these two guys are so they're. Definitely on top of everything.

G

uh Hey abhishek, um so um are you saying that, in this kept for cluster network policy, there are several comments that apply to what you would call english policy v2 and not directly cluster network policy? I feel like the boundary between cluster network policy and policy. V2 gets blurred.

I

Not really the the reason why I brought up about network policy v2 is that you know these. These are new resources, and what we want to do is that these resources need a place to live and a great api group to which they will be bound.

I

So network policy v1 is under the networking, skates api group right and and and since we are introducing new crds, our question to the community was that whether we want to write these new crds or new resources as alpha resources under this api group, or should we create a separate repository where you know we evolve faster and then mature, faster and and once they're all well matured? Then we merge them in in the networking api group.

I

This is the approach that is chosen by the service api folks, if you notice they have a gateway, api repository and where they're evolving new, you know ingress v2 apis there, so so we're kind of trying to file follow the same same approach.

B

Yeah- and I think that that was kind of the main thing coming into today- um that us as a group would have a hand in right. I mean, if you guys, as cluster scope number policy folks decide that uh the crd option is the way to go um hey. It would allow you to get your work out there faster, be I mean I think it would be easier to iterate in the first five months.

B

If you know you got it, you got to see crds up there, people started using them implementing them, and then you realized. Oh, this isn't going to work for x number of reasons, but I think it's also important, because v2 or an extension of of functionality for network policy is going to follow the same track, as you guys end up doing like you're setting the precedent so.

I

Yeah, I agree because you know because the v2 is gaining traction, so it's it makes sense for us to evolve these new.

K

I

In a separate repository so that we are a little more, we evolve a little more faster than uh than otherwise we would.

I

But, but I I this, this is a topic I think we haven't yet covered in our thursday meeting, or at least we haven't gained consensus. So I don't know whether young and satish have other opinions on this.

F

Yeah, I kind of agree with uh abhishek. I think I'm to have like a separate repository uh like where we can actually uh have like all the different proposals. Like I mean once uh like, once we have like the kept approved, we can actually have an intermediate repository that has uh all the to be matured apis. I think yeah that that kind of makes sense, but I don't know like if young and govind have like different opinions, probably like uh then we haven't discussed last week.

F

So probably we can discuss this week to figure out there's a different opinion as such.

B

Cool and yeah some precursor knowledge here. I think the main problem was antonio asked like how can you add a v1 alpha one to the networking api group, because v1 alpha one's already been deprecated in the networking api group and that's kind of what led to here ricardo I saw you did have a you had a comment basically saying this shouldn't be a problem. I don't really know.

D

Yeah after after I spoke with antonio on slack, he pointed me some some real real problems that might might happen.

D

So, if you take a look only to the code, it should not be a problem, but, as you have like things that point to the to to the api like what was that, like, like a client go, I guess or some some somehow like when you do vendoring you do rendering, based on the api version, not only on the api, so it would be like networking v1 alpha one again and then the networking v1 it might generate some conflict so yeah. I.

D

I was wrong into that comment. Okay, cool, no worries. I.

B

Guess I was wrong, I think no.

D

One actually did that test right, no, not not even like dan or our team or or jordan legit. So we are waiting someone to make that test. Otherwise, I think we should probably bring this again and say: okay, who is going to who is going to to to to own this team? Can you deal with with jordan? Egypt? Do you think we should actually just go to v2 and okay, let's go to v2 yeah.

D

B

Mean I think, there's a merit to both approaches and obviously you know the the details of cluster network policy. We can leave to. You know commenting on the kep if you have opinions and stuff, but I think when it comes to how it's going to be delivered, it's really important for us to decide like how are we going to do this and who's going to support it right? So these crds that if we did make up a repo kind of like the gateway api, it's essentially in my mind. It's it's provided, but not fully supported.

B

Crds right, I mean they're, not part of the official api but they're in the kubernetes organization. You know for people to use um and it might help. You know that problem stephen talked about earlier, where we have a new feature coming in cluster scope, network policy or new features or network policy v2 to ease the implementation.

B

You know bottleneck by cni's right rather than by the time we get. These features into a main api there's only one or like no cni's supporting it. Hopefully, by the time we actually went from like a crd level to api level, we'd have more than a handful of cni's supporting it. So I don't know yeah.

I

And I think we also need the different cni providers who provide network policy to be on board with that, because you know they they need to be, and at the end of the day they are the ones who are going to be realizing uh these apis. uh So as long as they are on board- and I I'm sure I mean I can speak from entry community- we will be supporting whatever is decided upstream uh and I believe teleco and salim are also on board with it and so so yeah.

I

I think the next steps would be to figure out figure out. How do we move this conversation ahead about getting a repo? And you know setting this up? There are going to be a few things that we need to do, uh including, I think I saw the gateway apis. They have a website of their own with you know, extensive documentation of those apis and then examples- and you know, along with the api type so so, and also the validation code. So those are the things that I think we need to hash out a bit.

I

How do we begin, especially? uh You know the gateway apis. They're all core related uh uh apis that they're introducing. So it's like a single goal, but here we have like multiple concurrent proposals that are coming through: v2 will have its own, like uh lifespan, uh the customer policies will have their own evolution. So we need to coordinate a little better and you know probably have a have a thought to approach for this.

B

Right, no, I agree and that work you know the work of this repo. Putting it together and stuff is. Is this whole team like we all need to take that on? um I guess, then I I guess we can talk to some gateway api folks and ask how they went about doing it. I don't know the workflow off the top of my head, jay ricardo to like getting a a new repo set up for something like this or how we would even get started.

I

I think jay and jay and ricardo. I guess you guys recently did one for keep proxy, so it probably should be on similar lines.

G

uh Another thing is that I've actually been in a part of a group where we did this in a totally different group, so you have to essentially put together a proposal for your parent group, so in this case it's sig network um so put together a proposal like unless it has changed recently in which you make the proposal that you want to have a new repo for essentially everything to do with network policy.

G

Futures and one of those is cluster network policy, and there could be others, and this could be just multiple crds within the same repo. And then your parent group would bless it and you would get space allocated for your repo and then you could call it. You know: network policy, v2 or network policy.

G

You know you could come up with a different name or whatever, and- and your proposal would need to- you know, cover things like: is it backward compatible with network policy? V1? Is it? Can it coexist like all of those things that your parent group would need to know, and then they will grant you the space in their allocated.

G

Because it because this would need to be under kubernetes six and our parent sig is sick network.

I

Try to agree, I think you make valid points. So maybe um you know, I guess, uh as part of the team, I think maybe satish young you guys can probably sync up with jay and others on the group here uh to figure out the next steps on. How do we get the people.

A

Me and ricardo got so bored of of trying to figure out how to get a get out repo that we just made our own github org to put a bunch now. But.

D

As soon as we justify it, it's uh it's a doable because, as we are saying that we are trying to make the approach of crds and and developing the crds, we can do the same approach as kaping right kabing is running on on kubernetes sigs, kubernetes seeds, or they they have.

D

The bar is lower for the requirements like approvers or being member or something so if you think it would help you just just. Let me know I can. I am pretty. I am pretty free this week, so I can run run and and make this happen. Ask team, hawking and casey david park authorization to create that ripple. It's a it's really doable.

I

Yeah, I think for justification. I guess we can just show them the comments on the cluster network policy. You probably the the thread that you know. This is what we can.

D

Say that we are, we are getting sorry, go ahead.

I

D

Good, we can say that we are getting the same approaches as gateway apis and and say: okay, we need somewhere that that we can work and the community can follow, but that's not as official as the kubernetes repo, but that's not an unofficial as like junit jun800, slash, slash network policy, v2 right.

G

um I think you would might be want to put together like again like three or four slides to present to sig network at their next meeting and say: here's the proposal. Here's the caps that already exist here are the comments. So your your formal proposal to sig network- and let me know if this is overkill, so I don't want to make it overkill. But this is a process.

G

That's been followed in other groups where you summarize your proposal to your parent in in their next working group meeting with you, know three or four slides that capture all your caps, relevant caps and prototypes, and so on, and or maybe that's already been done because I'm new. So I apologize if I'm speaking about something that you guys have already explored.

D

Yeah, I guess I guess folks already did that with cluster api. Sorry with the cluster scoped network policy, so the sponsorship for that is going to be, I hope, easy, usually when I say that something is going to be easy. It's hard like I can spend something like a month or two trying, but I I think it's a it's something that we can do and also say. Okay, we are going to put everything here: the crds and also the slides and documentations.

D

It's not it's not going to be hard. I guess I hope yeah, sorry. If it is it's my fault.

D

Just just just remember me tomorrow. If you want to move andrew, if you want to move, I can I can help you. Maybe andrea can open the the pr because, like I am pretty noisy in the community, so okay andrew is new, don't beat him.

B

Don't be I'm more than I'm more than happy to help out too.

G

B

Just I want to see this move forward uh so feel free to ping me on slack about it and we can move forward.

A

So the proposal here is a single repo for crds.

B

Yeah, but we need to make it fancier than that right. We need to make proposals fancier than that kind of like what sanji said.

B

I think I'd like to write- or I guess well now- I'm volunteering myself I'd like to see something written up. You know that says: here's here's where we're at with network policy, here's why we need this new repo. This is kind of the way sig network has already instructed us to move forward um and here's our actual proposal to do so and gateway api has already done it just to clarify.

B

We are talking about the cluster scope of network policy, right, not the network policy v2 yet or right, but this repo that's coming up is probably it is, I would say, going to house both at the end of this okay.

D

Okay, we can. We can use that as like cluster scoped network policy, just like to do not generate too much too much questions of. What actually are we trying to do that and say? Okay, we are extending the scope of this repo to network policy v2 because we are using the lessons learned in clusters copy network policy. To this thing I guess it would, it will make things easier. It's my opinion.

A

I would start with something I may be in the minority here, but I I would start with something that you owned yourself and then transition it later. I don't really see much point, even though ricardo is very generous, running around and finding stuff like and getting people to make it up. Replays, I'm like I, I just I'd, get something useful into a personal, github, repo or or you know something like that and then and then kind of be like all right.

A

I want to transfer this over just because why block yourself on having an official repo, you know like.

I

A

I

I think it's it's not it's not about uh where we want to or whether you want us. You know whether this is hindering our uh progress in terms of writing those apis in you know in the structs and placing it somewhere. I think it's more about uh defining in the cap as to where this will eventually go, and uh you know because uh at the moment uh we you know we, we can't just say that it's going to live in my repo, something something somewhere yeah we just want to. We just want to solidify okay.

I

This is where it will eventually go.

A

I

And we'll find a way, how do we reach there? Okay,.

A

Yeah no go for it. I don't have a strong opinion either way, I'm totally supportive of that. Okay, ricardo, but.

I

I agree when, when you say that you know when we start developing these api types, I think it makes sense. If we don't have the repo by then at least we can start it in a private repo and then or a different repo and then move it once available. Yeah.

B

There's there's no rush, like I'm not saying we talked to sig network this week about it or anything. It's no.

A

It's kind of if it's going to help the cap, let's let's you write abhishek like if it's useful and it's going to help, send the right signals and help the kept move along. Let's do it, you know what I mean like fine, I don't I don't have. I don't think, there's anything wrong with that at all.

A

So ricardo, do you need to present this to sig network before we before you ask for this stuff, or do you want to no.

D

I'm gonna, I'm gonna, I'm gonna just just just remember me tomorrow, because it's a 6 p.m. Here in brazil, I still need some things I will forgot. I will forget for tomorrow, but remember me tomorrow. I I can open the dpr saying: okay, folks, working on cluster scope, network policy. They need a place to put the crds and the documents and, like the the simple controller, you will need to to create those things, but they need somewhere to put everything here.

D

Can can you create this repo and make like abhishek and andrew as the owners or the approvers or something like that and yeah.

A

Yeah, okay cool, so all we got to do is troll ricardo tomorrow and we'll get the repo up.

B

For y'all we'll be in touch.

A

B

I know we're reaching the end of time here, so we can go ahead and finish up. The last thing I had on the agenda uh um still working on. You know a v2 dock, just sort of preliminary. Why? Why are we doing it get some of our thoughts from our last couple. Meetings down on paper should have hopefully have something around that next week, but that's all we have there. Otherwise, I think that's it. Does anyone have anything else? Yeah.

E

I got a I got a quick request: um does anybody have any proposed yaml for cluster network policies or something like that? I just wanted to kind of like start thinking about that stuff in cyclones, potentially.

K

I think there was.

E

K

The it's on the cap, um which is the um I think, andrew just post, post it in the in the chat um I can repost it.

B

Okay, cool and I think, there's some there's at the top of our agenda. There's some slides um and there's some examples in there. I believe too.

K

Slides might be a little bit outdated, okay, yeah.

I

Yeah we will update the slides to ensure that it's reflecting the latest.

E

I

As yang mentioned, the cap is the right place to look at this.

G

All right awesome thanks I'll. Just add that the report, the report will contain more than just cluster network policy, so the name of the report should be more like english policy v2 whatever and cluster network policy is one of the components of english policy v2, because otherwise there'll be three things: there'll be policy, v1 policy, v2 and cluster network. So this should be one repo for policy v2, which includes cluster network policy as one crd and one or more crds for other features, and that all will be in a single repo with a common name.

G

D

Can call it like network policy v2 or like whatever I I can can I can send to you like the vr on on slack and say hey folks, so just the better naming here we just just.

G

Get to appear guys right, they started off, calling it ingress, we do and then they came up. They didn't want to use the v2, because there was all this backward.

F

G

So if anybody has a name that that.

I

I I had suggested on the network policy api. I think that kind of like covers everything equipped policy.

G

But but when you say even the current thing is a network policy api, so maybe it needs a little bit of differentiation. I mean.

I

Or yeah yeah, but at least at least I would say that we should stay away from v2 or cluster network policy or any specific topic right. You can have that.

B

Discussion on the pr tomorrow, maybe.

G

Your net network filtering api or something yeah. I was.

H

Wondering if it's just going to be a long-lived uh repo, that any new project would kind of start out there develop a crd and then.

K

That's also that's a good question. That's also what I was wondering sorry. I was away for a little while, but uh I guess my question will be: is the intent of the repo being it always hosted the new things that we're proposing and once we graduate things to we won. For example, the news king can come back to this repo and uh and the state uh v1 alpha and we want beta there.

K

I don't know if what you guys think on those lines.

G

I think typically, they haven't done that they, the a new kubernetes sig repo, is for a relatively well-defined project like the gateway api is basically usb2 uh gateway. Api will not hold anything other than ingress v2. Logically, so you would want to justify another repo for a something that has nothing to do with network policy. This is generally in the umbrella of network policy, whether it's cluster network policy or network policy we do.

G

But, of course you know if you can sell your parents say you can do anything.

A

G

A

H

It's scoped to network policy. There could be, you know, five more things that we want to do next year, that would they still go in there or yeah. That.

F

B

Under the network policy umbrella yeah, I mean, I think we start. We start with this yeah and we see what we can do just.

H

Come up with a g, I think maybe just come up with a generic name- might be good to keep it safe. Yeah.

B

Well, ricardo's flexible. We can do that all in uh uh comments in that yeah sounds good for me, cool great! Well! Thank you so much everything thanks for coming, I was check. I know you're, on parental leave. I'm sorry about that. I kind of spaced when I message you in the chat, but I really appreciate it um actually.

D

He's thanking you because he can say: okay, I need to solve this. They need me. Okay,.

I

Don't kill my wife he's.

A

Getting bored he's getting bored, he wants to come back exactly.

B

Cool well, thank you, everyone and I look forward to seeing you next week and we'll be in touch tomorrow. Ricardo thanks, bye,.

J

B