Kubernetes Network Gateway API Special Interest Group, 11 Apr 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: SIG Network Gateway API Bi-Weekly Meeting for 20220411

Description

SIG Network Gateway API Bi-Weekly Meeting for 20220411

A

All right, it is april 11., uh we've got uh full agenda today. uh So thanks everyone for coming out. uh This is the gateway pi meeting for april 11.. I I see some new names to me. At least, I think, uh if, if anyone does uh feel like, they want to introduce themselves we'd love to uh find new new faces and uh and see what brings you here, but also no pressure, if not, but we're always happy to have more people uh at this meeting and taking part in gateway, api and uh contributing cool. Okay.

A

um So, first off I should say this is gateway api community meeting. It's very informal. We have a agenda here that anyone can edit. So please feel free if you want to add things, but first off on this list is mike, and I think you're here so feel, free to start us off with uh reference policy things.

B

All right so yeah. This is something that I ran into when implementing support for reference policy. um I was initially thinking of the case where resources are modified after a route was initially accepted, uh but one of the contour maintainers also pointed out that their implementation uh differs in from what we I proposed in the conformance test for how a route should initially be treated as accepted and routing traffic.

B

um When a back end draft in the route may not have permission granted through a reference policy so um and that's potentially more complicated if resources are modified, um if a route should ever like become unattached when it's modified or when a reference policy is modified um or if traffic should uh default to like 503 errors, as is mentioned in some places in the spec. The fact I think is contradictory around this there's some parts that say invalid resources should not be accepted and there's other parts that say.

B

Traffic to invalid back ends should uh give a 503 response, so basically just open. This up topic of discussion would love to hear from other implementations other maintainers in terms of how y'all are approaching this and try to get some consensus on what is correct, or we should be checking for conformance purposes.

A

Just to make sure I have the question correct here, this is in the case where reference policy allowed a reference initially or allowed. This cross name space reference to exist and then that reference policy that allowed it is modified or deleted in some way that no longer allows that to exist. What do we do in that state?.

B

Yeah, that was my initial case, um one of the contour maintainers uh steve chris. I think uh also mentioned that they do allow route to be accepted uh if one of the back ends is not permitted initially, but just follow through the traffic to it.

A

Accepted but getting it so accepted, but not routable so accepted, and yes, returning 503, okay, yes,.

A

That seems that seems con, so the status for the route is accepted, but the route will surf nothing but 503s.

B

It's mostly, I think, in the case of multiple back ends, where one may be valid, one or more may be valid, but at least one is potentially invalid. So think of like a v1 v2 split, something like that.

A

Got it okay, I yeah that makes sense.

A

Yeah that's tricky.

A

And let me pause, I should I should let anyone else speak before I before say what I'm thinking.

A

Okay, I'll go for it. So uh with that, I I think what we've done elsewhere in our api uh is maybe a little bit.

A

I I think the most relevant thing here would be the allowed routes on gateway right, where we have that same kind of cross, name, space, allowance from gateway to a route, uh and in that case, when that is no longer allowed, I can't remember our guidance, but it feels like we should be doing the same thing in both cases and I feel like it is to drop tr like drop that route and consider it no longer attached to the gateway.

A

I'm not exactly sure.

B

That's the trickiest part is like: if you modify a resource- and maybe it's only five percent of the traffic it's pointing to an invalid destination, would you end up dropping an entire route that 95 of the traffic is active? That seems risky.

A

We've had a similar conversation before and the problem is you you it's very difficult to define that appropriate threshold right, because what, if it's the other way and you've got a back-end, that's used to handling one percent of traffic and you send all your traffic to your canary backend, for you know whatever reason um yeah huh it jeff did. You want to say something.

C

Yeah, there's, I think, there's a couple things. One is.

C

I think there's two different issues here. One is with you know, with a route when you've got some of the back ends available and some not uh you know from a policy point of view.

C

What do you do with the route and I'm not sure the answer on that? One. From my perspective, I think that the second issue, though, that mike's getting at, is you know what, if they're everything's fine, you know I've got a functioning route and and back ends and everything, and then um uh the administrators of the name space with the the say the resources are in the back end reference to they change the the uh the reference policy and no longer allow that gateway to access those resources. What's our behavior?

C

Is it like with a gateway class where we don't change it once it's been uh put in place or is it dynamic and we would stop for using sending traffic to those those backends.

C

Like, I think, sorry rob, I think it needs to be dynamic where we stop sending traffic to those to those resources, because there is a security implication here.

B

I guess my I think my core consideration is there's two different ways to stop sending traffic. One of them is to start responding with 503s. The other is to entirely detach the route, and I think that's kind of my core question is: what's the behavior that's expected.

A

So in that, in that very specific example of you have a.

A

You're you're splitting traffic between two back ends. One is another name space that one another name. Namespace is no longer valid, but you still have one valid backend. uh Do you just send 503s to the invalid backend now or to request that would have ended up on that invalid backend?

A

Or do you just drop the entire route and yeah? uh I I want to back up one more step and agree with jeff that this should be dynamic, that we, this is a security thing, and if someone removes a reference policy, we don't want that access to persist indefinitely like we. We want that to be an immediate as close to immediate response as possible.

A

um I think thank you for whoever's, taking notes, I think, uh related to that it may be practical or wise to consider a finalizer pattern here of you know this reference policy is being used to grant access to the to some set of resources uh and I'm gonna drop a finalizer on it and you can I'll remove the finalizer as long as this is no longer relevant for my implementation. This again that doesn't change the the end result.

A

It just makes it a little bit harder to have accidents, because the accidental deletion of a reference policy here is potentially very painful.

A

As to your question mike, I I'm not sure how many I'm not sure I don't think we have any prior art for the idea of saying that you know in in this traffic splitting scenario that 99 percent of re responses need to be 503 and one percent can go to a valid backend or you know like splitting, between an error result and a actual back-end routing.

A

A

I think this I think this deserves more. I don't feel like I am qualified to answer this on my own, I'm interested in what others say on this call too, but we may need to bring this out to a github issue, discussion, etc. Just for that specific question.

A

Any any other thoughts from other implementers.

D

um Say hi, I'm travis, I work on the kong team with shane um and this kind of just was something I was looking at today. uh I kind of agree so far we'll fill in the stuff like should it might be dynamic or not. um It should like that's kind of the way that our information is going to work inherently anyway. uh If we get a change, we're going to rescan all the objects to see if they can still apply, I think we really need to do that like otherwise.

D

You would not be able to like add a reference policy in the middle of operation either, um and that seems a bit. You know not what you want as far as the other part for whether it gets like partial support or not. um I forget offhand like what we actually do.

D

I think in our case, if, like there's a specific rule, we cannot handle um if, like we will generate, you know the remaining rules that we can handle without any issues or not, um but I mean that's kind of the way that we would do it like.

D

If we wanted to get partial support, we would generate any rule that we could um and like log in anything that we could not um what's the other player they're gonna see here um thing I was looking at for this- is that, ideally, we would kind of want to just say it like edit time.

D

um If this makes any difference, like you know, kick it back out to the user and say, like you know what you requested isn't possible, but that becomes a bit difficult here, because it's not something to do with a single resource that admission controller, like it has to um cross resource lookups, to like check both the reference policy and the http route or whatever.

D

Because we can do stuff when we reject stuff in the middle, um but it's more it's not as user friendly, because you have to like go look in blogs to see like what actually got rejected.

A

Yeah great great thoughts- and I I agree that it would be nice if we could reject immediately uh every time I've tried to push for cross resource validation upstream, it's gotten shot down pretty quickly, just because it's so hard to guarantee order of operations, and you very likely end up uh preventing you know valid configuration that just came in out of order or something like that um yeah. I wish we could find a way to provide immediate validation here uh and maybe maybe there's something. But I agree with everything you're saying here.

E

Just a quick question for someone who knows the answer to this um mike mentioned something about um uh reconciliation at the top. Does that mean that that there's an operator that's examining the status of the back end of all the multiple back ends that might be attached to this route? That might be able to mark it as degraded or you know not quite ready, for you know in some way, not quite a valid route.

A

That's a good question. I don't think we've defined any any kind of standard guidance or suggestion to do that. I yeah what I think mike you may be, the one taking notes. I think you're suggesting yeah, that the resolve ref status of we we already have all of this conversation seems to overlap with any other instance where back and ref is invalid right. So someone makes a typo on their back and ref and it references just a service that doesn't exist because the name's wrong, or something like that.

A

So so we do have a more generic set of guidance for what happens when you refer to something that doesn't exist, uh and I- and I think this is awfully similar to that.

A

uh But I maybe I didn't completely understand your question, but I think you're talking about like a generic controller pattern of marking a route is degraded. Is that I'm not sure yeah.

E

Yes, I just don't know. I haven't investigated closely enough to see if reference policy is, I mean if routes are something that are reconciled along with the status of reference policies.

E

So, yes, I guess it would be just a generic.

A

Pattern yeah, no, I I think I think we I think we have a pattern that is too generic right now, uh the docs, you know uh the the docs for even resolved refs or even a missing back end ref or a invalid back and rep are not clear.

A

What we're you know what an implementation is supposed to do uh so yeah we we need some kind of more well-defined pattern than we have today for what that can be. I think part of part of why what has prevented this from happening? So far, is you know? In some cases we just say: well, whatever the implement implementation has, when there's no routing is what happens, uh which there's some variation. I would imagine this feels this feels different than that.

A

Yeah, I I think this is a big enough conversation that it merits an issue uh unless mike you, you link to something, but it looks like just a comment on a pr.

B

A

B

Was a pr comment that uh kind of prompted me to reconsider the initial acceptance of it, in addition to kind of the life cycle conditions that could cause a situation like this but yeah, um I could definitely write this up as a github issue. That seems like a reasonable next step.

A

Cool and candice, I'm not sure, did we answer your question or just make it more confusing.

E

No, that's fine I'll, look into it more on my own. Thank you.

A

Okay, great thanks uh any additional comments on uh reference on this question.

A

All right: well, thanks for bringing this up uh reference policy, is one of those things that I think is both very exciting about our api, but also needs more, better, better document, more thorough documentation uh and implementation guidelines. So thanks for pushing this forward, I really appreciate uh the upcoming tests conformance test for reference policy. It's gonna be very, very helpful, um yeah, okay, so uh milestone.

A

uh I pulled this, so I always try and add just try and keep a focus on v1 beta 1, because that's our next release want to make sure we're still making progress towards it, and so I always add an item for that and I pulled an item in from the last meeting because I don't think we actually discussed this last time mike, but you had an item on the agenda that got, I think, missed, or I just forgot about it, but renaming the default uh branch from master.

A

To main I know I talked individually with nick about that. He was very much on board. No, I think nick actually suggested it, and I was on board either way big fan of the idea. Just no one. No one has volunteered and we haven't tracked it anywhere.

A

um I linked the official guidance of what needs to be done. I I'm supportive, but I I have not.

A

I don't currently have the time myself, uh but maybe, if there's enough interest, uh we could uh at least have an issue to track that this is something we want to do and if someone wants to is anyone, does anyone have time mike? Is this? Is this something you're interested in uh working on as well or just uh I know, I'm sure you have.

B

Plenty, I probably have my plate full with reference policy stuff, um but it's something that I would love to see happen before we go to beta.

A

Yeah yeah- um I I am in a similar place of I would love to see this happen, but my my plate is also more full than I would like to admit. uh So, at the very least, I think uh this is this is something we should add to an issue and say: if, if someone is interested in working on this, uh here's how it would happen and there's, I think, broad support from uh project maintainers to move forward with it. If anyone has time to to make it happen, um yeah, so I I can.

A

I can follow up and create an actual issue to track this, and definitely this is one of those areas where, if you are wanting to get involved, contribute to the project, uh we're always looking for additional contributors here, cool all right.

A

So next one is uh api review, one of the things in the oh, I kind of skipped over the v1 beta one, while so sorry for that uh there are a few things going on in v1 beta one milestone, we're still at the same spot of uh almost entirely focused on documentation and uh yeah, basically entirely focused on documentation and web hook. Things I did raise a bug the other day that I found going through api review myself, and this just does not seem accurate.

A

We had a gateway, spec addresses that was listed as core support. It did not seem like it like many implementations could support this so anyway, there's a pr that will switch this to extended. I don't even know that this is an api change. So much it's just a clarification, uh but that's one thing that got added to the milestone in the past week.

A

You notice that we have many of these. There are prs that will close them out soon, but there are still some things that uh we need a bit more work on, but again documentation in web hooks. I don't think these are. I don't think we have api changes pending here.

A

If there's anything that you really want to make sure is included or fixed in v1 beta 1. Please please, please raise it now or soon. Just so, we don't. You know graduate resources to beta and regret having something in here once we do get to beta that the resources we've graduated, the fields that are in those resources are basically locked. uh We can do some basic changes, we can add things, but we can't really re remove things or make significant modifications to what already exists.

A

Just add more things on top yeah, okay, so related to all that yeah.

C

Rob on the the gateway spec address, I mean I I'd agree with you. It seems like this shouldn't be core should be extended. uh Do we need to do anything other than just get a pr for this.

A

Yeah, there's a so there's already a pr. uh What we do need is uh a release. Note just you know and we'll make sure it's part of our change log. This is one that could probably be cherry picked back as a patch release. It's I look at it as more of a clarification. I don't think any implementation out. There really looked at that and said. Oh, this should be poor, because you know it's it's frankly, not supportable by enough that yeah. So I think I think of it as a clarification or bug fix primarily yeah.

A

I okay, so uh great question. Thank you. I one of the key things in v1 beta 1 that did make progress last week, was going through api review, the last api review session that we had for with sig network reviewers. I just set up some time on friday and had you know time where any api reviewer could chat with me and work through any any api issues? Anyone is welcome to attend these, but it's so hard to find the logistics of scheduling things with larger groups of people. uh Tim showed up for this review.

A

I expect I'll have additional review sessions if anyone is interested in being part of that by all means. You're welcome uh with that said, um this is just the tim left. Some comments on this review uh on this pr and some of them I wanted to highlight here.

A

Okay, one of them was mine. This one I'm going to cover shortly another one. I kind of chatted with shane about a little bit and uh tim has been tim, had a few questions that I am unfortunately not equipped to answer, because I it feels like so long since we did the address matching that I didn't have a clear answer for him about source addresses in tcp and udp routes.

A

I I think, I think the reason we added source addresses as well as destination addresses, is just that it wasn't like that was theoretically useful, um but it was I'm not sure if the intent was purely matching or if we were starting to overlap with firewall. um If my.

F

Can hear me yeah if my memory serves, I actually intentionally left out uh source addresses in the in the pr that I did. I believe somebody else added destination.

F

um I can still help out and like try to make some sense of that situation, but I'm not I get the questions. I understand the questions completely. So I'll take a look at it and kind of okay, yeah.

A

That's good, I I need to look back through this too and and find the history um but you're pretty.

F

Sure it was the second pr, a follow-up pr that added the source ones pretty sure about it, but the.

A

First, pr was dest and then second was source addresses and source addresses are less yeah. Okay, that.

F

Makes sense yep? Originally I didn't see a specific use case and I really didn't want to add something. I didn't have a specific use case for.

A

Yeah, no, I I get that I get that.

A

Yeah well, we'll have to look back to the history, but this is one that I just didn't have a good answer to yet uh so if anyone does remember context or has a clear use case, for it uh definitely speak up, if not it may just, it sounds like there's not a lot of people that are really.

A

You know needing this specific feature. So in general, when there's a lack of that, we may just cut it from the release. There's actually.

C

Sorry, there's actually there's actually a pretty good use case for this, um and it's when you need to block specific resources from uh like a country which is not in common. um You you like they can look at your. You know, look at your web page and stuff, but they can't download your software kind of thing.

C

So it's gonna, be you know you have to make a decision based off of what you are, what um what url is trying to be accessed and whether or not that source ip address is allowed to access that that resource. um So that's that's a fairly common use case that I've seen.

F

Yeah, that's that's true, and actually that was fathomed when we originally wrote the gap it was, uh but the problem being in its current state there's no sitter support for a type. So I think that reduces that use case quite a bit by having to put in like every ip address of a country of course good point. So so that's something that, like I do think eventually, I thought originally eventually.

F

That would be the main use case for source, but I just didn't need it, so I didn't put it in, but in its current state I don't think that one's gonna work, unfortunately, because unless we go ahead and we just push to add sitter, which is a pretty straightforward change and if somebody's like really in favor of this I'd be like yeah just add the center support.

A

I think that's a good point. What tim, what tim specifically was calling out here, is that what we say right now in source addresses is is unclear. It doesn't say that we're dropping you know traffic that doesn't match we're just say it seems to indicate we're just ignoring it and letting it continue through matching, which is in inherently different than, uh for example, what we have uh yet.

A

I forget the specific uh name of the field on service type load, balancer of source, ip ranges, basically, uh where in that behavior is, if you're, not in that range, you're dropped, you're, explicitly dropped, and here we're just the description is pretty vague, but it seems like what we're suggesting is we just ignore it and let it continue to see if it's.

C

An or match yeah.

A

uh And so anyway, I think it's unclear here and we need to revisit it and yeah. Like you said shane, we should just go back to the history and figure out at what point we added this, and maybe we can find some more context on why we added it. um I know like, and the thing is it it very well could have come for me. It's been so long. I don't remember um but uh anyway, that that's just the thing.

A

So if anyone does have a clear use case, uh let us know uh otherwise we'll just try and figure out what what our original use case was. um Okay and then he had a similar question for destination address. Matching.

A

I think this I think destination address matching is clearer to uh describe the use cases for, but it is. It is still admittedly hard to understand uh when combined with a gateway, um but I'm interested if anyone else can can help, add use cases here or for you know I I did a first shot at like the two use cases I'm familiar with, but maybe others can add or better explain those use cases.

A

I think someone was about to say something: I cut them up: okay, so yeah. If if this is a feature you're interested in the one that I am less, I I think this is. This is a real use case. The uh you know further filtering uh based on destination address, but it's not as obvious as some of our other much of our other config routing config, so yeah, um okay and the rest yeah, that's that's about it. Any any comments follow up on on these things.

A

This is this is 1086.. If anyone wants to help keep an eye on this pr, I expect we'll be getting some additional uh feedback in the coming days. So anyone can help with responses. Maybe follow-up changes whatever is needed. That would be great, and yes, this. This discussion with tim, uh led to a thread on the kubernetes api reviewers mailing list which I've linked in the agenda, uh and that is really this pattern we have all throughout our api. Is we have a type and a value field right? So you think of uh path matching.

A

We have type prefix value, slash foo as an example right and that's fine.

A

uh Tim was questioning if that was really scalable and what it came in the context of is the changes I made related to rewrites and redirects and that mailing list you feel free to read through the thread, but I tried to summarize it here: one union discriminator is still recommended.

A

It sounds like gone back and forth in kubernetes api conventions, but recommendation is still to use that, but the difference is uh a there's, a preference to use unique fields instead of a type and address in a type and value type pattern that we've used in many places in our api, so it instead, you would have a type address type and then ipsider hosting you know a separate field per address type, um and so this this is very similar to the pattern we're already using for filters uh but suggesting using it in more places, or at least new places, as we add them and redirects or rewrites came up because that's another thing that was following that pattern.

A

uh This at this allows for better validation. uh It allows for in the future. Like specifically, why tim asks about this? I think there's a comment on the pr too, is in our path, uh replacement logic.

A

There is future room for a substitution right, so you have a type a value and then, at some point in the future, you may want to say I specifically want to substitute this part of the path and that field would only be valid for some address types and tim's suggestion was well instead of that.

A

Why don't you leave yourself more room and have a uh allow for a struct type, so you have okay type of uh we'll just say rewrite type here, and one of them is subject substitution and instead of just a string, it's a strat.

A

uh I can spell the day and then you have a little bit more room to work within that uh structure, so that that is a high level pad pattern that came out of that thread. I think that may lead to more broad changes, or at least changes for how we add things in the future, um but also that's api reviewers thread, so you're welcome to respond.

A

If you have questions comments, thoughts, whatever there's only a couple, three different things in here so far um yeah, um but I I think I think that is a good bit of feedback and something that we should probably adjust towards as we're going forward with this api design.

A

Any any comments or questions about that feedback or that direction.

A

Okay, cool, I think we're on to the last thing then, and that is conformance test organization.

A

um I uh I had a conversation with someone internally that I work with who's been running conformance tests with us against our implementation, and they were talking about all the gaps. They helped identify all the gaps in our current performance tests, which I you know I recognize our conformance tests are not in in any way exhaustive right now, but it seemed like it would be helpful to at least have a path forward to understand the gaps and document the gaps in our conformance tests right now, so I made a very rough attempt at organizing these.

A

This is actually, I think, jeff. You had a comment asking about this a couple weeks ago, so very related to that too. um So I have a area conformance label now and I'll just drop into one of these to give a rough idea of what they look like and in this case, uh mike you're working on a pr that, I think, will knock off all of the things from route to service, and then we still have more for gateway to secret and we should probably still add additional tests here.

A

This is just my run through the api. Here's, the things I know we need to have coverage for, but if you come up with more things, don't hesitate to add to this list or add new issues, etc.

A

What I'm really hoping to get out of this is some idea of who can help write conformance tests, because this is a large project and it's also one that is easily distributed. It's one where anyone on this meeting can say hey. I want to contribute this one test. I want to contribute a test that covers cross namespace. Reference is not allowed by a reference policy uh from gateway to secret um and that's all um if, if that's something you are able or interested in contributing, that would be really helpful.

A

This again is just this just a way of trying to structure and get some organization around who's. Taking on these tests jeff, I know you mentioned you've been working or your team had been working on some additional conformance tests. Is there any overlap with the tests? I've been the the tests I've described in any of these issues and what might be coming from your team.

C

Well, there's the reference policy. Yes, it might check it.

C

I I don't know off the top, my head. uh What else we've got in plan that we haven't already checked? In um I mean we've got, I think at least two prs that are outstanding uh on for conformance tests that we've wanting to contribute yeah.

A

No, that's that's awesome and I would love to get to a place where every every implementation has contributed.

A

uh You know a sunset, you know even just one conformance test, but just to have a a truly broad set of contributors to our conformance test, because not only do we want everyone to pass conformance tests, but we want everyone to have a shared understanding of what to have have contributed to the definition of conformance, um so so we're all invested in the same definition um yeah. I know I I have plans to uh to help out with some of these myself.

A

I think I chatted with uh the person who's been helping us with with our docs review. uh She has been volunteered to start on one test from one of these items, but again this is. This is not meant to be. I know this is a overwhelming list, but this is not meant to be. You have to solve everything in one go. That's uh there's, there's lots of small little pieces to this and you can just pick a tiny little piece and work on that. uh You know.

A

I think that the matching is a good example of we have an example test for what it looks like for prefix matching. If you take that same pattern and use it for exact path, matching uh or header matching it, it should be a fairly good starting point and just reading a comment from mike, it's you're saying you may be able to help with the other set of reference policy tests. The gateway to secret ones, yeah that'd, be awesome, wow cool uh is, is anyone else uh interested in contributing to conformance tests.

E

A

Interested, oh awesome, awesome. Well, definitely, uh you know message. Anyone on slack drop, something in the main sig network gateway api channel. uh I I know I've just kind of I what I think I probably need a better starting point of here's. Here's how you write a conformance test and here's how you run it, uh but in lieu of that don't hesitate to uh just ask ask questions, um because you know I'll always want to make it.

A

uh You know, help help people getting started with contributing to the api um yeah yeah thanks uh thanks for being interested.

A

Cool and same goes for anyone else, don't hesitate to uh to reach out, uh and in the meantime I will try to have a slightly clearer definition of what it looks like to add additional tests. I I will point out that mike's pr somewhere down here is, is a great one for for reference, and I've lost track of it. Oh yes, here it is. Thank you mike uh for adding conformance tests. This is a really good example.

A

This adds several conformance tests, so you don't need to have a pr quite this big, but this is a great example of how to do it.

A

Okay um yeah. Thank you. Thank you again for taking notes and with that, whether anything else on the agenda that we should cover otherwise I'll get into just a bit of pr issue. Triage.

A

Cool okay, just uh I don't think, there's much! uh Oh there's a brand new one. Thank you mike um or not a new one, just yes! This is the one that we just discussed. Thank you um this. This all makes sense. um No, we didn't. We didn't even discuss this so mike. Maybe you can explain sorry.

B

Oh, this is just something that we've noticed, while going through all the route status stuff. Is that real condition reason is actually not in the api spec, yet um the type exists, but the docs. Don't uh it's something that we can probably add. Quick, yeah.

A

That makes a lot of sense. Okay, cool, uh it looks like everything else is a little bit older here, um so I'm going to let this one stay and then for pull requests. I think I've I think I have touched on everything pretty recently. If I've missed your pr or someone else has missed your pr like, if, if you are needing feedback on a pr that you've written, please ping any one of the maintainers in slack, I know that we're all busy and miss things.

A

So if if we have missed a pr, definitely let us know, I know several of the maintainers, including myself, are going to be out of the office for the rest of the week, so not purely coincidental.

A

But a lot of us chose to take this week off so I'll, be out for a good chunk of this week, but yeah, don't don't hesitate if you feel like your pr has been missed. It probably has so uh add a comment. uh Add something in slack and we'll make sure someone looks at it.

C

Does it help um if people who aren't maintainers uh reviewing and doing uh lg, uh you know looks good to me.

A

Yes, please and I I've been meaning to say that. Thank you.

A

I I yes, every review is helpful here uh I they're they're, so we have a formal maintainer role, but it it it doesn't really all that all that limits is who can hit a final approve, but it is incredibly helpful to have lots of people uh contributing uh reviews, because you know uh that this relatively small set of maintainers can only do so much and we want everyone to feel like they have ownership in this project and feedback and and can really make a difference.

A

I've seen some great reviews on some of these conformance tests by other people, and yes, please, please feel empowered and to review these pr's and all feedback is valuable and helpful, so yeah. Thank you.

A

Cool, I think that's all we have for today, um any any last things, or should we get another 10 12 minutes back.

C

It just kind of put in a plug here that for the route inclusion delegation uh gap, uh the documents the gep document itself is up there. um I actually uh updated it this morning uh because nick rewrote his uh the route status section, and so I merged his changes in and those are there. So that section is no longer. You know a draft from his perspective uh and so far I think rob is the only one who's who's reviewed made comments which thank you very much rob. I appreciate it.

A

Yeah I, this is an absolutely massive gap. I appreciate the efforts here- and this is this is a perfect example of where additional reviews would be very helpful, because it's it's it's hard for uh any any individual reviewer to catch everything or to really understand everything, but especially, uh if you're thinking about implementing this api.

A

If you can take a minute to look through here and say, oh you know, this would be really annoying to implement, or you know this or, if you're planning on using this api. uh Oh this, this would be confusing to use these kinds of feedback. Those kinds of feedback would be very helpful. uh Route.

A

Inclusion and delegation is at least from what we've heard from contour team, something that is very easy to turn into a very complicated thing to develop and implement, uh and you can you can end up regretting different parts of the api if you're not very, very careful. So this is one I want to make sure we have as many reviews as possible and we've thought of every little edge case. I know like looking at the size of this gap already it's, I think, probably our most detailed gap ever so.

A

Thank you uh and you know, I think it is already very well thought out, uh but again additional feedback to help us catch things now before we, you know, merge it and make it an official kubernetes api will be uh very, very helpful and appreciated.

C

Yeah, if we can just get a few more lines of stuff that we need to add in there, it'll be over a thousand lines.

A

I have a feeling we're headed in that direction. Yeah.

C

A

Cool all right, well, yeah, thanks for bringing that up uh again, that's uh pr1085 and uh any and all feedback is very welcome on this one. um But with that I think we've got uh everything for today. So have a great rest of your monday and uh we'll talk to you again next week.

C

E

Thank you, bye-bye.