Kubernetes API Machinery Special Interest Group, 28 Apr 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Gateway API Meeting (APAC Friendly Time) for 20210428

Description

Service APIs Meeting (APAC Friendly Time) for 20210428

A

All right uh we're recording this is the gateway api meeting last one in april and the last one for v1 alpha one. I think I wanted to highlight a couple community blog posts, you've, probably all seen I cncf uh yesterday, had a blog post uh covering contour and gateway piano, which I thought was really cool. I think damian you're, one of the authors on this one yeah and uh so great, to see some more coverage there.

A

uh There there was a kubernetes blog post, which many were authors of also great, to see um so yeah, just uh highlighting those, and I think, there's going to be more coming where that's with the there's a I know. On google side, we've gotta learn kubernetes with google series, which is gonna, be covering gateway, api and tomorrow we're hoping to launch public preview for our implementation, and I imagine, there's plenty more outside uh they'll, be coming in the next couple weeks. So yeah, that's exciting, um also of interest in the community.

A

You may have noticed that I think it's a data wire, but the project project, formerly known as ambassador, has built in support for gateway now, so that that's exciting to see um yeah, so just random community tidbits. But uh let's move on to actually talking about meeting times a relatively limited group here today. So I I don't know that we can make a cons and we can make a decision on this quite yet.

A

But I wanted to highlight that there is that straw poll. I think everyone here has responded to it already. I would like to shift meeting times sometime soon I the leading contender based on pacific times. It would be mondays at three which we had. Eight people respond, yes to, and similarly tuesdays at 10 had a fair amount of yeses and tuesdays at 10 is particularly interesting in that it enables a larger chunk of the european maintainers to show up so mondays at 3 is more friendly for aipac and thursdays at 10, more friendly for europe.

A

So there's not a lot of overlap between those two meeting times, unfortunately, but that does cover everyone. Who's responded to the survey so far, um so I'm I'm kind of leaning towards that kind of split. You know alternating back and forth, but I know that does add some confusion and some overhead. So if anyone has strong feelings about when we do meeting times, uh let me know hey rob.

A

I'd like to audio is uh broken. I think yeah, okay, one! Second! So if anyone has been saying anything, uh it is okay. Now I should be able to hear you sorry for the confusion, rob.

B

Can you hear me yeah, okay, great thanks, I was, I was gonna, say it'd be nice if we could actually proceed with uh both the monday and tuesday and just alternate, because I know we've got uh several contributors that are out of australia. That would be unable to ever attend if it was at 10 a.m. On tuesdays,.

A

Yeah- and I think I think that's the problem- we have right now with this meeting time. Although we've had some attendance from nick and james, it's been pretty sparse, yeah.

B

A

Yeah, so I.

B

Thought if we could at least alternate that would give them an opportunity every other week to give them a viable option to attend.

A

Yeah yeah that that's what I'm thinking and I and we've also started to get more involvement from you know, traffic and, I guess, even to to some point glue, which would be east coast but kind of the earlier time zones, uh and so getting some more involvement from them would be good if we had a morning well morning, my time meeting as well, so that that's kind of what I'm thinking between the two, you could also argue that the most people responded with mondays at three, and we could just do that, uh but I'm interested in trying to provide opportunities for everyone to attend.

A

So I I think it's worthwhile to flip between these these times.

B

Yeah, I agree with that and I think we're gonna see additional participation after kubecon and it would be nice to have a little more time zone coverage.

A

Yep agreed um related to kubecon, uh it's a a good segue here uh I was chatting with nick yesterday on slack and one of the things that he'd brought up is.

A

It would be helpful if we could get together and try to figure out try to try to develop some kind of consistent approach to how gateways are mapped within cluster proxies. uh You know I I spent some time preparing for kubecon, actually testing out all the implementations. I could, and I saw a fair amount of variation in how in-cluster proxies mapped the concept of a gateway to their implementation.

A

uh You know whether it was like a single gateway per deployment of a control plane or whether you just merged gateways together or whatever it was. There was a fair amount of variation.

A

uh I'm not saying that we need to you know specify it has to be exactly this way, but it could be useful to get some of the maintainers together that are working on these in cluster proxies and see. If there's some common ground see, if there's some guidelines that we can provide whatever that looks like so, we have an easier task when it comes to conformance and consistency across these implementations.

C

It's basically giving names to categories.

A

Rob yeah yeah giving names to categories, but also trying to identify patterns that make sense or don't make sense, know you know like uh there's definitely variation, and I I know it sounds like contour is still trying to figure out what the correct mapping is and that's my understanding with some of the other implementations as well.

A

So it could be interesting to try and just focus on that, and the reason I'm bringing this up specifically is that nick mentioned next week he's going to be working on eu time for the sake of kubecon, which means we have an opportunity where we might have overlap with a larger chunk of in cluster proxy implementers uh sometime next week.

A

uh So I'm interested in trying to get something organized there really informal, but just try and get in basically what you know. One one issue we have right now is: we have maintainers in europe and australia that never get to talk to each other. uh Well, not formally in these meetings anyways, uh and it would be great if we could try and bring everyone together for this opportunity.

A

Since it's kubecon, even though it's virtual uh to try and make some connections and some you know best practices or recommendations for how this can be done, um so I don't know if anyone's interested in that I I can follow up later in slack, but I just wanted to bring this idea up. I think next week does provide a good opportunity for these kind of.

A

I know it's still a virtual kubecon, but we can still have these kind of sessions and, just you know, brainstorming ideas, uh especially when you can get people that don't usually overlap in time overlapping.

A

So yeah is anyone interested in that that kind of.

C

Idea yeah, but do we have this meeting overlapping with that? Maybe we just yeah switch the meeting times and then that's just the meaning you're. Basically.

A

Saying there's an.

C

Extra meeting or.

A

When I'm really, I don't even know that it needs to be a formal meeting per se, and I what I want is I I don't want that meeting to get there's a lot that we need to cover in our community meetings, especially next week. I think next week is going to be our kickoff for v1, alpha 2 and there's a lot of content to get through and okay mate.

A

Maybe that's naive. Maybe there won't be many people around, because it is kubecon, I'm not sure, but what I really wanted to do is I didn't want to distract from.

A

I wanted to have a meeting that was entirely focused on in-cluster proxy implementations and trying to find some common ground in between them, because our meetings really cover everything from issue triage to you know v1, alpha, 2 planning or whatever it happens to be, and I think that's valuable, but in this case I just wanted to take advantage of overlapping times of maintainers for a very specific topic.

C

Yeah, I think, though, like if we want to get all of the implementers. I don't like. Maybe it's worth floating a a shared dock first and then have everyone come in because having everyone come in.

A

Yeah you're right even.

C

If it's like kubecon, where people supposedly are gonna, be awake at that time period, it's like not a guarantee.

A

Yeah yeah for sure, okay, well, yeah I'll, think about that some more. If anyone has ideas about that or if this is something like that, others have been thinking about more, you know whether it's contour or istio or traffic, or whatever, I'm just interested in trying to find some some common ground among these implementations um so yeah, I think you're right bowie. I think the the next natural step would be to to have a doc where we can start brainstorming, and maybe that turns into uh some kind of natural uh meeting.

A

Okay uh with that, I also wanted to throw out here I've just kind of by default been leading organizing. Whatever these meetings, I don't have any need to do that if there's other people who want to rotate with me or be part of this or try it out once or twice uh by all means. If anyone is interested just let me know I, I don't need to be the one to do this.

C

So I think, like rob, maybe it's worth um putting in the stock, somehow the next few sessions and then people we can people can sign themselves up.

A

C

A

Wanted to rotate yeah, I I agree, and I I don't think well we'll see.

A

I don't know that we'll have time to cover this in this meeting, but I have we're about to transition in what I think is a pretty significant way in these meetings and in what we're focusing on on gateway to v1, alpha 2, because we've intentionally been focusing on these kind of smaller iterative changes in these meetings and our work on the api and once v0.3 releases tomorrow, that all switches- and we start talking about bigger picture things all over again and uh potentially significant changes.

A

And I I have a few ideas queued up. We have some issues queued up that are, you know, labeled breaking change or v1 alpha 2. uh and I do think it would be good to have some kind of structure around uh when we discuss those. So maybe we can we. I think we have enough concepts. We want to get into v1 alpha 2 that we can probably schedule out meetings uh a few a few at a time kind of thing and then, if there's like you're mentioning someone, that's interested in leading discussion on a topic.

A

uh That'd be a great good place to volunteer.

C

Yeah so rob: um let's see we cut v1, basically, today or tomorrow I see tomorrow, um yeah so like between that and the next session. I think we should you we could just use this dock. There's no need creating another dock to throw down those big meetings, and then we can schedule them so that that sounds great.

D

C

A

Cool all right, let's move on, then, um let's take a look at the milestone. I think we're awfully close here. I I know harry has uh a lot of meetings this week and I don't think he's going to be as responsive for the next couple days, but he has done incredible work on his validating web hook, and I think we can almost consider this one closed uh just this morning. We finally got the last test in for pr merged in.

A

I think that may be the final piece. We may need a small pr to fix a couple things in this repo, but I think it's awfully close, and this certainly does not need to block v1 alpha 1 in any way, but it's exciting to see it just about ready.

A

um This is one that manuel took on with the this pr, and I think this one is awfully close as well. This is uh cleaning up documentation around gateways, routes and tls, and I think the main concept here is.

A

Is actually showing this idea of given this listener protocol? This is the tls modes and routes that are supported this. This is really just a summary of a conversation of a good slack thread from a few weeks ago and just wanted to make sure it got recorded.

A

I think this. This is not everything we need to say about tls, but I think this is a good addition. Does anything for anyone looking at this for the first time, does anything in here look wrong.

D

I was just going to mention that um we should move this into the console like we should take this out of the guide and move it into the concepts this pr, like, I don't see any issue with you know, recording it in a guide now, but at some point we should move it to the um concepts.

A

Yeah, I was yes, I I agree. I had a similar thought when I was looking at this pr and I said wow.

A

This doesn't feel like it needs to belong in a guide, and then I was looking for our concepts tls and we don't have one and I looked at our tls guide and it feels pretty similar to a concepts page and less similar to a guide but like, like, like you said, doesn't need to happen now, but I agree that this feels somewhat out of place as a guide, and maybe we need to split this up.

A

But for now it it's good content to have.

A

Okay, cool I'll uh I'll run with this. I think he had just a few little follow-up items to uh do on this. There were a few I added a few nitpicks at the bottom, but uh otherwise I think this should make it in in time uh what else is in the milestone?

A

Oh yeah, I think the last one belongs to you.

C

Yeah this one should be very simple: people can take a look at it. It's basically taking that comment at the bottom and putting it in the concepts or guidelines uh we haven't made it consistent in the code base because we have to go and fix it, but I would take that on. As like a separate thing, I don't want to go and change like a ton of stuff right at the last moment.

A

Yeah, so I agree with that- I think one thing that's going to be confusing here is our docs right now have become the concept of a custom support level, but I don't think we do a good job of just defining implementation specific and I think we're using the two terms interchangeably here.

A

uh I maybe at least in terms of docs. We should just either update our current reference to custom to be implementation, specific or update this to be custom. I I don't. I don't have a strong preference for naming here, rob that the whole point is that.

C

This distinguishes it from custom, so we, if you're, proposing the ladder, then actually calling this out, is a little bit strange.

C

Okay, so cause it says right.

B

C

Wait just go to custom yeah, it says. Custom features will not have api types in schema, except via generic extension points.

A

Okay, so yeah we've we've really been misusing that yeah, that's confusing, because we we definitely have custom listed, as conformance uh where we may want implementation like it's not extended.

C

uh So I think, like wherever custom is just saying that it's like: where will you go and look for the custom stuff? It's not gonna, be here, I'm just you know we're just saying that, but it's only supposed to appear in the documentation and then for the generic extension points. That's where it says like hey your custom stuff will be here, but it should not be used in a particular field that exists that then we say well. Actually I take that back.

C

I think like we need to look at where it exists, because I don't want to make a blanket statement.

A

Yeah, so I just because I've been working on hd route recently and dealing with the specific conformance, but I think this is a good example of us using the two interchangeably.

A

So you can see support implementation specific here, for that one is custom.

C

Because it is a generic reference that could go to something else,.

A

So if that makes sense so custom, but that, like that's an api type, so let's say.

C

Okay, maybe so, for example, regex is a good implementation, specific thing, because we define everything else around that, except for the nitty-gritty, behavior of the the regex.

A

C

Right, that's like a good example. I think this.

A

C

Custom because yeah this one should be implementation specific.

C

In fact, implementation specific is just right. There.

A

Right, that's so implementation specific is, is actually a a path match type or a param match type. I mean we use the same types for a variety of things here.

C

So I think regular.

A

C

Was originally intended to be extended because I don't know if everyone was able to support it, but the behavior we said would be implementation specific just because it was just too hard to generalize or it's like there's very little point to generalizing.

C

um This is not custom, because it's not like you have a a reference to another resource that could be of any type. I think that is the most clear distinction is, for example, that certificate ref actually could reference some crd that someone has produced from somewhere else. That's why that's? What's meant by it's, not part of the type system.

C

A

Okay, so so we went and introduced an entire type, an entire struct type shall we say that was custom conformance, but we might have a match type or something like that. That was custom conformance, because that referred to something like that was implementation, specific.

C

Yeah implementation specific in quotes- or it's just specific to the implementation- let's just distinguish that, um what's meant by custom, is that it's basically just all the random extension points that we have everywhere and to actually add a custom feature requires you to use that extension point.

A

Okay, so should we be calling so should we ever have support implementation specific or should we just have support custom everywhere? Maybe maybe I'm misunderstanding. This.

C

So here the support for different resource types will be custom like we don't say anything about it, um and but we note that this is a place where you can introduce different types, where implementation specific can't be a support thing. uh It's I guess it's like. We define almost everything about the feature, except for this one aspect and that aspect we say will be implementation, specific, behavior.

C

Okay, if it's a subtle difference, I think the fact that it appears in the schema as not a reference to something some other types indicates to me that it's talking about implementation, specific behavior, not.

C

C

Is defined as like it's going to refer to someone else's crd, I think like, if you boil it down to what it probably results in.

A

So yeah, so I guess my question is if we are going to say that both custom and implementation specific are valid values here, it feels like I'm.

C

Not saying that implementation specific is not valid here,.

A

Okay, okay, sorry, I'm gonna send it okay, so it really should be custom. Okay, I got it yeah.

C

Support of other types is custom like it's like you're, free to add other resources there. Okay.

A

I yeah that that I think that makes sense. uh I'm interested uh and anyone else does does this match what you were thinking here.

C

I do think like we need to scan through just to see where we've we've put that to to make sure I was as I was trying like 10 minutes ago. I was like making a blanket statement and I realized like we really need to look at it.

A

Yeah, I do think we've used support type custom more than implementation specific, but I'm not sure.

B

I mean we have like the way that I view this is support colon, but we're talking about the support level right I mean and building conformance tests around those different support levels, and if we go back to the beginning of the project, I think bowie. This is even um a slide that you put together. That has the blocks with the arrow saying you know, gravity or something like that right and if I recall correctly, the outer was custom and then it was extended and then core right, and so I think, to simplify things.

B

Is we look at it as like? Why are we even specifying support here right? This is to identify what level of support that you know a user can expect.

B

So I think we we simplify or standardize on the three support levels of core extended and custom.

C

Yeah, that's true, I guess like um we should boil it down to what does this actually mean? Because let's say you had you're writing conformance tests like what would you do for a custom for custom here? Would it mean that maybe this is just being very picky like?

C

Does it mean that, for example, let's say you had regular expressions as extended? That means that if you support irregular expressions, you can specify regular expressions in a portable way, but the behavior of the regular expression is not the same versus custom means that you just you could do anything. I guess this is less relevant here, because we it's it's very specific here.

A

Yeah, I feel, like anything, that's listed as support. Custom just would not be covered by conformance.

C

But we kind of.

A

Do want to say.

B

That it would be, but it would it would.

B

C

Yeah, I was maybe implementation specific is just like a very narrow thing where we say that for the most part it's going to be portable and then there's this one aspect that we say: hey, that's implementation specific, so we can make it generic at least that's the way. Philosophically, I'm thinking about.

B

It the way I see it is, is that whatever fields use, if you know if it's core, then it would be covered by the you know the core uh conformance tests, uh my go ahead, use another field that is extended. Okay, well, that's covered by the uh the project's conformance test, and, oh you know I I'm using contour as my implementation, I'm using particular fields that are implementation specific. I would expect that contour would then provide those conformance tests, or maybe I don't know if those implementations are custom.

B

uh Conformance tests uh live in the project. uh Have we covered that before? Where you know, implementations like contour would then write their own custom conformance tests or would those live in the particular project's repos? I guess that's.

C

B

Think, like for custom.

C

It seems to me to make the most sense that it lives outside here. I think um we have the the original intent is that regular expression is extended, but the behavior is implementation specific.

C

If that makes sense like it's not the case, that regular expression, because it appears as the api type like, we need to say how what it means. It can't be custom because custom.

C

Right, it's like a little bit of a nesting here.

A

Okay, yeah, it seems like the big follow up here, is to run through and actually look for, support, type implementation specific. I think it's fairly rare that we use this, and if it is I can, I can make a quick pr just to update those to use custom, and I think we also have to follow up on actually reviewing this kind of description of implementation, specific, which is more I this. This is like a decorator on custom is that is that correct? No.

C

It's not decorated on custom. Sorry, if you read it's a decorator on core and extended, because we live in a reality where things are like mostly, but not entirely portable. That's the whole point of this is that we.

A

Can basically define.

C

Like, let's say, regular expression was a bit more complicated, but the only thing that wasn't portable was the nitty-gritty of how the match works right. You can define other things. Let's say we define like case and sensitivity or something I don't know, but like those things we can extract out to the portable layer, and we have this carve out. That's like well, you need to go you can you can describe it generically in this aspect of it, but you need to go. Look up this one piece of it and that's well defined.

C

That's what I was saying was implementation specific, because then it lets us cover more surface area with the api, um as opposed to right like if, as soon as one aspect of something is like not super portable everywhere, then we just can't talk about it at all. That was my concern.

A

Okay, so really what you're proposing here is almost a new concept of that would allow us to elevate some concepts that we currently just call custom, because they're not fully portable to extended implementation. Specific.

C

Like it would be a shame if just one little thing caused it to not be able to be extended,.

C

And we know like it's just the nature of the thing, a regular expression being this canonical example, of where it's like it's already too late, and we don't foresee the community kind of fixing it in any way, unless something amazing happens.

C

But at the same time, like everyone, has regular expressions and did not give the user that knob and to just basically say they have to say just implementation. Specific just feels not right.

C

So that's why we have regular expression here, specifically as a type rather than just say. If you want to use our expressions, you have to just go implementation specific.

C

A

All right, uh I I think I think this concept also may come into play for, say, timeouts or some of our extended configuration where timeouts are similar in concept, uh but have somewhat significant differences. You know what, when the, when the time starts and ends that it's measuring as an example yeah.

C

I think like we have to use it very judiciously, so it's not like we can just kind of slap it everywhere, but even just a bit even quote-unquote portable is not like. There are some leeway right, so I just don't want to like end up in this situation, where some tiny mismatch then kind of voids a whole useful thing for the user. I I think, like in this case, being able to specify that it uses. Regular expression is like very useful.

C

A

Yeah, okay, that makes sense I'll uh I'll, take a look at this um and if anyone else can take a look as well, um yeah, okay,.

A

A

I'll uh yeah, let's, let's keep on moving, because I want to make sure we get to our 030 release discussion here tomorrow. I want to make sure that there's a changelog pr, that's ready to go.

A

If anyone wants to volunteer to take that on, I feel free, I otherwise I I can do it, then we need to take and publish the release. And finally, we want to make a pr to actually flip everything over so that it's clear that v, one alpha one is frozen and v. One alpha two is where all additional changes go, and so I I wrote down what I think this process should look like. Obviously we want to generate a new v1 alpha, 2 api.

A

I think we want to copy our docs to v1 alpha 2 like so. We have a new directory where we can continue updating, docs based on v1, alpha 2 and eventually that can graduate to be our main doc site, but initially it will just be gateway. Api sigs case io slash v1, alpha 2., and then we can also add a note in our readme that, although we have v1 alpha 2 checked in it's, not it's unstable and not yet released.

A

This is kind of how I envisioned supporting both. I do want to keep it simple and just any future changes go to v1 alpha 2. They don't go to v1 alpha 1., so releases and everything else are a little simpler to understand, but I'm interested, if that makes sense to others or if that's uh maybe uh too limited in scope to completely lock down v1 alpha.

A

A

And no big deal, I you know I I plan on creating a pr that will actually do this and can get feedback on on it at that point as well, but that's kind of my vision going forward is I want to really focus on v1, alpha, 2 and drive all our effort towards that, and so I think freezing v1 alpha 1 at this point is probably the easiest way to do that um so ping me uh on slack or anywhere, if you're interested in being part of this release process, it's always cool to have more people that are involved in the release process, but I also recognize this busy time of year for everyone.

A

So I, if there isn't bandwidth, I'm happy to take this on at a minimum. I I would like a couple sets of eyes on this changelog pr. uh As in the past, we really wanted to get consensus before release among maintainers that this is a release we want to do and we've done that on the changelog pr. So we wanted, I think, a majority of maintainers to be on board with the changelog pr once they were.

A

That was kind of approval to publish a release based on that so I'll be pinging people for reviews on this.

A

That makes sense any questions about the release.

A

B

That sounds good to me.

A

Cool all right, I think uh we're moving along pretty good here. uh The uh there have been a couple issues uh raised here. Thank you, bowie for a follow-up issue.

A

To actually make sure that this is consistent, um steve had an interesting issue. Well, let's, let's go back to, I usually try and cover everything in the past week and let's, let's start back at the beginning here, which is the conflicting s between http route and tls route.

A

Unfortunately, it looks like the people that are most involved in this conversation are not on this call, uh and I don't have a lot of context to add to this one I don't know. Has anyone else been paying attention to this.

C

Yeah, I think we just have to follow up with on slack for now, until the meeting times of flip-flops.

A

Yep, okay, I'll leave that, as is then and uh there's also a request for method based routing, I'm curious out there. Oh yeah we're starting to get future requests from datawire team, that's cool! I I I'm curious. How broadly this is supported.

A

C

It seems reasonable. There is one thing with connect that we need to kind of figure out with connect. What? Because, I think, if you go down like connect as a oh wait, is connect a method.

A

I don't think so. No, I mean sorry.

C

Maybe I'm just getting confused.

A

Yeah, this is just so, whether it be options get put post uh delete uh patch, depending on your your support level. um Oh connect is a method. Thank you for correcting me.

C

Okay, yeah yeah yeah, so the connection is like a little bit of like I don't know like a liger or looks like it's like neither here nor there. So most of the verbs are basically the same, except for connect.

C

A

Okay, so I mean it's same.

C

As in like they basically are extra headers, the yeah connect is just like a very odd beast, because it's it's like go. Do something else entirely sure. Okay,.

A

Good to know, I think, trace is another.

C

One options maybe yeah options: um yeah there are a couple oddballs and we should call it out like it might make sense for the normal ones and the oddballs we would kind of have to evaluate.

A

That's fair, we could, we could consider extended support, for you, know the the core methods here and specifically list them out and then custom support for anything beyond that.

C

Yeah, like yeah, like options and.

C

Trace as well, if anyone uses trace.

A

Yeah yeah, that makes sense cool.

A

Does anyone? Is anyone working on an implementation that could not support this well method based routing.

C

I think if it's extended uh that reduces yeah yeah the impact of the that question yeah.

A

Okay, uh then moving back up here. uh This is just to follow up uh when harry was building the image. uh His scripting uh really just used the default amd64 architecture.

A

It is not hard to either build it yourself or anything else, but right now, it's kind of I think it's hard-coded in here somewhere yeah. We we should.

C

Yeah, this is almost like a to do. We do need to. We should be nice and just build for the most popular architectures.

D

C

D

E

C

The common one.

E

B

C

A

Wait: oh no, this. I think this is the most common, uh but whatever it is, I I don't know how much it matters, because it's a docker image for our web hook. You know like how many people are going to be. I don't know I I guess it would be good to, and I just yeah.

C

I think like many people are building. Probably this is like on demand, like basically yeah, I'm sure arm. 64 will happen at some point and then yeah just on demand, we'll add it yeah. I agree with that.

A

C

We just freeze that feature, because it's it's highly likely we'll not get to it and fatalbot is going to bother us all endlessly about it. That's a that's. A good idea.

A

Cool all right, this is also a good one that really we need to pull in api machinery. Yeah. It's been suggested that I think what we're trying to do with this project as a whole is, you know mostly networking focus, but we're also somewhat by default, also trying to push forward the crd ecosystem. So projects like this can become more practical, and that means we get to run into fun.

A

Things like the the pain of coupe cuddle output right now uh enforcing immune immutability uh variety of things like yeah that we need to have our validating web hook.

A

These kinds of things I I know I've talked to people in api machinery about at least the first now all of these actually, um but this is probably something that we we should bring to api machinery as a whole in some kind of clear format to see, if there's any any plans to help on any of these, I I have an upstream pr that should help with this one, but some of the other ones are bigger questions I I know there were some significant complexity around enforcing immune immutability uh here uh it with at least with a web hook like what anyways so.

A

More to be discussed on this one, one somewhat nice thing about changing our meeting times is we'll no longer overlap with every other sig in the world. Right now is the same meeting time as sega and sig api machinery, which I've wanted to bring topics to, and you know hard to do both so anyways. uh That will be one advantage about moving our meeting time.

A

Cool all right uh request, filtering between gateways and namespace routes. This is I I was glad to see this as a user request, because I really wanted to focus on this in v1, alpha 2 or spend some time talking about this concept, but actually getting a proper request, for it helps ensure that happens.

A

This is is a concept I think that goes back to the very beginning, origin stories of this api and the idea that hey it'd be really cool. If you could delegate routes, if you could delegate from one route to another route- uh and this also overlaps in concept with uh another idea- and that's can you forward across namespaces from routes can routes reference, other resources and other namespaces, uh because, theoretically the reason you'd want to delegate a route? Is this very specific example of you've got?

A

You want to give the slash cat's path and anything below that to the cat's, namespace and slash dogs and anything below that to the dog's namespace right? That seems like a pretty clear example of something like you might want to do. I, and I don't know that this delegation is really as meaningful or valuable. If you can't cross that namespace boundary, so this really pushes the boundaries in two directions: one that kind of route delegation concept, but also the cross namespace concept.

A

um I don't have a good answer for how we do this and how we do this safely without just over complicating the api.

A

But I know this concept has been interesting uh for a while- I I don't know bowie or anyone who do you remember, yeah, okay, john, it looks like you. You referenced some prior art here with the virtual service delegation.

E

Yeah it's unfortunately, it's a bit circular because we implemented it because the gateway api was planning it originally yeah. But oh.

C

So we can learn from uh any bad experiences.

E

A

And damian does contour have some kind of concept like this. They have inclusion now I think, or something.

C

I forget they used to have delegate.

C

B

Always saying there's inclusion.

A

So is that so I'm not I'm not as familiar with inclusion. Is that similar in concept to this or.

B

I believe so I mean I'm still learning about it. There's a lot of aspects of contour, I'm still coming up to speed on okay.

E

Okay, yeah, I think the tricky thing is that most implementations probably can't like. Logically, we have like two tiers of routing right with the like root and the leaf or whatever you want to call it. um But most implementations probably can't actually do that in the internal implementation, so they have to take the two levels and flatten them, which can be extremely tricky if the matching logic is complex like here, it's simple, like slash, cats goes to cats.

E

Slash dogs goes to dogs no problem, but then, if you throw on a regex or you throw in some custom matching, maybe it gets really tricky. So I think in the istio one we just like really limit it down in validation. So, like you, can only have a few different types of match um in the the top level one, but.

C

I think that's.

E

One of the trickiest parts to get right.

C

Yeah, I think, like any proposal that has to make that makes it into our api has to be realizable without actually even knowing about the underlying implementation, like it's almost syntax sugar, with the r back associated with it, um we'd have to see like from a user experience perspective if that meets people's use. Cases versus everyone wants to add all the bells and whistles, in which case we're just like it, can't really help you like you, can't compute this thing.

A

Right like it seems like if you were doing path matching you'd have to have yeah well again. This is also complicated because we have so many different kinds of matching whether it's header matching brand matching.

C

A

C

It's almost like, as, along with the web hook, we have to implement basically like a merger that people just use, as opposed to saying, hey implementation, I'm going to tell you how it's supposed to be, because that description might very well be like one-to-one with the implementation.

A

Yeah yeah, by like focusing on path, I think it's reasonable to say that if a route is going to delegate to another route, the path match, type would have to be prefix and regex could not be found in any any matcher for uh any routes involving delegation, whether they were the root or the leaf.

C

Yeah- and you can't have like filters or something like we, it would be very restricted to yeah.

C

For example, like could you create like a circle.

A

Yeah right, right, yeah and, and similarly you need- I mean we we've. We took so much effort to cross the name, space boundary between gateway and route crossing. Another namespace boundary is going to to take some thoughts and and like you're saying like I would have to be pretty restrictive all around to do this, but I that I still think it's valuable. uh It just will take some thought.

A

All right: well, that's uh one fun thing to look forward to uh the last issue. I think that we have to cover today is missing service name behavior. uh I just I just got a quick look at this before the meeting today, and I thought it was a good kind of.

A

Underspecified area uh right now we're very strict with this, and that says, if anything, that you're referring to in the route can't be found, the route must be dropped from the gateway and steve raises. What I think is a interesting use case of something like that.

A

That may feel too harsh may uh so in this case, let's say that you're.

A

You've got two matches. One of the matches is valid, it's referencing a valid service and the other one is matching is not matching a valid service. The service is invalid.

A

You would think that there would be a way we could specify this in a way that you could retain this match and drop this match, but I don't know how to to reflect that in status or how to.

A

How to really communicate that in spec, but this feels like something that we don't currently allow for in the spec, but that would provide a much better experience.

A

Does anyone have any ideas on this.

E

I'm actually a bit concerned about both options, um because if we drop a partial match, then now we're changing behavior, because before slash blog went to boo hiss and now it's suddenly going to valid service, which we maybe never want any request from blog to go to valid service. Maybe that's a very bad thing for us now. If we drop all of them, then we have a huge blast radius. So that's also bad.

E

It almost seems like if we have an invalid service. We just want to return like a 404, so we still do the match and we still don't allow traffic to. We don't like switch up the matching, but we just do a 404 directly to the response or something now for tcp and tls.

E

Obviously we can't do that, but I suppose you could close a connection or something, but I'm a bit worried about either option of dropping.

E

A

Yeah, no, I think you're, I think you're right. uh That is, that is definitely wouldn't.

C

This be a 500, almost not the 500 uh yeah 500. 503. yeah.

A

C

Upstream, whatever it's called it's like upstream is like not, there kind of thing.

E

Yeah yeah sorry.

C

You're right it.

E

Probably shouldn't be a 404, but some mayor code.

C

Yeah, it should be a 500 like um I forget what it's called, but it's like I'm sending it somewhere else, and that thing is not there like.

A

Well, that thing is not, there is 404, but 503, no.

C

No, no 404 is that your request is requesting something that that does not exist. This is that the proxy is trying to go up to somewhere, and that thing that was configured is wrong is not there.

A

Okay, sure yeah so yeah, I think 503 is, is appropriate here: um service unavailable, whatever it is, uh yeah, okay and and that that does ensure that we we aren't routing. So I guess I guess one extra level of complexity here is our conflict resolution.

A

You could theoretically add this to conflict resolution and say you can't if you have two equally matching uh rules and one resolves to a service and the other has an invalid service reference. You could trust the one that does. I think.

C

Yeah but that's like.

A

C

Thing I or conflict resolution should be statically defined.

A

Yeah, I I yeah that makes sense um so, given that I think just adding guidance that you should 503 here and then I don't know how we do status in a meaningful way. Here.

A

I still need to figure this one out at the the confusing thing about this is the route status is difficult to populate, because multiple controllers could be routing to it. Multiple controllers could be using the same route, but yeah, not that I I think this is a good issue to follow up on.

A

So we know at the very least we know what we want the behavior to be. We just don't know how to communicate that to the user.

A

Okay, well, I will leave it there. I know we're already past time, just uh keep an eye out for a changelog pr or ping me if you want to be involved in the release process at all. uh I think we're awfully close to getting our 030 release out, and then we get to focus on all kinds of new and exciting things.

A

All right, we'll have a good rest of your week.

B