Kubernetes SIG Network, 18 Jul 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Network Policy API Meeting for 20230718

Description

Network Policy API Meeting for 20230718

A

Awesome, hello: everyone today is Tuesday July, 18 2023.. This is a meeting of DC Network policy, API subgroup to sync Network. This is a cncf sponsored meeting, so please be kind to each other, use nice language and follow all of their Community guidelines. um Thanks for coming today, we'll go ahead and dive into it. Let me share my screen with the agenda um per usual. The agenda is pretty free-flowing today feel free to add stuff as we go or anything else so before we get started, um I see some new faces.

A

Do we want to get some kind of just introductions and kind of why you're here or what are your? How are you interested in network policy? Maybe from we'll start with um Hunter Gregory? You don't have to either you can say: I got nothing to say.

B

Thanks Andrew yeah um really excited to be here um yeah. This is my first time joining um so I'm from Microsoft I've been working on azure's network policy manager for the past few years, um yeah and I'm excited again well.

A

Awesome, that's really great hunter. um We're excited to have um you know, representatives from various implementations for the longest time it's just kind of been uh Yang from VMware and Surya from oven, kubernetes, so good to have more implementations on board. uh There's a lot to catch up. If you look back to our agenda and look through some of those docs that might kind of help you but we're focusing on the admin, Network policy effort right now so cool cool um and then I might be saying it wrong. How do I say it.

C

Damian Damian perfect thanks Sandra, uh so yeah um I've been involving kubernetes and the cncf ecosystem for uh quite some time um and uh just joining to see kind of what's been going on with network policy uh over the recent months, I've been an active contributor in Sicilian which of course uses Network policies, uh uh their their own network policies, so I'm just trying to kind of see what what the latest is going on with with network policy within the kubernetes community.

A

Awesome happy to have you um again: we actually have a issue to track the implementation of admin. Network policy, which is kind of the API we've been focusing on lately uh in psyllium, so any help we can get there and pressure is is is awesome we and we also want feedback from them. So that's kind of our goal: okay, sweet!

A

um So first things. First, there was an issue that came up in the last Sig Network meeting um around a couple of concerns with network policies. I I, don't know if there's really an action item for us in this group. Yet I'm assigned to this, but uh Tim Hawkins gave his thoughts. So I am kind of just waiting on a response from there to see. If we can help help out.

A

um Essentially they were the security. The audit and security team was unhappy with a lot of the design principles with existing Network policy, some of which we've fixed in admin Network policy, um but it's definitely a good read as we kind of push towards, hopefully designing a network policy V2, so I definitely advise everyone here to give it a quick review. It's kind of interesting.

D

E

uh Andrew quick question: do you think we need to fix anything in A and P at this stage, uh based on their order report for NP.

A

I, don't believe so a lot of it had to do with the lack of it. Some of it at least had to do with the lack of explicit deny, which is obviously something we're providing in admin, Network policy, um and then what was the other thing? It's actually been a week or two since I read it.

E

ah No worries I can I I, it's the first time, I'm seeing it so I can read it. Yeah.

A

I just wanted to highlight it here from my first read: I didn't think there was anything immediately we needed to change for ANP, um but I thought it was kind of interesting that this feedback was coming in I'd, say you know all the way now that Network policies V1 it's funny that the feedback wasn't given before, but anyway and they're testing all the way back on one two, four, so kind of an old kubernetes version, just something to think about.

A

I didn't even know there was a kubernetes security audit report. So that's you know it's all good things. Cross-Pollination is key and I'm sure any policy objects we come up with. We should probably from now on try to get opinions of the kubernetes security team right, like it's very relevant, so.

A

Yeah cool yeah and, if anyone's reading that and wants to comment, feel free to the more voices, the better awesome. So the next thing I wanted to start kind of pushing forward uh were the npaps uh Nadia the past week did a good job of adding some documentation to our repository um for folks who are new.

A

um We have a website for this working group uh and it's just literally Network policyapi.cigs.kate.io and you can find our repo from there when I say the word endpap, um it's essentially a shortened version of a kubernetes enhancement proposal, specifically for the network policy API.

A

We wanted to make it a little less cumbersome for folks to propose new features, and uh you know kind of Quicken, the iteration cycle for a working group and it's modeled closely after the Gateway API who have gaps so um we have some good documentation there and both Surya and Nadia have opened and peps around ANP features in the future. We hope to you know for anyone here if they have some cool new idea for a feature or want to own some new object.

A

That could be a part of network policy API, please open an npap. So diving into it, the first one has been open for a while um from Surya and it's regarding adding support for egress traffic control to uh admin hour policy. I, don't know! If we really need to talk about it too much Surya. Could you give like a quick rundown, just like a tldr for folks on the call about what this nfep is is regarding Syria.

E

Yeah um I can be quick about it. So what so? The first version of enp is supporting only east west traffic. What that means is we only support part depart overlay networking as of now and the goal of this, and that is to try to expand that to also support Northbound. So if those of you who know Network policies, this is the equivalent of the IP block offering that the network policy gives so something similar to that.

E

So that's the one part of the npap and the second part is to to see how we can smoothen the part. The host Network bar communication rights are more like towards the node IPS, which crosses from the overlay to the underlay. So those are the two main items that I'm trying to address in this n-pep and I did have a question for Andrew or maybe Nadia I, feel like the Gateway power. Sequels put their npaps in the website and I didn't see the.

C

Same like Nadia's.

E

Was also like a documentation thing in the repo and I was thinking it should be a part of the website somewhere right and I. Don't know where yeah.

F

They actually do have it as a part of a website. I just didn't edit, yet because it's.

D

Basically, just shows the same information they have in this like Gap or ad Pap folder, and you just need to update site to do that. So I wasn't sure if we want to do that straight away or if we just add it later, if needed,.

A

I say: let's get these two very first baby and peps out of the way, and then we can look at him to the website. But it's a good points area um I'll, try to make an issue for that after this meeting that we don't lose track of it.

E

Yeah sounds good.

D

Yeah, there is just one uh tiny thing that for every and pep update after that, you also need to make sure you update the site sources, because the and perhaps or gaps are grouped by this status. They have and I've seen like quite some PRS that you know will merge some Gap change and then the next follow-up will be over I forgot to update the site uh page sources, to also change that right. So that's why I didn't add it. Here's the way.

D

People also need to add some I, don't know reminder somewhere to make sure we don't forget to do it ourselves.

A

100 um I think we can even add, like a note in a PR template for an n-pep that says, remember to update the website as well, um but for now I think it's all right. I would like to do that in the future. Definitely um so back to your npeps area, I gave it another review. I know Dan's reviewed it um I feel like we're moving towards consensus.

A

So the reason I really wanted to bring this up is is to here if anyone has issues with this n-pep, essentially because we are moving towards a point where I would feel comfortable um merging it. So this is kind of the last shout out to give it a review before next meeting and if there's not any outstanding issues raised against it, we'll go ahead and get our merch sound good.

E

D

I think we wanted to update. We need to update the formats for that and Pap now, because it was created before I did they actually did the template and the dogs for it.

A

Yep you'd be proud of me, sir uh Nadia I added a comment to do.

D

That, oh okay, cool! Thank you.

A

Okay, what else on this one I think the only other main thing I had was and Nadia also had around this cup, and maybe we can kind of chat about it here really quickly, because we don't have anything else on the agenda um was if we were going to Define traffic destined towards a node or a host. Network pod is as kind of the same thing or not I, don't know if you had any thoughts, Surya.

E

I wanted to make it explicit, because that's one of the mistakes we did in the previous in network policy, where we did not have rules for this and it's not well defined so I think we even had like uh I, was actually handling towards making normal pod. Selector select only see an iPods and then have a whole selector. That's explicitly selects only in both pods and make the traffic signal using those selectors foreign.

A

Do you think it'll be difficult for implementations to distinguish between traffic destined for a host Network pod versus a a node I mean they're going to have the same IP most the time right.

E

Yeah, that's true, but I I think oh I feel like we discussed this somewhere. Maybe you've done had a comment on the previous thing. I think Young also had point to resolved.

E

I should go back and check it out of them.

D

Yeah I think we've talked about that that there is uh actually technically there is a way to distinguish host Network pod traffic from the host traffic itself, but probably not too many Network plugins can do that now. So that's a guess, kind of what we ended up with.

E

The 86 one yeah.

B

E

User stories, foreign.

G

You can like have rules that are based on the uh C group of the the the con of the socket, and so you know distinguish different host, Network, pods and host pods or host processes. Based on that. But it's it's not really obvious I mean nobody. Does that.

A

Right and I think that's okay. As long as we have like explicit mechanisms that we can specify that some implementations might not be able to to actually implement so like I, if we added a node selector or even a host Network pod, selector, I guess that would be all right, because we could specify that this may be a feature that not all not all cnis can Implement I'm, not against that.

A

um But then we are going to need to go down the path of exploring you know, experimental Fields, just or adding like an experimental field, just like Gateway API does right.

E

Yeah and make it non uh make it not mandatory for conformance.

E

See if they have at least one or two implementation so implement it, and then, if we don't see any, then we do not graduate it from experimental.

A

Supersede, okay, cool I'm, glad you, you, like you, did the right thing you linked 86 here uh for folks, following along in the recording, are here there's a lot of good conversation in the previous er. uh The reason we open a new one is so um that we could align close more closely with our new endpap format. So, okay.

A

Nadia, do you have any opinions there? I know you were the one who, basically my opinion, is: is I'm all right with doing trying to do both I think it. There is some use cases for doing so, so that makes sense yeah.

D

I think the definition of our API may be a bit different in these cases. So if we say that uh host Network pods are like indistinguishable for us from the host Network traffic, then first of all, it probably only makes sense to use node selectors and not host Network pod selectors, because if you select the host Network pod, you like allow or deny the whole node right and the host Network Port is just a little part of that.

D

So it may not be obvious, and by selecting a host Network pod, you can actually like drop the whole traffic from the node to something like that right and then also in that case, when you do select a node, let's say with the node selector. You also say it will affect all host Network pods traffic hosted on that node right. But then, if in the future, let's say we want to distinguish these cases, maybe you will want to select only Network pods traffic from the node right with the node selector. So these are different things.

D

You will be able to have host Network, pod selectors and the node selector, and then the definition of what node selector actually does will be different in these cases. So that's why I thought it's important to kind of Define it somehow, while we are here so there is, there are no like two ways. You know to do the same thing and then it's also quite obvious of what exactly will happen with the networking when you select something like that.

C

E

So is that the second stage of the n-pep or like or the goal needs to be more well defined around what a node selector is and what a host Network Parts lectures, or does that come inside the API design that I do in the next stage like or.

C

E

This thing, or is it a next stage thing- is.

D

I mean from the API point of view like how we just know the Pod selector is definitely next stage, but here I just found that part that says I want to control traffic from nodes and or closed Network pods right, and it's not obvious if you actually uh want this use case for host Network pods, specifically separately from the nodes right. If we will not be able to actually do that, I thought that maybe useful to Define it here explicitly.

A

Yeah I think maybe maybe even just break if we do want to try this to segment or even in the future segment between traffic does infer node in the host, Network, namespace or trafficked us into a node or sorry in the host C group, the default C group or traffic does into a node um in a in a container C group. Let's break this goal into two and say yeah traffic control towards cluster nodes and then have another one saying: Implement: traffic control towards host Network, pods and Define them as explicitly separate things.

E

Okay, yeah: that makes it more clear. Okay, I understand, though, but.

A

But I agree with you like the API design should definitely be next step. Yeah, let's try to stay high level, at least in the first iteration.

E

I'll break this up.

A

Sweet thank you.

A

I had one other comment there, but we don't have to go over that now.

A

A

Let me get back to here, so the next one is in regards to tenancy uh Yang I know: you've had a you've had a lot of opinions on this one too. So um I started reviewing this today. uh If you could also give it a review, I think we want to figure out kind of how this would work if we need to do something here and what the consensus is um in regards to having a better way to express Hennessy than we do today in admin hour policy, so is.

C

There anything else you want to kind of.

A

Give you do you want to give a short tldr, uh Nadia I know: we've talked about this a lot, so you don't have to keep it long.

D

Yeah so uh first note I know that dogs usually say that we want to copy as much as possible um to the npap itself, but I actually left a link to the dog that actually then made to discuss different options and copied only like the one of them.

D

uh The important part is I've outlined, like two main uh problems with having tenancy defined as a peer of admin, Network policy, it's listed there, and that is basically the reason why I propose to define a new object, which will be yeah, hopefully simpler, to implement and simpler, like to understand what exactly happens when you define this tendency, so yeah.

A

Sweet awesome, thank you for opening that I think it's important um and thanks for linking the existing discussion and that doc she was talking about, is an issue for the npap and it's one. Dan wrote up a while ago: I really like this doc. So if folks are wanting to learn more about our discussion around tenancy with amp, this is a good place to start.

A

Okay, cool and eventually, like I, think we should formalize to kind of keep us honest in the community like a sort of timeline for npeps I. Don't maybe that's a bad idea, but like because I know, surya's has been open for a long time like I. Think it'd be good for us to decide this community within a span of like you know we can.

A

We can come up with what the span is, maybe in the span of like four meetings, where we kind of poke people every time about it and by the end of those four meetings. If we don't get feedback like it's going to move forward or stop right.

H

If it can be helpful, I I'm not I'm, not necessarily directly speaking to what you're saying, but it's kind of related in Gateway API. We have introduced the concept of a probationary period for gaps, although it's only during the experimental phase. This is because gaps that make it too experimental, but then last for say two years become used in production and are no longer experimental, even though they say experimental. So we had at least one really bad situation where that happened and learned from it.

H

So it's not exactly the same as saying we just have a timer on all of our end, peps or whatever, but definitely during the point where people are told to start using a thing, I would recommend some kind of probationary period. Upstream does something similar.

A

Yeah I think that's a good point. We don't even have kind of like the infrastructure set up today for having experimental. You know the different stages that gaps do um in the Gateway API, but it's probably something we're going to need um so Shane. One question for you from Gateway API do fields that maybe are not implementable by every implementation. Do they ever make it out of experimental, or do they what's the name for okay.

H

We call that extended and we.

A

H

That to be at least at least three I think all right, I think yeah I think it's at least three implementations can do it uh we'll call it extended and move it out of experimental.

A

And can extended apply to just Fields within an object or can.

H

They apply to a whole, you can even it can even apply to just values within those fields. So, like we.

B

H

We have like things where, like it's a core field but there's an extended option.

A

Okay, and do you annotate the actual API, with that information like if it's experimental or not, or is that done separately, experimental.

H

Is different, so actually experimental has to do with our release channels, and you can have a like. An experimental thing actually goes with. Our experimental manifests and may include things that are said to be extended, but aren't actually promoted to standard. If that makes sense, so like something, that's extended will go into experimental first and it'll only be available there, and once it's graduated, it's gone through all its testing and we're sure that it's working with conformance with the implementations that can do it, then it'll start showing up in the standard Channel later.

H

But that's separate from being extended extended is like what level of support do we say this is at like can do all implementations need to do this or not, and then the experimental versus it's confusing? It's not.

A

It's confusing, but it's I think it's important because it allows you. It allows you, as a working group to roll out, like maybe some more exciting fields and features in an API without worrying about breaking everyone right and like yeah yeah. That.

H

People should that's what we've not be using the experimental manifest in production. They do and that's fine if they want to, but we say should not for a reason and it's up to them if they want to do that.

A

Okay, I'm gonna start looking into adding that infrastructure for us as well, because I think as we move into beta there might the more m-peps that are open. The more I realize we're we might have some fields or parts of our API that are a little more difficult to implement for a lot of folks. So yeah.

H

And if it's, if it's helpful, I've recently made some updates to the get overview file so under the gapster and Gateway API, which includes, for instance, the probationary period we give like a roughly it says it says, like we pick a probationary period, but we kind of just decided on like six months is kind of going to be the average where, like the idea, is, come up with your graduation criteria.

H

Once you hit experimental, you have to have graduation criteria to make it to standard, and six months is the time period you have to meet that graduation criteria, or else you'll be considered pulled. So the idea here is in the past. We've had people like just jump on experimental use it in production and unfortunately, then it became real.

H

um So this this makes it very clear that that that's on them not on us like if they decide to do that and that we reserve the right and have communicated that we may need to pull the rug out from underneath the feature that can't meet its graduation criteria.

A

D

Hey well, we we are here uh I, just yeah I just wanted to um tell where you can find, like we've added these instructions on how to open and prep right and what statuses we have now, not sure if it's easy to find uh so one way is in this natural policy. Api website we have. There is a reference section that you need to click on and there is enhancement proposal. So that's where you read that and another way to find that place is now we have templates for issues in the repository we have.

D

Then, if you open enhancement proposal, um there will also be a link to this process, saying that you may need to follow it if the enhancement is big enough, yeah, the slash enhancement one, so that also should uh go to the same page. We've just seen, yeah just in case. Anyone would like to actually find that.

A

I was looking for that earlier and I couldn't find it so I'm glad you brought it up.

D

A

Nadia for help with all that, um that's awesome see cool, okay, any other questions with the end peps n-pep process. I think I have some stuff to look at to try to try to make this even better, um but excited that we're getting it rolling.

A

Sweet silence is affirmation in my book. Okay, next thing, I'm gonna, toss it over to Yang and Syria. Whatever order you want to go, first um doesn't have to be long, just really informal and brief for folks who haven't been here. Oven, kubernetes and Andrea I'd say are kind of the far the furthest, along with implementing admin hour policy. So um hopefully we're we'll have like actually complete implementation soon, so I'll toss it over to y'all.

A

Surya you wanna go first yeah.

E

I can go first, so we have been working closely with the Upstream Community for six months now or even over there, um since the Detroit kubecon, which is when I first got involved with amb. So I have this um implementation in progress. uh So it's mostly us working with so it's red hat and Nvidia, who use O, B and K mostly, but it is all open source and Upstream plugin, and so we are um in good shape right now, like with regards to supporting all the fields.

E

There are some fields that we have not implemented yet some of them, so one of them is the same labels and not same labels and the reason why we didn't implement it is because of the tenancy uh npep that Nadia has opened, because we wanted to clarify about that. Field stands for and the other thing that is sort of not in the first iteration of implementation is the named ports, but I do have like a secondary PR where we will bring it in so outside of these two I think pretty much.

E

We implement all the other aspects of the API that we have in Vivan and we are hoping to get this merged as soon as we can and the nice thing about uh this is that if you open like one of this well, we don't have to open the CIA job right now, but we have defined the conformance tests in the network policy API repo.

E

So all the e2e tests live in the Upstream repo, but every cni can just take that and run it Downstream in their specific implementation, and that is already done in this PR, which is pretty cool. So the CIS are all running the e2es that are versioned with the 1.1 release that we have in all the lanes. So it's good that the conformance tests are more Upstream generic and not cni specific. But the next step here is to also do conformance profiles.

E

So since obnk is almost done and Andrea is also almost done, I do plan to open and confirm API because they did this first so that we can then report which of the cni plugins that are implementing a specific API Upstream. So for A and P and B and B, we can say that okay obn care, does it and Trail does it, and we can give some sort of a badge saying whether they're conformant to all the API fields or, if they're conforming to some of them, and not really for everything and stuff like that.

E

So that's where we are at right now, so I hope to make a lot of progress in the next two months on the implementation and Conference profiles in general.

C

A

H

So much it moved yeah. We just moved um conformance profiles into experimental in Gateway API, and we have our first live report coming in shortly.

H

So just wanted to let you know that that's the state of those things and I don't know if it's gonna we're gonna have time before Gateway API GA, which we're hoping to do before Chicago, but I still think it would probably be good if we came together and like kind of made this a more generic library at some point in the next year, um if you guys end up really liking, it.

E

Yeah I think that that is a great idea: Shane, um maybe more projects as more projects become out of pre. This can be of uh Essence right, like I I, see a lot of scope here and I was even thinking that for the contributor Summit, we should make it a bit more wider and maybe do a talk. I, don't know.

H

A

Sweet thanks so much story. That's an awesome update good to hear all the news um Yang. Where are you getting with answer? Have you been able to run some of these conformance tests as well.

I

uh Yeah, it's a little bit more complicated story uh so for for entria um I think the implementation is ready. We have this PR for the implementation, which you know. Obviously pretty much does the same thing. uh We don't support the same label so that same labels, yet but I think we do actually um support the nameport case, uh which I didn't realize that there wasn't one in the conformance testing, which I can probably add to that. But I think we do support the name per case. So that's not a part of the conformance. Now.

I

The problem with running to the conformance testing is that I've tested in a local setup with entry deployed and passes everything. Now.

I

uh The strategy for conformance testing on Nigeria is that we were trying to add a GitHub action so that you know every time you maybe a PR is pushed to the actual repo. We spin up a new kind environment and do the confirm assessing there, but we discovered that you know, because maybe the the test bed will be a little bit slow and there. um um The current conformance testing logic doesn't uh there's a little bit of a glitch that we needed to fix.

I

So it spins up for namespaces and you know, use the pods in the four namespaces, the Harry Potter houses right to to do the conference testing. But the problem is um right. Now we use a pod ready condition to um to do to verify that these uh pods are already now on the test bed that we had um after a the state for sale is deployed. uh The pods are not even there so um in.

I

In short, we got a Ron um go a green light for conversing the um conformance testing before all the testing parts are actually becoming ready. So this is something that I have already opened the pr to fix and I'm thinking that uh we probably need this to be to be merged and then maybe use a different release tag or something so that you know entry can use that specific release. Tag to uh to to to to do the conformance testing, because otherwise the uh GitHub actions is actually fading on on the entry test.

I

But so um okay.

G

I

Is kind of like the uh status right now, but you know I'm hoping to have this. You know sorted out soon because uh we are actually looking at maybe another entry release uh next week and I really hope to get the mean level policy super merged by that release. So uh but obviously we need the conformance testing to be passing so um uh I'll I'll, you know um I see. Surah has already commented on PR I.

I

Will you know address these comments and uh let's maybe get this merged um you know by today or tomorrow, so that you know we can have more testing in the entire CFO. These are passes and we should be good to go for uh merging the free trading trip.

E

Yeah this is actually awesome and I I took a look at the pr and it was coincidental because one of the lanes when I was testing it in kind on OB and K. I ran into this exact same issue that you reported I just didn't have time to dig into it. So I wanted to take a moment to thank you for coming and fixing this right, because it is going to help pogi and K as well, because I.

I

Didn't well, you know and and I I, just I think I just saw your comment about the uh um the checks uh and and I do think that you know to.

C

I

At least I think the ready replicas should do the trick because the Pod um status it doesn't also. It doesn't also explicitly check for all the containers right, so it just checks. You know the part itself is in um succeeded status, which I think should be equivalent to the ready replicas. However, the problem is, you know, for this specific change.

I

I haven't been able to test it because I was doing a replace for the uh now a policy API to my own repo, but there are some sort of like wear dependency issues, so I couldn't I wasn't able to run this uh using the specific Branch um that I have so I'm going to still try that um to verify that you know it does solve the problem before you know, we actually merge it, but um but I I do think. uh I do think this should be enough for checking the ready status, though dude.

E

I

E

If it's I was about to say, if you, if you say so, if you want to test it once and then leave a comment, then I'm okay to merge it, as is if we think that the ready replica is not good enough uh for us to start uh to go ahead with before we start running the actual tests.

E

G

B

Me a green signal.

E

That it works on your CI, then let's get this merged.

I

A

Sweet and once it's merged um I'll probably see it, but if not just ping me and either we can cut a minor release or like I, did for kind of testing for Surya I just pushed a tag without cutting a release, because the API didn't change at all. It was just some of the conformance bits.

A

um We also want to think about for our next release. How we're going to package um these bits into the release. I know today, you're just pulling from a tag in your in your vendoring for your Downstream implementations, but maybe there's a way we want to do that differently, I'm, not sure yet. So, let's just try to think about it. While you both are dealing with running them. Downstream.

E

Yeah sounds good, so do you think for now? Maybe after this PR merges, we can you can just re-tag the 1.1 like.

I

E

Yeah, okay, that's.

I

Cool retake the one okay I thought it was going to be a zero one, two or something. So it's a retake, the 1.1 yeah that works. For me, too yeah.

G

C

E

Haven't really yeah, so let's go with 1.1 right, like I, don't think we really need to do a new tag. Just for this. No.

I

Good yeah I agree that works, sweet.

A

Yay open source, Yang fixing bugs this or yes I, found I didn't have time to fix. That's what we like to hear.

A

Cool um thanks for the updates y'all. That was really great. um Hopefully you know these two implementations will give us the ability to do some really cool demos with the API. That's kind of our end goal here and push other people to get implementations on, so we'll keep soldiering on ahead.

A

Okay, the last thing I guess I wanted to mention when I was looking back at the last one, um the last week's or our last meetings agenda is Dan. Winship is officially an approver. So just keep that in mind. um If you need something merged, he can do it as well, so excited about that and um I think that's all I had for today. Does anyone else have any questions? Comments, concerns Floors, open.

A

Okay, again, silence is affirmation um for new folks. If you I know that we went over a lot of stuff that involved a lot of prior art that we've already discussed, if you're looking for places to get involved um and want to actually start getting your hands dirty. We have plenty of stuff to do just reach out to me or others in the network policy. Api slack Channel we'd be happy to get you up to up to speed.

A

One of the big ones is ownership of kind of a developer, Network policy or a network policy V2. So we've been looking for someone to own that um nobody has raised their hand yet because it is going to be a challenging Endeavor, but we're looking forward to providing that functionality. So hey.

C

Andrew on that topic, is there an issue in the repo that provides more context.

A

um I, don't know if there's an issue, but we have a working document and I will find that and Link it in the agenda. How about that great? Thank you.

C

A

Okay, well, hey thanks for everyone's time. Today it was a really productive meeting and I will see you all in two weeks have a good one.

C

Thanks bye, foreign.