Kubernetes SIG Network, 12 Sep 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Network Policy API Meeting for 20230912

Description

Network Policy API Meeting for 20230912

A

Hello, everyone today is Tuesday September, 12 2023.. This is a meeting of the Sig Network policy, API subgroup to Sig Network. We are a cncf sponsored meeting, so please follow their guidelines and rules and yeah. Let's have a good meeting today.

A

um Agenda's fairly light um I'll, just say: I think sorry, I have some questions about her and pep, otherwise there's nothing on there. So if you want to talk about anything else, please go ahead and add it um to the agendas we're talking about serious questions.

A

Some things I just wanted to highlight like really quickly before we hop into your question. Sorry, if that's all right with you.

B

Yeah go for it.

A

um I took a stab at starting to update our project board for the road to Beta. um This kind of came out of a suggestion from Antonio and our last meeting. It was like you need to have a road map and you need to like set explicit dates, or else stuff's never going to get done. So the first step for me was trying to clean up our roadmap, and this is, is the roadmap right.

A

Our project board um I, tried to add all the n-pep issues and PRS that we're working on um that I think are kind of blocking us towards beta and then also a bunch of other issues that I think are also blocking us towards beta. So just as you're making any new issues um please and you feel like they need to be done before we do a Beta release.

A

um Please add them here and next step I, don't not necessarily we have to do today, but we probably want to set some like General dates. Like say, we want to make to make it to Beta by December and then work towards that, rather than us, just kind of like reviewing PR's ad hoc right um I. Think some deadlines will be good, so yeah, you can go see this board pretty easily under our projects. It's again kind of inspired from Gateway API, so shout out to them and.

C

uh This is a drag and drop thing.

A

uh So the only trick it's it's drag and drop once you get it in the board, but the main kind of annoying part is: you have to go like if you opened a new issue.

D

A

You have to make sure that the project is set and then and then and then everything's drag and drop. um But you just want to make sure that um okay, the Project's set.

C

Okay, I see yeah, because I I see I, think two things in the in the null status column should be moved to in progress. Prs I think some is Oliver. uh Who is a positive PR and my uh name for a change. Pr is also a PR in progress, so.

A

That's awesome, okay, so let me move that in progress. Well,.

C

E

And most people probably don't have permission to right.

C

E

Sorry am I cutting you.

A

Were yeah you're kind of choppy.

A

Can you try again Dan.

A

Now, we've totally lost you, but I think what he was trying to say is that the permissions are probably only oh well they're. Only me so I'm gonna add.

A

um I'm gonna add a gang and Dan since they're, um both maintainers just off the bat. What the heck.

A

C

Know why should I try DUI oh yeah, dude d-y-a-n-g-g I like like my GitHub handle that might yeah there. You are okay, sweet.

A

I'm gonna set U2 as admin. um Is there anyone else? That's you know in this group that wants to be moving these cards around um I'm fine, to give other people here who are active contributors to the project, um write access just so they can actually like move their own issues around.

A

um Is there anyone else here who wants that I'm assuming Surya.

B

Yes me too, okay, thank you.

A

Sweet you might have to the people I just invited you might have to accept something- maybe not, but now you should be able to and as good time goes on, if people want to make edits to the sport just paying us in slack, we can add you um so yeah, uh Step One is kind of getting this kind of cleaned up, which I think it's almost there uh step. Two is gonna, be let's put some some dates and deadlines on this, so um we can start thinking about that. Obviously we're Upstream.

A

Everyone has, you know a million other responsibilities, but I think it really would be good for us to give some deadlines, um especially for when I go to Sig, Network and say like look we're trying to get to Beta by X. So like we'd, really like some of wider Sig network works, reviews on certain things, Etc et cetera, um so yeah. That was one small thing. Any questions about that, and this is just for admin, Network policy, so obviously there's a bunch of other stuff to think about, but.

D

A

And if there's an enhancement, we're missing that customers are asking for, users are going to want that we want to get early like now. Is the time to add it because, as we are gonna have to like kind of lock this down right at some point, we should say like okay, we're not going to accept any more hat enhancements for beta like this is what we're gonna do um and that's it right. So I think we have a pretty good queue.

A

um I, don't really I can't think of any at the moment that I want to add. So if there are others like for folks watching recording this is kind of the time past due I'd say, but do.

C

You do you think we should wait after kukon, though, like would there be like tons of new things that you think that's probably going to be in there or.

A

It's a good question: um I'm, not against it, I guess that kind of comes with. If how we want to think about dates, um Shane I know, you said you have kind of this project, but do you like publicly announce like your intended dates to get to a certain uh goal somewhere else, or do you build it into the sport? Somehow.

F

um We have Milestones like releases that we usually set a date for once we get within a couple months of that date. It's.

A

F

Flexible because everything's, based on volunteering time, so there's never any guarantees right, but I wouldn't say we don't have after the ga. We are intending to have a road map where, like the minor releases, are kind of planned out as to what might go in them and when they might go out a little bit further out. But currently we don't do that. It's more ad hoc, but after GA we'll we'll be doing that.

A

Sounds good I think Milestones are probably a good way to do it.

A

um Cool I'll try to look into that. I think that'll work good, because then we can have. You know different milestones for different issues, obviously like. If there's a we could have an issue that says you know lock this board and that could have a milestone set of you know right after kubecon, but yeah I I think that's a good point. We might get some user stories, we never even thought about at kubecon so and it's coming up pretty quick, so I'm not against leaving it open.

A

Maybe this is right for well actually yeah we'll probably be presenting on this in the maintainers track. Talk anyway. So right it'll be a perfect Forum, yeah cool I. Like that good point.

D

F

Sweet so yeah, our our road to GA board, included uh many different Milestones V5, all the way up to V8 zero v080, which just came out and now V1.

A

Cool, do you as the maintainers of the project like? Are you? Are you Shane like managing all of that board, or do you just let a bunch of people? That's that's a lot of work.

F

So I I do the project management stuff, uh it's I'm I'm the uh because it was needed and nobody else wanted to do it. However, recently, as in the last few weeks, we did I I started I kind of pushed the issue of us having a maintainers meeting separate from the community meeting, because the community meeting I would I I would recommend having a separate maintainers meeting when you're trying to hit some timelines at some kind of regularity, because we a lot of stuff sorry I, won't swear a.

D

F

Usually shakes out in a smaller setting like maintainers, and maybe people who are like approvers and reviewers are good for that. That meeting, uh okay and focus it not on, like you know, the ongoing Issues new things, only focus it on the board, like look at the board, go over things what's getting out of band what's in progress, but that person disappeared a month ago, like keeping on track of that. If you want. Basically, if you want velocity, I'd recommend doing a maintainers meeting.

A

Yep 100: okay, all good suggestions.

F

Might actually be different here because it's a smaller group, but that's just something that works for us in a larger group. So let that be my inspiration to you. I, don't know if you need it or not,.

A

Right we're hoping it becomes a bigger group after kubecon. That's our goal anyway. I.

F

Would be I would be shocked if you don't grow significantly after kubecon.

A

We could use the help, so that's awesome. Okay, sorry I totally jumped in front of your agenda item Syria, so I am going to toss it back over to you. uh Go over some of your questions on the egress enhancement, which is struggling towards completion. So you have the floor.

B

Thanks Andrew yeah I, like that shuttling towards completion trees. Let's hope we can get it merged uh soon-ish. But um firstly, let me start by saying thank you. Everyone who has reviewed the enhancement- and we are almost there I- feel right. Some of the comments that are left out from Dan and Rahul and I agree to what both of them are seeing and which is why I'm bringing these points up to the wider team meeting. So we have.

B

The first question is around pass action right, it's just to shed some context there we have the the deny and the allow, which is the same as Central policies, but we have this new new pass action in admin, Network policies which is not there in our Network policies we run API right and what that does is basically delegates traffic that matches the admin Network policy rolled over to the network policy. So it's a way um of I I, want to say it's a way of communication between ANP and NP.

B

But really this exists in the East-West traffic. But question is: do we really want it or is there valid use cases for this to also exist on the egress traffic? I actually didn't even think too much about it and I added it. Just as you know, oh, we have it free stressed and it's going to be a part of the same API. So why not add it for egress kind of a thing, but Dan rightly points out that we do not have a valid use case.

B

So this is where I want to bring it up to the wider Forum to see. If anybody has a valid use case, that I then can add to the end pep and if we do not have a valid use case. My plan is to keep it, but it will be experimental or extended feature for the egress traffic use case, so that implementations are not first to implement it, because there is no valid use case right.

B

So I don't want to be I, don't want people to just implement it if there is a no if there is no use for it Downstream, but at the same time, if people do have use cases and they want to- they can opt into using this. So that's where I am, which is a sweet spot or compromise on both ways, but I'm open to suggestions and opinions.

E

So um just to clarify I was not suggesting that we should not implement this or or even downgrade it to experimental or anything. I was just saying: we don't have a user story for it. So so don't write a pretend user story, for it say you know, as an admin I will use the pass feature.

E

That's not a user story like so I I mean it would be more work to not Implement pass for for cluster egress, given that it's presumably going to share all the same code as the other stuff which, which does have pass so I, mean I, think it should be there, but but there shouldn't be a user story for it, and then you know, as I said there, if it turned out that there were some, you know good reason to get rid of it.

E

We could say: oh well, we don't have a user story anyway, so we could get rid of it. But until that happens like I feel like it should be there, but not be part of any user story.

B

Got it but here's my.

B

Story is it okay to just keep it as an implementation, like um do user stories, get what we put in the API or not.

E

No I would say, like user stories, are supposed to explain how we ended up with the API that we ended up with, but but they don't Define the API.

A

I I think yeah I think in the original cap. That was a little murky, but um in like- and that was just because the cap went on so many cycles like we had to justify everything we did in the API design by pointing back to the user stories. In this case the justification is not necessarily an explicit user story for um that you've added here in your egress mpep, it's more that like for API consistency.

A

It makes a lot of sense to do this, so I'm kind of with Dan on it like you, don't have to have one if there's not a good one but like isn't there a good one? Can we not think can we not literally just say like? Oh admin wants to allow namespace owners to.

B

I made it up: yes,.

C

So I think my take on this is that you know unless a um implementing pass for egress um Bears implementation burdens on some implementations, so we we don't want to do that or having passing um makes it really confusing for people using this feature. um Those are the two kind of reasons we might want to have this dropped, but otherwise we we might not even have to have a user story for this, and people just get it for free right.

C

So when you wanted to do some, if somebody wanted to do this, um you could do that, but we don't have a user story for it. So you know um we don't advise people to write a policy like that. um It's kind of like what I saw.

A

Plus one I was making wanna make it up, but I agree. 100 percent.

B

Okay, I think that clarifies my point also because I think I was really getting that everything going into the API has to be justified with a user story, and you do not just add things to the API. If it's not having a use case, maybe that's where I went from and that's not happy to just remove.

F

Yeah, that's not a bad default position to take, but I think to Dan's point: it's not a hard and fast rule. It's not like you don't break the rule.

C

F

Gonna get things for free and stuff like that. It's a good default position to be like I. Don't really want to add anything to this API that nobody's going to actually want to implement, but at the same time, if you got something that's just coming along for the ride, you know.

E

So so, as a contrast um in the tenancy API um Nadia mentioned that she didn't have a user story for tenant definitions that involve courts and sure we already have ports in the the admin Network policy API. But you know it seems pretty obvious, or at least to me that yeah, you really don't want ports in in the tenant definition right. So so, in that case, the lack of a user story does suggest that, maybe we don't want that feature there, but I think in this case you know pass is already there.

E

It doesn't need a strong justification to to stay in in this part of the feature as well.

C

B

Awesome yeah I'm glad we got a consensus and that I'm actually happy to then go back to the n-pep and then I'll. Just really just call out that we do not have a user story for pass as a note, but we are going to get it for I won't use the words free, but you know I'll say that we will still support it and I guess we don't have to make it um Extended conformance right. We make it core in that case,.

D

B

Cool and the same context for the host, Network, or also right, and also for the rest of all of you in the car. If you do come up with the user Story, please do go to the in pep and leave a comment, but as of now I'm just going to go ahead with mentioning that we do not have a user story.

B

um The same thing for host Network, pods traffic use case is this I. We moved the API server use case as a separate thing outside of the nodes and the host networks and the VMS and all that right. So it's going to be a special entity and it's a separate user story.

B

So that leaves- and that was the only user story I had under host Network part. So this is cni part to host network card policy case. So now we are left with no user story for the host Central cards as well. So that's two options: either I completely removed this goal for my impact or we keep it when we do a host selector, but we make it extended. Performance like we had decided, because not every implementation can differentiate between a node and a host selector anyways, any dicks, or anybody opposing that position.

E

So, in this case, I feel like, given that many implementations wouldn't be able to implement this feature anyway, that that dropping it would be better.

B

B

Think that I had was trying to get a k, API server, that is a host network card implemented. But since that's covered within the kpi server user story, I am I. Don't have any other use cases for host Network per se, so I'm. Okay, with that suggestion of just dropping that all together from the goals.

C

Yeah, in my experience with Ensure I, think it's 98 of the cases. If not 100 people are coming to toe to us, saying that why don't you select host network products? It's because they want to select kubernetes, API server right, so I I can't think of another use case for host Network pass as well. So.

G

Go ahead, roll.

H

uh Just something to clarify, because I got a little bit lost. Are we saying that we're selecting the API server as a peer or as the primary.

C

I think, as a as a peer as a peer okay, yeah, so I I I, can I can actually provide a little bit Insight on some of the um quote-unquote use case. That we saw is actually in the cloud scenario where you know I. Think.

C

uh Let me let me try to find the exact issue, but essentially I think what it does is that some some users opened up an issue and saying that in eks environment um they don't have the um I, don't know if it's Coupe DNS or something running in the group system cluster, but they have some other um like the default kubernetes Service uh running in maybe another repc, so um their workloads needs to talk to the default kubernetes service um via the control plane, node IP, which they want to select as a host Network um wait, wait a second I I, think I'm, not making sense here, but I was lost yeah.

C

Let me try to find the exact issue, but uh you know.

D

We're trying to do multi-clown right or multi multi-cluster communication.

A

I, don't think this is in I I'm, not sure if this is in relation to multi-cluster like I, don't think it's in that.

D

Contextluster rules right: you have two clusters and then it's normal egress Ingress over the house or maybe not.

C

Right, you could go ahead, I I'll I'll, you know, do something: offline, yeah,.

A

Did we answer a Rule's question? Yeah yeah no I mean I just.

H

Wanted to double check that it was only we're, saying, select, pods uh like regular pods and allow or deny egress to the API server, and that makes sense right.

A

A

And then like as to whether or not things should be extended or not, Surya like I, don't think we have to know that right now, I think like. If we get to the point where we've you know written a new feature or written the the yaml for this, the API definition and um we have implementers right, ieu or Yang, and then whoever else comes on board in the future telling us like. Oh, we can't do this, then it's a strong case for us to make it experimental right or extended support, so I.

A

Think for now we go with core. If you and yang are cool with it from ancient oven, comedy side of things, we can always, you know bump it back out.

B

Yeah, that's a good point, sounds good yeah. So I'll um update the end consensus items that we discussed today and then, hopefully you can sweet.

A

B

Close to merge.

A

Yeah sounds good. Thank you. So much. That's awesome. First, empath about ready to be merged. That's a big milestone! Right.

A

Thanks for all the hard work on it, um okay, that's all we got on the agenda. Is there other stuff folks want to discuss today.

B

I have a fun topic right, which is uh something that I got as a feedback from one of the customers. I was talking to last week. It was around fast action, coincidentally, and another way of looking at pass.

B

Action is to not Define it in the first place right like if you do not Define an adminatorial courtesy, but you have a network policy, it's the same as passing right like in a sense of um the way it works, because today, the way Network policy and Baseline nbinatorial policy work is anyhow because of the way they're evaluated per the theoretical definition, It's, Always, A and P first and then NP and then B, A and P.

B

So from an end user perspective, just defining the banp is automatically passing on traffic from NP to the banp right like as a as right as far as they're concerned like they don't have to explicitly ask a network policy to pass it, and this right they were thinking like the same there's a little bit inconsistency in the way we say: oh yeah, you can pass from me in P to NP, but really as far as you're concerned.

B

If they are safe as an admin, if they're safe enough to avoid even creating a an a p, it's kind of the same like even if I guess what I'm trying to say is like I guess, maybe it's an implementation detail in the way I do it in OV and K I, don't know how Andrea does it, but the way we do tiers in how we evaluate it and how our diagram looks where you're guaranteed that the ANP rules are evaluated first and then the NP and then the ba and B.

B

The past thing was a bit of a of an interesting thing for them to like they were just mentioning it.

E

So I think I, okay,.

A

Sorry go ahead, no you're good! You got it I.

E

Was gonna, say, I think the the point of pass was so that basically, you could create a hole in an ANP um like if you wanted to say that, like you know, if it's on Port 80 then pass otherwise. If it's you know to these things, then drop in and and so then you're saying, like you know, drop egress to these pods but allow Network policy to decide whether to drop or 80 to those bullets.

A

Exactly what I was gonna say um it like I feel, like we went around in circles for a long time on how to define exceptions to anps and what that means, and we settled on making it explicit right. Like obviously an exception to any rule, you could say is the same thing as not defining it, but um we kind of ended up with past what was the other one? We had Yang. It was like in power. We had a whole host of ideas, yeah.

C

The focusing signal really didn't didn't, like it I think but yeah but I feel like yes, this is kind of like a little bit more into the the philosopher kind of things where you know it really depends on how you look at it right. So it's an elephant. If you look at it at different angles, you'll see different things, but by the end of the day, if people understand what it is and know how to use it, we're good, we just wanted to come up with a good.

C

um You know the starting point on how we explain this so that we hope you know people really um uh really understand. What's the rationale behind it and know how to use it, basically,.

A

Yeah and I had you had you assigned that issue to yourself? I opened an issue last week to write like a best practices DOC for amp and.

C

This guy I'm working on it right now, actually because, because I think I'm doing the write-up I think it's gonna be better than fashion for for coupon as well right, because we have the the the talk, uh the main talk where we explain what the API is so I think uh I think what I take from the issue is that uh we have a lot of examples on the on the uh um website that we have, but we never had an example where we say that hey in this cluster, we have a bunch of namespaces and we have an amp and a bunch of KMPS together in that cluster.

C

Now, how would the? uh How would the traffic look like? We don't have an example like that right, so.

A

That's one of the big ways right.

D

A

One of the that's one of the big things I think the other thing to think about maybe I didn't convey to that issue was like with network policy. You know we have docs all over and Upstream. That's like. We suggest that you do this right. We suggest that you lock down everything in your cluster explicitly, even though it happens implicitly and then poke holes in it, because that's what makes the most sense right default denial and then a bunch of.

C

A

So like having something along the same lines for amp and BMP like um and maybe Syria can speak a little bit more to it. Maybe not, but we we had QE testing the feature and they were getting a little confused right. They, they defined to be an ANP really quickly that like denied everything and then they realized. Oh wow. We have to write like a custom Rule now to poke holes for our control plane right because everything's gonna pause.

A

So um you know just kind of having a duck that that makes That explicit says like this is how we would use it, or this is how we've seen it used right, so I think from from findings from Andrea or openshift Etc yeah.

C

I feel like it's kind of like uh completely different or the opposite way. Right rather than you know, I wanted to lock anything up and then Focus like kubernetes now policy in the admining, our policy, because it's a little bit more powerful, you don't really want it to just blindly, throw it and then I mean now policy there you, you would really want to have a really specific traffic pattern. You wanted to explicitly allow a block for you to actually apply one of these. You don't just you know, throw.

A

C

And say it: okay.

A

I just wanted well just remember that everyone has been right using and stuck with network policy for the past six I mean, however many years five years now so they're, very that's our that's very ingrained at the in their head at this. At this point, right um I, don't know we'll see you know, as as we get more feedback and stuff.

H

I wanna, um like maybe I'm, not sure what the right place to do this is but I do think. We need more examples of Baseline admin, Network policy, um because I I think I had a conversation with you Andrew and uh Yang a while back now, uh where I was very confused about what banp is actually supposed to do um and I think it's kind of underspect in general like it's not there aren't enough worked examples to make it clear what happens like. Maybe the wording is true, but it's. It is pretty dense.

A

Yeah, maybe we can take because I know our QE Team and Red Hat has been like making some scenarios, so maybe I can get my hands on those some of those test cases and we can Upstream them and that might help because it'll actually show you yeah more examples, but hopefully Yang's document will help as well, but I I totally agree.

H

Yeah, because it's it's not clear to me from the docs currently that BNP is not really a fall through it's a default like you, don't fall through Network policies and hit banp. It's just. If there's no network policy, you evaluate B and B, and that's actually like it's consistent with network policy, but that doesn't mean it's not surprising, given how enp works right.

C

Right I agree because there's no fall through for Network policy right right. You either you either hit it. Allow that's experiencely written or you hit a unexplicit deny, which is captures everything right. So so there's no. It captures everything in the namespace. Basically so yeah.

A

I agree: maybe we've used the word pass through a little too liberally here. um It.

C

Is confusing right, I'm hoping um a couple of examples, whereas diagrams in the uh sample yamos can help solve this issue.

D

C

And I'm I'm actually working on it, so I'll keep you guys posted tweet.

A

Thank you so much yeah. Let's just make sure it's on the website um as well: okay, sweet sweet all good stuff um I feel like we're. Making good progress, kind of looking forward to kubecon excited to see everyone who's going to be there um I think. That's all I got for today. We'll keep reviewing uh npeps, try to get Syria's one in uh ASAP and keep kind of moving along on the others. So is.

G

There anything else.

A

Folks want to talk about.

G

Oh hey Andrew,.

D

G

Could talk about Cyclones if there's still time.

A

There is still time take it away. Awesome.

G

um Might share my screen if.

A

um Yep, let me give you right.

A

Okay, you should be good to share now. Okay,.

G

All right um yeah, so last meeting we um talked about cyclonus a bit um and then the overall takeaway was to look more into the implementation, see if it's feasible, um so I tried to flush out more of what, in my opinion, would be a good idea to do if we go along with it and then I was looking at the code um to see how easy it would be to do that.

G

um So one other idea that um you guys were talking about was just selecting parts of psychonists to keep um so overall I was thinking. um Probably the most beneficial Parts would be the test case. Generation Um I think this is just an example here, um where it um maybe I could zoom in a little better um much better. Thanks.

D

G

um So the there's, like a framework where you can kind of programmatically create tests like this I'm, not really sure what the state of our conformance is right now- um and maybe this is all these things are already part of that, but I'll just go into what the cyclinist kind of looks like so yeah. You just have like Steps for each test case and you can do actions like labeling pods, creating a policy in that programmatic way.

G

um So it ends up being a pretty quick process to create new tests. And then you can add tags um like here. There's a tag for create policy, and if you wanted to just look at tests that had create policy or say, if you just wanted to look at tests that had ANP, you could filter based on that.

G

So that's the flow for programming tests.

G

um Then this is like the cyclonos formatting here. um The main benefit, maybe is parsing the policy into a table and kind of giving the human language of what is going on within it. So.

G

um What I was thinking if we wanted to extend synchronous to amp I was thinking probably be beneficial to incorporate both the policy table and um test generation, because.

G

um Test generation would kind of be free um once you create a probing like expected, connectivity function.

A

So that, on that little snippet there, um it looks like you're, defining right, explicit test cases when you say there's generated test cases. Is it literally just like a matrix so like it'll you'll have right? uh Is it? Is it a connectivity Matrix or is a that is auto-generated or is it a um test? Matrix, that's auto-generated.

G

um So there's there's like a list of tests um that are run like like here. Some of the tests like set name.

D

G

To X is one of them and it has uh One Step here and then it sees um like if the connections are correct or or wrong um that isn't the best example um I think I get what you're saying, though yeah, but this is the um connectivity Matrix that you get for free once you implement the like um Network policy simulation and then they come. They compare like the expected results.

G

Pinging on egg and host pods with the simulated results.

A

Okay, so breaking it down I try to make the question a little more explicit, I think I understand what you're saying. So, if you write a test that for Network policy ensures that pod a you wouldn't write, a test that says um ensure pod a can talk to pod B right, you'd, write a test that says deploy this default, deny all and then Auto generate a matrix of expected connections like okay. That's.

G

Weird you're just creating the network policy and then cool yeah.

A

And then cyclonus goes in and does all this? This makes Matrix generation for you, basically yeah yeah, that's right, sweet, so I know today. Surya and yang can both speak more to this to me because I've reviewed it, but it's been a while um we in our conformance testing today, we like literally hard code like it's explicit, like we literally have a matrix of PODS, and then we go through and say like for this test.

A

Pod a should be able to talk to pod B part C shouldn't be able to talk to pod D et cetera right is, am I correct in saying that Surya.

C

A

D

A

So like something like this I think could totally be really cool. uh Don't you think Yang and Surya? Now it just pertains to like not much of a nightmare. It is to uh Implement for amp, but.

B

Yeah, but when we had started off with the conformance tests right, we had looked at Cyclones in this metrics and then eventually I think we all wanted to reach that state. So I think it's a cool thing to have where we just create an A and B and then see that effect across different combinations based on connections of labels right so I plus one. For me, it's just a matter of figuring out how to merge this with the existing.

A

Right, that's the tricky part, I mean I, think first, we would do like a development experiment alongside it right like leave the conformance test as they are um and start either in our repo, well, probably in our repo just kind of having a little directory to hack on cyclonus, maybe even with a custom, build tag um but like this would be really great.

A

I think this is step one and then step two is the table right, because this is more like core infrastructure Improvement versus like the table output view is more of like um really great. You know good new tooling that we don't have right. uh Well, maybe it's I don't know. Maybe it's not maybe it's more important that we work on the tooling first actually, because we already have conformance tests I'm, not really sure.

A

Because I know it's going to be complicated for users like the moment they get a bunch of anps in a cluster along with net and piece like understand. You know what that looks like in terms of of traffic flows.

G

D

Anyway, I could also.

G

um I started thinking about like what the table could look like with amp. If.

A

G

Like to look at that,.

A

Yeah sure now this is this is really really great. So, let's, let's check that.

G

Out um and yeah also looked into the code to see what you would change and where um oh, that's awesome kind of nitty gritty, um so yeah the there's, this Cyclones analyze, parse command, that's also used in the test um function and that's kind of what we were seeing earlier with this table.

D

G

So it gives you like the Ingress and egress and then the targets- or these will be the subjects for A and P, and then all the network policy rules that have that Target um and then appear in protocol. So what you would want to do is probably add these features for NP.

G

um So, first for the subject, you would just support um a namespace selector and a node selector. If that's a thing um and then you'd support um same labels and node selectors for the peer and then probably add an action column with priorities.

A

Yep cool that would be so helpful, I mean I. Think that's. That was one of the things in our initial design of the cup and we've talked about over and over is like having good tooling from the get-go, which is really hard right, because our API is still changing and there's other priorities, but something like this would be really great. So is there anyone who has other opinions so like? Basically, what you're saying Hunter is like the bones are good.

A

um We just need to decide like where to allocate resources to get. You know what you've presented here done essentially and how to prioritize it.

G

Yeah yeah I think um I have a good idea of like how we would implement it um and yeah I. Think one thing too is we could like decide. If there are parts we will never want from cyclonus and then just remove all that code to simplify the project or or maybe just leave it untouched or.

A

Something no I think we should I think we should definitely remove it. um I don't think that's bad, especially considering like cyclonus, is still existing in its original place. Right, like I, don't feel like. We have a responsibility to keep it all, as is essentially like. We should make it work for us um and definitely credit Matt, because this was like a really awesome project: yeah. Okay. So how about this I, really like everything you've done here, I'm stoked on it?

A

Do you want to maybe break the two things we talked about and make and try to make issues and like break it down um on our on in in our project? So then we can actually start kind of working on some things. I I still am kind of unclear on what we should prioritize. It might be like what people are interested in right um or what you're interested in I don't know. If you want to kind of keep going down this path, you've already done.

G

A

G

Yeah I'll definitely keep working on this.

A

Cool but I don't want it to be like totally all on you, which is why I'm saying like. If there's stuff, you can break up to get people to help. You I'm happy to try to help pick up an issue or two um and hack along with you.

A

um So if we could just take this Google doc, either make an issue and and Nest this Google doc in it, or make an issue kind of explaining, like the steps or multiple issues explaining the steps of what we need to do. That would be great.

G

Yeah yeah, let me do that.

A

Sweet any other opinions and thoughts on all this work. This is awesome. Honor, like thanks for diving in super super deep here. No one has done it. No one took up that slack, but I think I think it could be a real differentiator for this project.

A

Like imagine, if we get to kubecon and we can literally show a table explaining what these admin Network policies are doing like in the terminal, I think people would love it, especially because it's coming from Upstream.

G

Yeah, so it sounds like we kind of want to work fast on this.

A

That that's like a a dream right, um I I'm, happy to help facilitate as fast as you want to go. I just don't want to put it all on you, because that's what happens in Upstream. A lot is like you did. You did this deep dive and then you end up owning everything, but if you're excited to get going I'm happy to help review um and help out with it, so.

D

G

I'll start with the issues and then I guess we'll go from there.

A

Basically, you are already the expert with the cyclonus directory in our repository, so you know, go for it feel free to start hacking away. Sounds good awesome thanks. So much that's really really great. It's super exciting.

G

Yeah, um do we also do we have any interest in pulling the most recent commits, or is that kind of a nightmare to deal with? Oh.

A

um Well, I think, maybe that's one of the issues we need to make is like. How do we deal with the Upstream right like? Is this gonna be like a hard? Are we gonna treat whatever we're gonna turn this tool and tooling into as like a hard Fork, where we kind of like make it our own, or is it gonna be sort of a staff work that we continue to try to keep up to date with cyclonus, which I don't is Cyclone is like iterating, really fast, I, don't think, there's that many new commitses.

G

There not that many new commits uh just like um like uh I, know, I contributed like a fail, fast option that isn't yet in our version and stuff and I'm I'm wondering if there are other features that might be useful. But we could always um like cherry pick stuff that we want if.

F

G

Asks for it later.

A

100 I'll leave that one up to you, Hunter, like like I, said I, think you're the that's the expert here on this. So if you want to cherry pick stuff or even do a rebase to get all the existing commits like feel free to do it.

G

Okay sounds good.

A

Cool bunch of exciting stuff, all our meetings recently, you know they look short, but then they turn into the long ones. That's a good thing. More people.

A

Anything else folks want to talk about today.

A

Okay, then we will get out of here with six minutes to spare.

A

um I'm gonna add a note to the agenda just to talk uh just to make sure everyone knows that we had a good talk about Cyclones today and that Hunter is going to kind of keep going on that train um but yeah. Otherwise, that's all I have for today thanks so much for coming. Everyone I really really appreciate it and we'll keep moving forward.

D

Last week,.

A

D