Kubernetes Network Gateway API Special Interest Group, 5 Jun 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: SIG Network Gateway API Meeting for 20230605

Description

SIG Network Gateway API Meeting for 20230605

A

All right welcome to the Gateway API meeting for June 5th 2023., thanks to everyone for attending I know, we've been flip-flopping on dates and times for a bit, but thanks for uh making it through that uh and we're back to our usual time.

A

For now, uh though, certainly attendance is always helpful to keep track of, so we can know what works best for people and on that note, uh while we're getting started here, if you can write your name on the attendees list here, we've been trying to do this more recently, just to again track uh what times work best for people.

A

We've been getting pretty good attendance at the earlier times, but also good to understand the attendance we're getting at our more traditional time, which is now so, if you can add your own name to the agenda again, I'll drop a link in chat and go ahead uh with that said, this is a kubernetes community meeting, which means we have. We abide by the kubernetes code of conduct. uh Largely just means be nice to each other, so uh yeah never had an issue with that, but yeah. Just please everyone be nice.

A

uh If you think of it, please rely on uh zoom's feature to raise your hand, so we can make sure that everyone has a chance to say their piece as we go through this uh and with that, let's uh get to the agenda. Yeah first on the list is actually something that Shane wanted to remind everyone about. uh Shane may make it to the later half of this meeting, but unfortunately has a conflict right now. uh So uh he just wanted to remind everyone that this timeout skip is getting awfully close.

A

I think we talked about this last week as well, but it is uh just I think in in its final stages, I think Nick you may have already given uh LG TM, not quite but we're pretty close on this one I think um so. If you see anything in here that you don't want to merge, uh please uh please take a look at today or tomorrow, because I think our goal is to get this in this week.

A

uh That's the timeouts Gap. This includes two timeouts directly on HP route. One is a request. Timeout and the other is a per try. Timeout.

B

This is obviously there all right go ahead back in is the time out to the back end from the connection to the gateway to the back end, whereas the request timeline is the sort of overall request timeout that one is important for uh implementers to check out, because he is currently proposing that the request timeout be a core conformance field.

B

So if you don't think that you're going to be able to do that request, timeout, that's uh pretty important for you to sing up for seeing out now, because uh I'd really prefer not to be adding something to the API. That is core that not everybody can do or that most people can't do so yeah. If you are an implementer, please check that out.

A

Yeah definitely- uh and we have, unlike some of our other core Fields, there's a little bit of flexibility here in terms of how the timeout is interpreted and I. Think any conformance tests for this will just you know, have have something that takes longer than say a 10 second or whatever. Our test timeout is to return and ensure it it times out.

A

um But yes, all right, please please do take a look at this want to make sure the language in this Gap is something that is implementable by as many people as possible, um yeah, okay, so that is uh 1742, timeouts um I, don't think uh Frank is on this call. But uh thank you thank you to him for uh uh for all the work on this one now seeing a question in chat uh from Igor.

B

um Yeah so issuing of uh API tokens um again doing like uh jaw, style, user authentication or something like that, something that we've talked about, but it's a reasonably uh complicated use case to sort of Define in the broad terms that we need to talk about for the API. So right now we are planning it we've liked.

B

I certainly would like to have something like that happen, but, like it's not it's a way, the way um from sort of being implementable by our ways away, I mean months to yeah it's at least next calendar year before we will get to this um and even start looking at it. So.

A

I definitely would encourage if you're interested, we can try and find a link to Slack if you, but if you just scroll up in slack a week or so my my reference to time is not great here, but uh there was a discussion about this in slack and there's a few people that are interested in working on a gap around this. uh This is absolutely uh you know.

A

An idea, like Nick, said that we'd love to have in the API itself uh Envoy Gateway kind of got out ahead of the curve and has implemented this with custom route filters, which is great, uh but hopefully we can bring this back into the API and especially if you're considering you know, building something custom for your own implementation. If you could, you know, take some of that effort and instead redirect that to something, that's you know an API standard. Instead, that would be amazing um yeah, but this is definitely in scope for the API.

A

It's just not something. We've gotten to yet great question cool all right.

A

Next on the agenda, I don't think costin is on the call yeah, okay, so I will I will just try and very briefly cover this idea that uh one of the core ideas with this API and like many kubernetes apis behind it, is that even after an API reaches beta or soon to be GA, we will continue to add fields to it, and we will do everything we can to ensure that any new Fields will be added in a backwards compatible way and when kubernetes, what that means is.

A

It means the default value of that field cannot change the behavior in any way. So uh you can have values of that field that change the behavior. They just can't be the default. um Now. What this really sheds light on is that we need a way for implementations to understand that they are working with crd's newer than what they understand, and so we've built that into the API with a common label on crds.

A

That is the bundle version, and it basically says this is the version of the API you're interacting with, and then you can know pretty clearly, okay, there may be things that I don't know about, because this is a newer version that I'm aware of, and you can Surface a warning. Some such thing. uh This is something we need implementation guidelines for. uh We don't have that right now.

A

uh We definitely you know it's one of those things where the mechanism is there, but the guidance isn't sufficiently clear around this, um but yeah that that's at least my thought on this one I don't know Nick do you have anything to add or anyone else, yeah.

B

Yeah I think that um we've, you I, can understand how this might be concerning her people, but this is one of the things that the communities API guidelines, um the API conventions and the API changes docs are all about. Is making sure that you're, when you make changes you're making them in a way. That's um that is backwards compatible and a large part of that he's, as Robert said, is that when you add new things that the default value can't change Behavior the slightly sucky part about that is that you know.

B

If say, we found a security problem or something like that. Generally. That means that you can't change. You can't fix the security problem by and change by changing your default right, like you have to sort of say to people hey you've got to do this, don't think that should arise too much, because the security stuff we're doing has been about uh referential Integrity by reference. Grant then, rather than uh you know, uh rather than security controlling fields in general um and I.

B

Think the stuff that we considerably will be adding in the future is going to be extensions or new Fields, where you know it starts out slightly looser and you can tighten it down if you want and that's the sort of the approach that we're going to be going with.

A

Yeah makes sense cool, okay. Well, let me just keep on moving then.

B

I, actually sorry I did remember one just looking at that thing. I did remember one other thing. One of the things the customer was worried about was printing um in that. uh So a very quick tour through this.

B

um For those of you who don't know um by default, uh kubernetes cids have a thing called pruning enabled pruning is when, if you supply a yaml, for example, that has fields that the API server cannot deserialize, it will just drop them on for so, if you, this applies to sort of um adding new fields to the API, in that, if you, um if you are a user and you try and add a V1 Gateway object but installed in the cluster, is the V1 Alpha 2 version of Gateway, and there are new fields in the one, those those things will be thrown away and you won't get a unless the controller implements something that says: hey, you're, you try to apply something, and even then the controller won't see it.

B

Unless you have a validating and Mission Control that looks out for newer versions than the ones you support, which is which would be nuts um you you're not going to know that your stuff has been dropped on the floor until you get that I can think. This is another thing that we need to put in sort of user guides. You should always get your object back out of the API server to check that the value that you have is what you've expected, um if you're, not sure about the kubernetes I've got the crd version.

B

Unfortunately, there's not much, we can do about that one. That's an API machinery thing that is very baked into the ways work and it has and not doing pruning, has even worse trade-offs.

A

Yeah yeah, it is a not intuitive failure model where things just silently get dropped, but that is the unfortunate state, yeah, okay, so one more thing, uh just an FYI, but also you know very interested in comments on this I.

A

For those of you who may be familiar, kubernetes Services have an app protocol field on Port and one of the I think is kubernetes 127.

A

We introduced the concept of implement implementation, defined prefixed names, so if, for example, your company, your implementation, supports a custom non-standard protocol that isn't in our standard list, uh this would be one way to communicate that uh which is somewhat helpful, but it does mean that if you're trying to you know work on a service that other custom you know, implementations are also trying to build on top of it's really hard to do interop with this.

A

So a kind of the the next set the next iteration of this might be to have a list of app protocols instead of a single app protocol. For this, um this is something that lior has proposed in Upstream kubernetes. But honestly, although this is going through K slash K, it is you know uh the the people that consume this specific field, our Gateway API implementations and Ingress implementations, which there's a ton of overlap between the people that are implementing Ingress and the people are implementing Gateway.

A

So really trying to make sure this idea makes sense would be useful. uh You know more broadly so I think one of the other examples of this is even in a non-standard situation where you have an underlying application that supports you, know multiple protocols, there's not a way to define that today, having a list might get you one step closer to that, but recognize that every change like this involves. Complexity uh involves more Cycles to implement Etc so trying to gauge uh interest level and get some more discussion here.

A

I see that Dave, Arco and John have already responded, um but yeah, please add add your thoughts here as well. Would love to see uh where we go with this um to add a little bit more context. I think Dave. You have already worked on something like that will would add websockets, as you know, having a formal definition as an app protocol.

A

Is that correct not to put you on the spot or anything, um but there there's a corresponding get cap for that I believe coming soon, um so yeah, just just adding a constant for that cool?

A

Okay. So let's uh that's app protocol. Please again take a look um yeah all right. uh Let's keep on moving, then uh kubecon Chicago is coming up awfully soon. The cfp all always closes way sooner than I am ready for uh in this case it is June 18 that gives us less than two weeks from today.

A

um So just a reminder, uh you know the last couple coupons. We have offered basically a way to coordinate. So if you just want to reach out to Gateway maintainers myself, Nick Shane, any one of us or all of us, uh what we've done is you know if you're interested in speaking at kubecon, uh we may be able to hook you up with someone else.

A

You know connect connect, dots if you're both interested in talking about a similar topic or if you just have an idea, you want to talk about and want to make sure it's not overlap overlapping with another talk submission we can help with that uh or if you're looking for ideas, you know any any of those kinds of things we can help. You know make sure you know help uh review talk submissions as they come in I've I've been around a few kubecons by now. I think same could be said for for Nick Shane.

A

All of us, uh so we're happy to help. However, we can uh we've had you know great uh great attendance, great talks, yeah previous uh poop cons related to Gateway API. So definitely you know let us know and see how we can uh yeah see how we can coordinate on this I. Think Chicago is going to be a big group con for us.

A

We are hoping to be GA, buy that kubecon and so yeah should be lots to talk about um yeah, awesome and yeah cool that there's already at least one talk submitted, so cool all right um yeah. uh If there's nothing on that, I'll keep on going all right. uh Next steps for policy, we've kind of been circling around this policy issue for a while, and there have been some discussions- I've uh met with uh Flynn and Shane and Nick, and uh you know, there's been a variety of discussions.

A

uh There's been a PR there's been a GitHub discussion all around this topic and for anyone not following or not following very closely.

A

It would be very easy to be lost in this process, so my goal was just you know in the next couple minutes to summarize, where we're at I think there's broad agreement that we made mistakes uh in this policy attachment uh process in the sense that we let a a pattern which was policy attachment, stick and experimental for a long time without revisiting it as thoroughly as we we would like or building on it. uh You know, I think we we when we introduce policy attachment, we really hoped that it would go.

A

You know we would build all these really cool things on top of it to make it easier to understand, and unfortunately it just kind of sat and it's kind of experimental state for quite a while.

A

um So one of the things that you know we're working on is trying to avoid that from happening in the future, so developing guard rails around apis and patterns to ensure they don't just get stuck in experimental forever and Upstream kubernetes. We had a similar problem where Concepts would either get stuck in alpha or beta for a very long time and never graduate just because well they're they're out they they kind of work and we'll just leave it.

A

There, Ingress yeah, yeah, ingress's, uh Prime and prime example of that I think it's it's stayed in beta for around five years, which is you know forever in kubernetes years, so yeah, um so that that's a big, a big learning experience, I I, think policy attachment is such that there are. There are good patterns in here. uh There's, certainly some significant ux issues we're working to clean up. But there are you know people that have built apis.

A

On top of this, and who want to ensure that investment is, you know it's worthwhile and so again the plan is to continue with this pattern and improve it. So with that said, uh Nick is working. Nick and Flynn are working on an update to the Gap that merges in Flynn's great great work uh he's put in a lot of effort to describe some of the things that can happen with the current model and ways you can get stuck and trapped with it, uh and so Nick and Flynn are working together to Define.

A

That problem statement more clearly uh well in parallel, we're also working on some first steps to improve that I don't know Nick. Do you want to add any more context? Just on that that problem statement itself or.

B

Yeah, broadly broadly, for those of you playing at home, the the um problem statement is that uh we don't Define any ways to sort of improve the discoverability of policy, and so it's pretty easy to set up Social systems where um you know there are. There are impenetrable rules occurring on objects that you own, that you that you don't know and possibly even can't know, which is a very bad place to be out for you to experience the point of things PR, uh that's the uh 2015 I think is.

B

The number um is that is to sort of tell a story about uh about this and sort of illustrate some of the problems that can come up here.

B

um If you there's all, you know it's worth reading uh and story and stuff and then reading through the comments on here, um you know we've sort of worked through some of the um things that we've I think we've all been thinking about this here in those comments, um but you don't don't feel like you have to because the point part of the point of what we're doing is to summarize those comments back into a change. Another change to the policy attachment get now.

B

This is going to mean that the policy attachment Gap is going to be by far by like at least probably two two three or four times as large as any other kit, um and so you, but it is you, one of the things that it's, that I've sort of learned to be a bit more clear about as part of this process is that policy attachment, as Rob said, is a pattern not an API.

B

It's a pattern for making apis not an API itself, and so that's one of the reasons that uh doing design work, for it is harder than you might think, and it takes longer, and it's sort of you need to both be specific, but also not too prescriptive, which is a very fine balance to walk it's one of the reasons that it's been sort of hard to figure this out, um Additionally, the the problems space that is able to solve is sort of very large and complex and so being able to select the right tool to sort of tell people.

B

The information that they need about using it is not is not as straightforward as it might seem.

B

At first glance, the point- the the update that I'm working on for this, for that Gap is to take- is to take the stuff that we've learned in the discussions and the sort of some of some of this stuff was already in my head that but I just never done a good job of writing a town um about how hard some of these things are and try and actually come up with a suggested Solutions again, because this is a pattern rather than an API.

B

We're not going to be able to say, must and have conformance tests and have things core and extended in this. This is always going to be sort of a recommended pattern and say: if you do this, then you must do this or something like that. It's the best that we can do um you- and here are some recommendations for things to stop. Here are some problems that can happen, and here are some recommendations for boys to stop. Those problems that are happening is what we're sort of working on um the last. The last link.

B

That's in this session is Rob's the discussion that Rob opened uh in uh discussion in 2012., and that one is um uh that one is about collecting suggestions for ways that we can manage this tissue once yeah. If you sort of feel like you understand the issue and would like to make a suggestion there or comment on one of those things that would be much appreciated, I am pulling pretty heavily from that to come up with the possible solutions that we can then sort of evaluate in the in the text of the gap.

B

So these Gap is going to end up being a bit discursive because it's gonna it has to walk through the problems, to be able to explain to people why we need to solve the problems and how it's not as simple as it might seem before. It can then get to here's what we're actually suggesting so um yeah this. This update the update that I'm adding is already updating thousands of adding thousands of words to an already lengthy Gap. So those of you reviewing uh I'm sorry in advance, but there's not much getting around this one.

B

This one's got to be pretty detailed.

A

Yeah yeah that that's a really good summary. It's kind of it's gonna test the length of how long of a gap can we really handle here, uh but uh yeah I think it'll be good. I I want to clarify, because I realized. What I said earlier on may not have been very clear.

A

uh We, we are very much saying that policy attachment the model uh had you know, flaws in ux, especially discoverability I think is, is the key one that just keeps on coming up over and over again and so we're working to build on top of it by improving discoverability, improving things. You know adding things well, I'll get into ways we're trying to improve this, but I want to be very clear here that the the core pattern in gap 713 that the original policy attachment model is going to continue. We're just going to build.

A

On top of that um and then seeing a question in chat. Yes, are we planning to introduce any policies that are part of Gateway API um yeah, no definite plans, yet uh I think it would go a long ways in making it. You know easier to understand how to work with policy, but it's really on a case-by-case basis. I think initially we thought maybe timeouts would be that, but timeouts have actually landed on route. uh We've thought well, maybe the back end TLS the gateway to backend TLS. Maybe that will be policy.

A

That's still a possibility, I'm, not sure, um but that is very much one that could but yeah we don't have any definite plans. uh It's certainly a goal. If the right use case comes up.

B

Yeah I think that's the way I would put it there. It isn't nice to have.

B

I would definitely like to have some policy in like managed as part of the API bundle that you get so that we can have very clear sort of directions about you, because for that implementation, as as is an API, and so we can say you must do this, and you must do that, and you must do this and we can try to illustrate why you know why and how we would use the patterns that we've talked about in The Gap by actually having something concrete.

B

um That said, as Rob said, it's going to definitely be on case-by-case basis, and uh the problem here is that there's a very limited set of people who could currently build that thing. uh It's pretty much me and maybe Rob, um but the you know, part of the point of what we're trying to do is to expand that pool a little bit so that um do so that we can have other. You know that we're not deadlocked on this I'm waiting for Rob or my bandwidth.

A

um Yeah well said so: I just want to highlight a couple of the concrete things that we're working on uh in addition to to the Gap itself uh and and trying to update that to reflect current state and- and you know basically fold in the great discussion around Flynn's PR and the broader GitHub discussion uh also want to save it. uh Coupe cuddle plug-in is becoming a top priority.

A

uh This is something that can solve many problems that we've experienced with Gateway API Gateway API has kind of been on the uh Cutting Edge of a lot of these pain points for working with crds and part of that is policy attachment. Part of that is. We want to very easily see which policies attach to which Gateway resources- uh that's that's a huge win and something that I think we can solve, but I think any kind of plug-in is going to be much broader than that.

A

uh There are a variety of things that I would love to provide if we could customize our Coupe cuddle get or describe output, we can't in near as good of a way as I would like, as you could in Upstream apis.

A

uh So this provides us an opportunity to improve the ux throughout the API, so ideas very, very welcome. Gaurav is going to start on that I. Think First Step will be probably a gap just to describe the process, but this is something that isn't going to be tied to Gateway API release process.

A

It's just gonna be something that can improve the overall ux when working with this API and then one other very concrete change that we know we want to make. Is we need to update status? There are some big changes we can do in status, but one of the smallest I, think least controversial changes we can make is update, Gateway class status, so implementations of Gateway API can simply publish via status the kinds of policies that they'll support. This will help a plug-in to understand uh that you know.

A

Even if this policy is pointed at this resource, there may be a disconnect, because maybe that that controller is not you know supporting that uh that specific policy resource so I think there's a there's. A lot of changes coming that will help improve this ux. But yes, the the core of policy attachment is staying largely the same, we're just trying to build on top of it to make it a much better ux um yeah.

A

Okay! So that's that's a lot on policy. uh Any comments, questions before I move on.

B

One one more thing: I wanted to add there that um that Gateway class status name probably will actually be a list of all of the extensions full stop so policies uh any extra extra filters or any other places where you plug into air new extension points in the API.

B

The intent will be to list all of the extensions there exactly how I do that I'm, not sure I'm going to write a short gap on that, um hopefully in the next week, or so that one will actually will be short because I, don't think, there's much to discuss there. Yeah.

C

B

A

Yeah sounds good all.

B

Right anyone else yeah, it's I'd, be very interested to hear if anyone else doesn't even say on this one.

B

um So um Michaela asked them in Chad what about support for extended or implementation? Specific features are in gamer clusters. Yes, so the um that's the idea, um so the the idea here is that the Gateway class status will have a list of all of the other resources that your implementation that are relevant for your implementation.

B

So if you have like uh a custom filter or a params riff for your gateway class or a policy, a policy that works by a policy attachment, then all of those will be listed there in terms of um uh support for extended features in conformance profiles. That's the different, that's a different kind of efficient, so it comes under the conformance profiles discussion. The idea is that everything that we have tests for will show up in the conformance profiles in one way or another. Maybe you've opted in to say you support it.

B

Maybe you haven't, but implementation specific is always going to be implementation specific. So it's a bit tricky to do anything to concrete there in terms of status, but we can at least the the intent is that that the the place with the place where what I want to do is to have a a placing camera clusters.

B

But you can say: here's all the API groups and resources resource names of relevant objects so that someone can go Cube cat will get API, Group dot resource name, Dash a and see all of the the objects of that type in the cluster. If they have access but like that, that at least will include people in on things that they should go looking for for your implementation, and so that will be a something along.

B

The lines of you must publish a list of all of these things in here, regardless of whether the extended implementation specific or what that.

A

Answers your question, yeah and and I think that's yeah I think these two things are going to play really really closely together. I think the uh already existing conformance profiles Gap is largely going to have under its umbrella what what Nick was talking about of in Gateway class status, the features dedicate weight class claims to support would be there. I think the intent is for that to be all in the same Gap but I.

A

Don't Shane's not here to correct me, uh nor is Matia, so uh you know, but yes, that that that is definitely a parallel effort that we should make sure uh is, you know, uh compatible with and and make sense, alongside uh what we're describing here.

A

Yeah good good points.

A

Cool all right, I'll keep on moving then, um but always don't hesitate to add things in chat. If you or or just speak up, if you have anything uh next up, the uh I added an issue today, I just uh wanted to start this for the sake of discussion and figured I'd, bring it up here, but one of the things that we've run into as uh trying to build out any kind of automation around Gateway, API and and kind of Traverse the tree in a more generic way.

A

I is that you know route parent status could really benefit from section names in in the status itself. So for those you know somewhat familiar with the Gateway API tree uh routes attached to parents via parent ref and in the case of Gateway, you may just say: I want to Target this entire Gateway and then the Gateway. May you know you may only end up being attached to two out of I.

A

Don't know 10 listeners on that Gateway rough example, and it's remarkably difficult to understand uh and which of those listeners you've been attached to now. You can just look and make sense of it. Well, okay! It's this protocol and this host name. So it must be these, but it's it's not straightforward for any kind of automation to to make that and so I think it would be safest if we added that actually to route status itself, so you could say very clearly as a controller.

A

These are the section names I'm attaching this to um haven't thought this through that much yet, but just wanted to get some Initial Ideas feedback uh whatever on this before I went any further with this it just this feels like one of the gaps that we have right now as we're trying to Traverse Gateway API Tree in a more generic way, um any thoughts. Anyone interested in this or have reasons to avoid.

B

I do have thoughts, but I want to save anyone else's. First.

B

Yeah I think it's useful in chat um yeah, so my my thought is yeah like I agree that uh it does seem like it'd be useful um and that in general we do need to work one of the discoverability things that the policy attachment discussion has come up with is that you know we need to avoid needing requiring uh squishy midbrains to uh to actually parse the full tree and and figure out, what's actually happening. We need to have implementation to be publishing, what's actually happening, as in as many ways as possible.

B

However, the the downside to that is that it's very easy to run into scaling limitations, uh either about the number of updates per second or object size, and so we just need to be careful when we do this, that we don't end up pulling out the object size too much with a lot of stuff in status.

A

Yeah yeah, that is that's an issue that continues to to bite us is just you know, I think I think object. Size is probably okay here, but the real concern is like what you're saying is just a fan out right, the uh you know, you add one listener to a Gateway and it ends up. You know affecting end routes.

A

um I think that may just be a necessary evil here, but yeah just need to be very careful when we, when we make changes like this.

B

Yeah yeah I'll try and put a response on there too. So.

A

Cool all right: well, if I, if I, don't hear anything in the next week or so I'll, probably just move forward with this one I, probably in inform a very lightweight Gap, um but yeah feedback is very welcome.

A

All right! We've made it that far and we are into triage. So thanks everyone, uh let's uh I, think we should have time for all of these just uh quick glance through what the and and, as always, please uh don't hesitate to add things to triage. It's just a list of the things that I found in a quick glance. uh What's uh what's going on right now, uh this is a PR from Brian. That I think is really helpful uh and I was amazed.

A

He made a markdown table that actually renders well uh in our reference dot docs as well, so who knew that that's a possibility, but this feels like a pretty useful mechanism to me to describe how rewrites work Brian had some really good questions and I think the specific one that was of interest. Is this specific case here that I want to highlight and ensure that this is compatible more broadly with other implementations?

A

But if you have an incoming request to Foo with a trailing slash- and you have a prefix match on you- know, slash Foo, should the modified path also have a trailing slash. I believe this is just by default. How it's going to work in Envoy today, I interested in other implementations as well here um I think this matches. How I would expect this to work, but I do want to highlight it because it is. You know you.

C

A

Significant Nuance here and there's some room that some implementations, especially non-onvoy, make based may be doing something different here.

A

um So if you have a chance to take a look and and see what your implementation is doing today, that would help the spec itself. Right now is fairly open-ended, as in as far as how this specific case would be handled, um you know, I think. Basically, every other case is straightforward in my opinion, but this one is challenging.

A

So yeah just would appreciate.

B

B

Always uh always always biting us: yeah yeah.

A

uh Dave, can you give.

C

A

Lib redirects on trailing slash.

C

D

C

Weird Nuance of the like of the um the muxer, the default muxer I, think if it's I have to dig it up, but if it's a trailing slash or it's missing, if it's a prefix or something like that, it will do a redirect to the one without it um so I can I, don't think it catches anyone, but it's just something that isn't particularly documented. Well. Okay,.

B

A

Yep cool great to know all right, well, yeah, just uh please! uh This is really just a request for comment on this. One I think I may be the only one who's reviewed it so far, but uh additional reviews would be very appreciated and especially if you're uh working on a non-onvoy based implementation reviews would be very appreciated, because I want to make sure that this uh Works, broadly here cool.

A

All right next up is uh just I think. The very last thing I wanted to cover on this routability Gap I think this is basically mergeable or in the like the tiniest little bit of knits left, um but right now, I, just I think this is the only remaining open conversation and it's saying that um if a Gateway is mutated, I and you know, as gets into an invalid State, all three conditions accepted, ready and program must be set to false, uh and this I think we just need some broader guidance somewhere and I.

A

Don't know if we already have this but I know there are some implementations that are going to take this state and not want to tear down the Gateway itself. They'll want to, you know, enter an invalid repair state, but not necessarily eat completely. Tear everything down and I feel like.

A

We probably need some way to communicate that that doesn't need to be solved in this Gap, but this Gap is maybe being very specific, more specific than we've been before about how a situation like this should be handled. So that's kind of why it's it's come up in this context, um but yeah that that's that's, I, think the only little bit that feels left on this one I think it's nearly resolvable with the the state of comments at the end of the thread, but would appreciate just a little bit more discussion around this.

A

All right uh next up it or go ahead. Dave sorry.

C

I'm just gonna kind of mention um something I mentioned in the thread following where, um if I I see conditions switch to false I, wouldn't assume some underlying infrastructures like um deep revision and it kind of made the point where, like I, don't want like a half state where, when I see like a condition with an older generation that that sort of is meaningless to you know, because since then the controller is turned off as an example.

C

um So that's why I kind of suggested like of.

C

um The underlying implementation.

B

I think the card- sorry, okay, I I, understand but I- think the for some of them programmed in particular, aren't ready, is actually deprecated, so we do need to remove, mentions of that, um but bringing in particular it's actually defined as having in relation to the underlying infrastructure that I.E that there is underlying infrastructure and it has been programmed like that's the, and so you know if you are tearing it down like like it has been programmed with that version of the config right.

B

So there's there's a few assumptions in there that, like in a way that we Define it um I understand that you- and this is just again one of those things about writing a spec- is that we've got to go back to the way that we Define things and if it's not exactly the way that we Define things, then someone's going to misinterpret it and so um yeah so I think it's really important to say you.

B

The I suggested in that thread that um we should have a way to say you know hey. If you're on implementation, you may leave the leave the infrastructure around. If you want probably, as Rob said, I think that we need to have a standard way to handle that, like a a way that you can have a condition that has the current observed generation and says you, the the you know, there's there's problems with the current Observer, the current observed generation of the spec.

B

However, there is an old version sticking around somewhere um and you you should. You know, check into that right, like just you can't we we're not going to be able to tell you what the old version of the spec is but like. If the implementation is doing it, then there needs to be a way for that implementation. To say, like hey, uh you know you, you know, there's there's some infrastructure lingering around. That is not, as is described in the spec.

C

I mean you can see yeah, it kind of sounds like you want a separate Edition program. Okay,.

B

That that one is that one is absolutely a separate condition. That's like a an optional uh extended at best, maybe even Implement extended. It won't even be extended. It'll be implementations because there'll be no conformance tests, but it will be uh if you are, if you do leave in infrastructure lying around. That is, that is stale.

B

That does not have the the current spec, because the current spec is irreconcilable for some reason, then you must put this condition on uh as a ux member but yeah again like I'm in general, like -1 on that, because it means that the declarative system is no longer declarative like you, but you know: I acknowledge that not everybody is as willing to be as hardcore about that as I am, and some people prefer not to blow things up just because someone asking them to be blown up.

A

um Yeah I'd say it's a tough balance, but you know for for infrastructure that takes minutes or longer to spin up and down uh it's a it's, a pretty rough it and you know, may spin up with a completely different IP or whatever it's a pretty rough experience to to have that happen. For a you know, accidental config mix-up, whatever um I I, want to avoid blocking this gap on.

B

D

A

Unrelated and so I was trying to be clear here that right now the language in this Gap doesn't leave room for another way. I, don't know that we need to solve the other way. We just need to leave that kind of out somewhere that we can do something else here, um not quite sure how that works, but I just I. You know I want to make it clear that we don't need to solve that here.

B

C

B

Yeah, that's a good idea. That's.

C

What I was going to.

B

Say: yeah yeah um I I had a bit of a suggestion on there as well. I might clean that up and sort of add it on to the end of the thread.

B

um Basically saying the the meat of the suggestion will be. Implementations may do this. However, it has significant ux issues um that that remain unaddressed and will need to be addressed in a separate work item. If you want to do that yeah you know so yeah it does. It says you may but be aware that there's problems with that approach.

A

Yeah yeah so I think what that basically means is. uh We would trans yeah, I I can follow up in a comment, but it sounds like this would become a should and then we would have a May that describes. There may be this other way. That is undefined right now, yeah anyway, I'll follow up in a comment.

A

Don't want to get derailed here, um but yeah thanks a ton for your patience and getting this Gap through I know it's had a ton of comments uh and you've been working a lot on getting this one through so I think we're almost there um yeah.

A

Cool all right next up is uh this one from Arco I, don't know is ARCO on the call. No he's not uh so I won't spend much attention here. It's just uh a heads up that Arco is uh working on a new Gap. That uh seems uh simple enough, I think about what, where Candace is working on?

A

Basically something very similar to this, but from Gateway to back end. This is from client to Gateway um so yeah. This is really just defining goals and non-goals at this point, but seems straightforward and uh I guess we can just ask more questions on the pr itself.

A

And uh the final one I've got for today is uh yeah in cluster Gateway deployments. I, don't know if John is on this call. Yeah I'm.

D

Here he's naughty.

A

Oh, you are okay, um yeah I know you. This went through a long round of feedback and then I think you pulled stuff out. So it's a lighter weight. Now. uh Can you maybe just give an update of uh what.

D

We should yeah. Can you look at the last comment? I I want to make sure I'm not getting this mixed up, but I think this was pending re-review or more comments um and that I felt that I had addressed all the open comments, but there could be new ones on next iteration, of course. So uh if you're interested, please take another look at it. When you have some time.

B

It's on my two review queue: John, that's a that's a big cue! So sorry I haven't got to it yet.

A

So, and just just so I remember, this is basically setting uh three thing like it's: it's adding to the infrastructure stanza, which has finally merged, and this is adding labels annotations and some way to like attach to a service or some kind of infrastructures that the scope of this one.

D

That's the API changes I believe, but it's also uh defining a bit more of.

C

D

On what you should do, if you are an incluster deployment which.

C

Is not necessarily API.

D

Changes but more like you know, you should deploy service that should be named this way or I. Forget the details. Really it's been a while since I yeah got the needs of it, but that's that's the intent, it's kind of like if you were in cluster deployment. Here's your guide on how you should Implement things, and that involves a couple. Api changes, but also it will kind of be I should probably live. I, don't know if we have an implementation guide, but if we do then.

B

D

Should probably be to update that, if not, then maybe we should make one.

B

D

So there is an implementation guide.

B

That's very, very skeletal at the moment that I have a long list of things that are on my list to do and to put in there but um yeah like you know it is with writing a guide. It needs to be uh just so, and I have not had a bad breath to word. Smith yeah uh correctly, yeah.

A

um And one so one last thing here: I I, think one of the details in this Gap is that it defines how annotations and.

B

You know I think I don't think is. Is that in is that still in here John or did we take that one.

D

Out this one has a infrastructure that annotations and infrastructure at our labels: yeah, yeah, okay, okay, right.

A

So what and- and that's just saying these are hard-coded values that I'm going to pass through like it's, not it's, not a list of you know I want to pass. You know an allow list of these specific labels on the game.

D

Oh yeah you'd, put on your like I want label who equals bar you.

C

Know: okay, yeah.

D

Super internal excerpt manager, internal annotation XYZ, whatever yeah got.

B

It okay, this this doesn't handle any of the stuff. We talked about on one of the other games about you, infrastructure, using infrastructure on Gateway class and how you would override those there's, a bunch.

D

Of other stuff, that's correct: it does not address that it.

B

Does not need to I'm not suggesting it should. uh I was just mentioning for Rob, because that was also a conversation that we had very recently about labels and annotations and the infrastructure stanza um yeah, so yeah I I, don't think it should I think that it's fine for this. To just say there is a labels annotation standard on on the gateways, infrastructure, and it is, and those are straight copied onto any infrastructure that is provisioned as part of the Gateway, which I think is acceptable.

B

That way, we don't have to worry about uh merging map, string, strings and stuff like that until another day. Let's get this one in first.

A

Yeah um yeah I I think since this this specific Gap is so focused on in cluster deployments, which is not primarily what I work on. It would be helpful to get reviews from others here as well, just to see that it's actually useful for other in-cluster implementations here.

A

um I can I, can review and and have reviewed some, but I would definitely appreciate some reviews from people that are a little bit closer to implementations. That would use this.

B

I think the tldr here for other in-clust implementations is the whole one of the points of this is to make it so that, yes, there is a way that users can specify in a standard way. You know I am running on my. My cloud is running on AWS and I want to be able to ask for an ALB or an NLB and those those things live in service annotations as of today. This is the way that you will be able to do that without having to write code to handle all the possible annotations yourself.

B

So I think that most in-house implementations will be very happy to have this in general. But, yes, please have a look at it yourself um and, as I said, I will be reviewing this one as well, but yeah I definitely think as many people as possible should review this one.

B

And does anyone watching the recording uh you know yeah definitely hit that one as soon as you can, if you're an implementer I see, there's a bunch of implementers I've, already reviewed it, but now's the time review, hello.

A

Right, okay, well, I, think we've made it to the end of our meeting with a couple minutes to spare. Thank you, everyone for great discussion, uh we'll talk to everyone next week and until then have a great one and we'll see y'all online.

B

All right see ya foreign.