Kubernetes Network Gateway API Special Interest Group, 7 Mar 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: SIG Network Gateway API Meeting for 20220307

Description

SIG Network Gateway API Meeting for 20220307

A

A

All right we should be recording. This is the gateway api meeting for march 7th. We've got some exciting things to go through today, but first up is jeff and route. Inclusion and delegation for gateway, api and I'll hide it off to you.

B

Thanks rob um so looks like we've got a small crowd today, um I'm not sure how many of you had a chance to actually review this document at this point, um so you know we can go through it and answer questions if you want or if people want to to review it and then discuss it next week, I'm open to that.

B

I don't want to waste people's time during this meeting if they haven't had a chance to review it yet so in votes. One way, the other.

A

I'm happy to take the time to to go through this, but uh hopefully.

C

I agree, I think, and I think the best seems to me like the best way to do it is to run through what you've got proposed. Let's ignore the comments until you've run through what you've got proposed and then we can talk about the comments in light bulbs. You know, obviously, if someone asks.

D

C

And it's reflected in a comment off to the right, maybe hold on to the question until uh yeah, until we've done with the with that one. But I think if you want to ask questions to clarify what people are talking about, that's cool.

E

Okay, maybe they will try to distract your parents, it's like a brief intro for folks who catch the recording and want to like um come next week and talk about in more detail. Yes,.

B

Sounds good thanks for the feedback, so, um basically, the approach here is to use uh not introduce any kind of new route objects, but rather uh take the ability we have with the allowed routes struck in gateways right now and use that or add that to the route rules that we have in this case with http so use, we would use allowed routes as uh instead of I guess you would say, a child route.

B

Excuse me a back-end ref when you want to when you want to refer to uh or delegate or include a second route, uh second level of routing, if you want um so all right, that's kind of the very highest level approach. um I've gone through, uh I'm talking about the goals real quickly.

B

This is this proposal is focused on http. I tried to lay out logic in a way that would as much as possible, be generic and be applicable to other types of routes in the future.

B

I just don't know that we have any at this point that.

D

B

Really need to do do more than that.

B

The only one I could think of is tcp enough stretch. Maybe.

B

So uh delegation is, is part of this, um so there's definitely the the intent here of being able to define a parent route at the gateway owners level.

B

And let them delegate a piece of the routing off of the listener to uh to another group so off of a single listener, they would be able to delegate. um You know he could have like say a single parent route that would be at a listener and then, within that route, delegate to different uh name spaces different. You know different groups, uh different parts under of what's coming in under that listener,.

C

Do you think um that it seems like you're just talking about delegation? um One thing that I didn't really see you explicitly say I think I have. I think I have a fair idea what you're talking about, but um could you just quickly walk us through like what you feel is the difference between uh delegation and inclusion, or is there a difference so.

B

I think the the only difference in my mind is, is really um intense, so the mechanism is used for both so there's no reason to have a child route that I you know. I.

C

B

Be the uh on the child route.

C

B

Hopefully, that's better.

C

Yeah, that's better thanks! All.

B

Right thanks for letting me know, um I there's nothing that uh you know I could be the owner of the gateway, the parent route and the child route, and I'm simply using child routes to to keep my parent route from getting too big.

B

You know, or I may have.

B

Maybe I have multiple domains coming on in a single listener, and I want to do the routing of the different domains in a current route and then then each domain would have its own child route to take care of things at that level. Just as an example doesn't mean I I don't own that all um it's really optional. It's all the same mechanism, so.

C

Okay, so would you think it's fair to say I I don't disagree. I just want to make sure. I say this for to make sure that I'm clear on that that we're on same page, um would you think it's fair to say that your delegation is when parent-to-child relationship also crosses a like persona boundary like or a user boundary yeah and inclusion is the the functionality that you get regardless. Like inclusion happens regardless? It's that the inclusion is also a delegation.

C

If the the one of the parent-to-child relationships happens to be across like two different people owning the objects.

B

C

Okay, exactly yeah, that feels like. I think it would be good to put in terminology okay.

B

Appreciate that.

C

That was why I was lucky.

B

B

So as part of that, so obviously that that does lip give the apparent route owner the ability to limit the scope of the trial routes that they delegate.

B

You know which could be the path could be. A single host could be something else, as I mentioned in just that discussion about inclusion versus delegation.

B

uh It does allow this a model of inclusion simply for a point of view of ease of organization, possibly um and they're, also not just ease of organization, but also a way to simplify, having potentially different sources of traffic, that route to the same service and not having to find the same route information in multiple places, but rather define it at one place. uh But you can update it in one place without having to to risk the out-of-sync scenario.

B

So rob I think I rather that's the concern on terminology for parent, rotten and and child route, and I think that rob you know technically, your comment is correct. I was just trying to since I hadn't introduced the the idea of allowed routes. Yet at this point I wanted to, I didn't I didn't use it at that point. So.

B

um So the two use cases that I've documented here are basically around the uh one is the delegation and one is the inclusion, um so the first one is the delegation, and the second is is uh inclusion.

B

uh I'm not gonna go into details of those. uh If somebody wants uh clarification or or thinks there needs to be, something changed obviously um provide that feedback.

B

C

I think use cases, look good.

B

Thank you. um So here's really the top level changes we'll add a section name to http route. um It'll be optional, also, add allowed routes which would be optional, and it would be any place back in reps.

B

Allowed routes could be used, but you couldn't use the same or you couldn't both. Excuse me for the same magic criteria.

B

B

Allow the a route to have a parent ref that points to another route as opposed to just supporting gateway.

B

Right now is the parent rob and and like the parent ralph that points to a gateway, and you have a and you have the name of the gateway and the name of the listener in this proposal, when you're doing it doing a route to a route, the parent ref for the child would be to the name of the route and the also the section name, that's in the route rules to identify exactly where that route is supposed to plug.

B

In the reason for that logic is, you could potentially have uh multiple routes in a name space, uh multiple child routes, basically, in the same name, space that would be plugging into the same parent, ref or same parent route, but at two different places.

C

But just to be clear, that's the the section name, um the section name is always optional. You can just say, bind to the whole.

C

B

Yeah, you could use it exactly like, uh um but you know the user would be just again just like back in refs, so um you wouldn't have to have section name. um But if you you don't, then it just plugs into um a place that you're you're defined as as an allowed route.

B

You've got an allowed route in the parent.

C

That's what I was about to say here so yeah, so every allowed rail slot it would it would. It would attach itself to.

A

I think the follow-up from that uh on and before I go further, I want to say this is an awesome doc. I've obviously commented a lot, but I yeah well well done. uh But one of one of my questions I somehow did not add as a comment about all of my comments here uh is what the default for allowed routes will be so on gateway listener. What we say is hey if you're in the same name, space just by default, you can attach your route to the same gateway.

A

Is that the kind of behavior we want for routes too? Is that the default just any route can attach to any other route as long as it's in the same name space, or do we want to have a tighter default there, where you can only attach to routes that have explicitly specified this.

E

I was personally expecting it to be exactly the same ah as the current gateway behavior, so same name space, it's the default, but open to alternative perspectives on that, when we talk later about.

C

How you need to tell you tell if things are a apparent route or not by whether or not this structure is nil, so you can't have a default.

B

uh Yeah, that was that was part of uh rob's comment. I think, uh and the definition of parent is that allowed routes uh could be null or if it's not null it's. It classifies as a apparent route.

C

Right I mean you can do there's some clever, there's some slightly clever stuff. You can do with defaulting and stuff like that, where, if you specify like a single value, then you get like you know. If you specify the you need to specify something uh but yeah, I think there's there's just some subtlety there and exactly how we make those rules work.

C

If that's the case, I'm kind of of the opinion that this is a complicated bit of functionality that is easy to misuse and that having people need to do explicit allowed routes of some sort is probably better, because that way you stop people from accidentally.

C

Like you know, it gives you the way to say what's apparent rare, what's the parent route and what's a child route, because a parent is anything with a defined allowed route, it gives you the rule that says um you not we're not using we're using we're not using back end rest. For this thing we're using allowed routes.

C

You can't have back end ref and a loud route set on on any specific route rule, and then it also gives you the thing where you say: okay, you have to define the behavior that you want, even if that is all known spaces or whatever there'll be a thing you've got to put in everywhere. I think in this case this feature is super complicated and requiring people to be explicit and having less magic is actually better.

C

Even the gateway use case is different, because most people are probably going to want to do like we want that simple. You know: hey I've got one gateway, one route, one http route use case to be really easy, whereas in this case we actually want there to be. It's actually desirable, in my view, to have a little bit more friction that you can't accidentally have lots of routes be included for you. If you're, not you yeah yeah, you can't yeah. You must have the full two-way binding.

C

For this thing to happen, um you need to jump through a little bit. More hoop is my opinion.

A

Yeah, I agree with that. I I'm cautious. I think this is one a very exciting feature, but then two like just I chatted a bit with some of the people that are implementing the api for us and then what one of the key things is is implementing guardrails around this, because without pretty tight guardrails it could become very difficult to implement and or use, uh and so that that kind of you know very explicit.

A

Opt-In, I think is, is a good starting point, uh because you you could, like nick said, you could easily make a mistake that you didn't intend, uh if you're, not careful with this.

C

I think and related to that there's one other corollary that I don't I don't remember seeing here, but I could be wrong is what happens in the case that you have so we've talked a little bit about the the sort of any particular rule being only allowed to be a parent or a child, but does that mean? Does that also imply?

C

The question we need to answer at some point is: does that also mean that if you have a single rule with an allowed route, you can't have other rules in there with a backhand ref right that that means you can't have like a mixed one.

C

That's that is a child, both a child and a parent, because- and that's that's important because otherwise, if you can have some rules, be uh parent rules and some rules be child rules or like serving rules, then you can use that you could theoretically use that to build a an arbitrarily deep, dag of uh these, which you absolutely do not want trust me. I know that's what we did in contour and it is a mistake.

C

It makes the it makes the implementation code really complicated because you have to traverse the full graph every time you do a conclusion. You don't want that.

B

C

So that is an implementation detail, I'm sorry to derail the discussion. We should not talk anymore about that now. I just want you michael and jeff. I want you to put that away in your memory bank and think about it. It is not relevant. It is not germaine at this point, I'm sorry for doing discussion. um Let's continue with talking about the the main part of the thing. Please, I'm sorry.

B

Okay, he's like um so that's that's uh the high level. um I just gave an exam just kind of a rough example of what it would look like here. This really wasn't meant to um make any particular point just to show a functional pair of routes.

B

So other than um kind of some explaining about how combining the parent and child rods are done. I've tried to pretty much have this list of things that I'm showing now on the screen as the summary of everything. That's that's uh going to be changed or added or or whatever I'm sure, there's some little details uh that have been missed. If nothing else, um I think you know the point about like defaults.

B

uh What's allowed, if you don't specify loud routes, you know what's the default things like that, but uh um so this hopefully explains everything that we'd actually change um and the list I had at the just before the example is in this list here. So the key changes primary changes I just just went over.

B

They are included in here.

E

B

Trying to figure out how to go through this a little bit just because I um you know, walked through a bunch of it already.

B

B

So apparent one thing is a parent's route.

B

Could have a rules, you know a set of rules and another that results in a a back-end ref. um You know so you may, as a route owner. You may want to delegate some piece of the route, information or writing decisions, but not all pieces of it.

B

So that's the kind of thinking behind that or you might also want a default back end rest for when nothing else matches.

B

The section name is optional. I think we talked about that briefly. It's really just to make it clear where a child route is intending to be inserted into the parent routes, rules.

B

C

It's like, it seems like the children must include a section name when it's parent reference or route, though, is a little different to what we talked about just a moment ago.

B

C

So that's, okay again, that is a that is fyi, just something to note down and do it later. Not not don't please don't let me do well. You keep going.

B

Yeah you're a good point yeah. I did say that uh you could plug it anywhere into the parent route, and- and here I am saying it must have a section name so good point. Thank you.

B

So just to keep life simple, uh because it's already a very complicated uh proposal and changes. uh I wanna make it so that uh a child route and a parent route have to be the same route type.

B

I could see a scenario where, where you might want to have them different, for example, an implementer might want the.

B

Parent route to basically represent an l4 load, balancer and so it'd be a tcp route and they might want the the child route to represent the l7 uh processing uh tier in the network.

B

So that it's a scenario I can see, but at this point in the proposal, I'm just saying it's not supportive.

C

Yeah yeah, I I think we need to be really careful with that, because that's kind of implying that one thing that I think is we need to be really really super duper. Careful with this design is that we don't at any stage imply that the um the parent reference implies a routing hole um and, like you know, because it's not it's all about this- is all about separating config, it's not about describing the routing chain, and uh you know having it so that you can have a tcp route.

C

That sort of includes a http route sort of moves us more towards describing the I mean. I know that that makes sense to a lot of people, but I think that the thing that we have heard on at the site at the moment is that routes that describe higher layers um are inclusive of the details that are in the lower layer routes. So like a http route, is inclusive of the details that are in a tcp route. So you don't need a tcp route to also describe a host of your up.

C

Http run describes all the tcp information that you need to to route a http traffic same for, and the same goes for grpc the proposed grpc route. It describes all the http information and thus the tcp information that you need to describe the grpc route. I think that that model and that model isn't 100 what not what some people expect.

C

The way that this thing works. I think we, if we're going to do, that, we need to be very clear about that. That's how it works and we want to explicitly stop people from using a tcp route that refers, that that has a child http route, because that is the http route already has all the details, and that gains you that buys you nothing.

C

So sorry again, this is a little bit of a digression, but I think it's really important to talk about, but I don't think we've written down anywhere that that's how the route rules kind of work, but I think that it is definitely implicit in how we have designed the wrap rules that the different sorry, the different types of routes, um and that your higher layer routes include. All of that should include all the details of the lower layer routes.

C

You know so ideally http like problem, you know. Ideally http route should include like whatever stuff we add to tcp route about. um You know allowing uh source ip addresses and destination ip addresses. I don't think we've done that yet but like but there's no. You know like like yo that it by that model, that's how it should work. Sorry, I know I'm dropping lots and lots and lots of things to think about here. um Some of them are relevant to this discussion.

C

Some of them are not, but I just need to some of these I'm going to forget about them. If I don't say them when I think of them. So sorry.

B

That's good, I you know, I think in this case I just wanted to acknowledge that there there is a um there is a understandable use case for mixing route types, um but you know just you know so.

C

Yeah explicitly not supporting that use case. I agree. Yeah.

B

B

um So um a route could be a.

B

B

Could be a parent? Well, let me a route could be both a child of another route and a.

B

Directly connected to a listener, so uh it.

B

It still only allows one unless I'm missing something. Logically, it still only allows one uh or basically just two tiers of routing. You know a parent and a child, not a, and not anything, to do all over that, but it doesn't force um you to um have separate quote-unquote child routes um when, if you want to use the same routing logic in in both uh a parent, you want to insert it in a parent, and you also want it directly on a on a list or someplace else.

C

Yeah, I think that's a like. I said before I think that's a really important rule. We we really want to avoid being able to create an arbitrarily deep tree of uh conclusions.

B

Yeah, absolutely being that we're implementing this too yeah. We fully agree.

C

We ended up having to use literally like a visiting graph pattern to on every change on every uh http proxy in order to be able to determine that. No thank you. Yeah.

B

Yeah, it's bad so getting to the reconciling a little bit um in general I'll talk about how to reconcile the parent and child um in general a little bit later. But there are a couple that have get special treatment, and that is the host name and the path.

B

So um I I think I think many of us believe that one of the most common ways of doing or doing, delegation or inclusion will be based off of path.

B

But if you're trying to define path at more than one spot, doing things like uh like a regex as a parent and uh a prefix string at the child starts getting kind of ugly if you're trying to combine those in a single path of logic- and we certainly don't want to make this a a spec that requires to have two loops of processing of the data.

B

It's not like we're going. You know we're going to go through it once and then spin it around back to you know, loot back so to speak and process it all over again. So um the way to keep it from an implementor's point of view relatively straightforward.

B

To make it so that, when we are doing parent child route relationships and our defining path at both layers, we're limited to doing prefix matching.

C

I mean I'm not going to say anything bad about that since I'm the one who suggested it.

C

We do the same thing in contour for the exact same reason.

B

A

Okay, just echo that point like as I was referring to guardrails. I think this is a really important one and yeah, and also I should do a time check if we can wrap this up in another five or 10 minutes. I do want to get to a couple other things, but this is. This is really great, and you have emphasized like this is this is a huge huge stock that covers you know so many edge cases already and yeah. Thank you.

B

um The um the other kind uh special handling for merging routes is hostname, so, just like, we allow you to define a hostname at the at the listener and at the route level. Just extend this model that that model to allow you to define it at the parent.

B

Excuse me the the listener, the parent route and the child route so which could be you know, example, it could be listeners domain name, parent route is subdomain and child route is hostname.

B

This is, you know ie example.

C

I think, if we're gonna, if we're going to allow that, then we definitely need to be sure that we sort of be clear that this must be that as you go down the tree, it's got a it's got to either be the same specificity or a greater specificity. Like you know, you either need to have it be wild cards all the way down, or you know you increase you increase specific each at each level. It must either increase or be the same level of specificity.

C

You can't be like specific host name at the listener and then wild cards the rest of the way.

E

Yeah, that's something that I expect would be a like. um What's called like reconciliation resolution error that would like set us a status condition like preventing it from binding. If it tried to do something different than that.

C

Yeah and that's what we do I mean that's that reflects it's basically, as as jeff said, it's taking the same model that we have for this another route and just extending it for route to route, which, I think is the feels to me like the best way to make sure that this the whole api as a whole feels harmonious, um and I think you know, without wanting to get into it too much like that's one of the things that some people mentioned about like. Why?

C

Don't we use back and ref and, in my mind the reason not to do it is so that this relationship is the same as the like that the relationships are the same all the way down. It makes the api easier to understand, there's less conceptual overload, but overhead and understanding it it's hard not to understand.

E

I think there's a few other things that uh I did not make it into this version of I'll definitely add a section on the like alternative ideas or abandon ideas. uh I think this approach specifically also makes it easier to prevent, at config time the possibility of a route being both a child and a parent by like centralizing the conflict on the round object itself, uh as well as kind of like making it easier to detect and prevent uh potential like cycle loops. Because of that so.

B

So um uh reconciling just basic concept is you know: I've got a section name in the parent, and I've got a set of match conditions in that section uh and and allowed routes, and so that set of match conditions would be added to each set of match conditions in the child. So I've got you know a match uh and back in draft. You know for uh path, foo um and uh I've also, but at the parent I've got a you know, match off of uh a.

D

B

So that the effective result is that I'm matching on the header and half foo same thing with filters. If you want to define a filter at the parent, um it does carry it down to the child, but it's just ended with the the child routes.

C

One thing one thing to just put in there is a thing to think about and write a rule for is. I can't remember if we stated this explicitly, but filters have an implicit order, because they're in the lists is it you know appended on to the end or like. How does the have we explicit about the ordering of filters?

C

If so, how does the sort of the importing work with the ordering um don't need to answer now, but just something again, something to make sure that we have an answer for I don't think what matters is just that we have to pick one.

B

And definitely could call it what I missed that, and I would I would say it would be ended at the beginning, the parent.

D

B

That the stuff would be the filters that would be handled first and then the child would be um the next uh set of filter instructions that.

C

Makes sense to me too, but yeah like I said. I don't think it matters too much as long as it broadly makes sense, and we write down the rule.

B

Yep, so um the last thing I'll touch on just briefly is a conflict resolution between the parent and child uh base. The way I've laid this out is.

C

Apparent winds is the oh, it's how I would summarize it is that right.

C

I think I can't hear you jeff. Can anyone else see jeff.

A

Yeah he dropped out for me, I'm not sure. Oh no, we lost it.

C

um So that's the last thing on the list, so we probably don't need the dock, but you might you want to just run us through what you what you think about uh conflict resolution.

E

Yeah, so I think jeff's idea was to basically default to oh, I don't know uh it's just default to like um a parent, wins kind of thing. I think it would help to add a little bit more clarification on what is considered a conflict.

E

uh I think the example there is more of like a set ad set removed that isn't necessarily in conflict and something like that.

E

If there was a need for it, could be better handled with a policy attachment to like prevent um a route, a child route from removing a header, or something like that like something very specific, um whereas I think just by default, it should be able to do those things, but that's potentially like a thing, that's open for discussion and we need a little more clarification of what is actually considered to be a conflict.

C

Yeah 100 agree, I mean, I think, looking at the comments on the side, john john raises a couple of points about like for filters.

C

You know, maybe filters aren't going to support being being specified multiple times and so that, in my mind, that's conflict, then um you know, and so I think that the broader conflict resolution thing is you know we need to decide is like how what's the overarching design, um so I'm a little bit minus one on like parent route winning, um because because it's kind of an unintended consequence then like at the cha for as the owner of the child right, I will see my thing behave differently to what I have configured and how will I know like?

C

Am I going to have things set on the child route to tell me like yeah? If we're going to do it that way, we have to be very explicit about what the contract is and if something is not working, how you expect where you go to check, um I'm.

E

Yeah or like reject at the binding time of like refuse to reconcile if it specifies something that would be in conflict with something specified in the parent, I'm kind.

C

E

C

Of refusing to of refusing to allow the bind if there would be a conflict, I think that's a again one of the things that I have learned about this of this whole process of doing gateway api is that um it's better to like less magic is better. um You know the more magic you make things, the more implicit you make things the more you're going to have problems with people either doing it slightly differently or users are going to be like. Why isn't this rep? I represented my intent.

C

Why isn't my intent like and my object was accepted? Why is my? Why is what I asked for? Not what I got you know and in my mind I feel like that's one of kubernetes key api things is that when you ask for spec like if your thing is accepted and everything you know, conditions flip to ready or whatever, then that means that your spec isn't implemented. As you have asked for, like you, don't get sort of some weird changing behavior, that's not really visible and I think the most visible way to do.

C

That is just to say, this doesn't work because there's a conflict.

E

Yeah, that's a great deal yeah. I think just yeah being very precise, like in this document uh and elaborate on what is considered a conflict. What is like set and set remove, and how is that handled? um What is like something that would be created as a logical and instead of being a conflict so like, um because I think there could be cases for like refining a filter further, potentially and figuring out like what use cases uh we do and don't want to support so yeah.

C

Yeah, so I think, there's absolutely gonna be, I think, we're gonna need a set of general rules and then four specific types of things there will be a set of specific rules, some of which may be implementation specific, because you know the filter at the filter level. Right like you've, got your implementation, specific filters, and then you, how do you handle the inclusion thing there? Well, the implementation has to define it yeah and so like that's. Why? We need like two sets of rules.

A

Yeah, I agree with that. I I'm sorry. No, no! uh So just time check, I think we're gonna move on from this, but there is a ton of good content in here. Thank you to mike and jeff for writing this and presenting this uh yeah jeff. It looks like you're back. Thank you. Yeah yeah cool.

B

Yeah I'll I'll try to um uh later today and or tonight and uh tomorrow I'll be responding to uh comments and stuff. So.

A

Awesome well, hey! Thank you. Thank you both for uh getting this out and uh excited to see where it goes.

C

I agree the last thing that I would say is I strongly recommend uh that mike and jeff, you put a alternatives considered section in there. um You're gonna have to fill it out when you make this again, but anyway may as well. Get it in there now get us all talking about it and it will should save some discussion on the side sounds.

E

Good uh we'll definitely get on that next. There, too.

A

Great thanks all right, uh so I added a couple docs. These are short ish. uh They get shorter as we go uh first, one is uh an old dock that you've probably seen before it had some uh comically optimistic timelines before that you that I've since removed, so we don't have to think about them ever again, uh but I think we are getting awfully close to being able to cut v one beta one. You know you look at our api. We've accomplished a lot of what our graduation criteria requires.

A

uh You can look down this list here. Back in the day, we created a gap for this api and one of the things in there is what does it mean for this api to graduate from alpha to beta, and these are the items that we had in there we've completed the vast majority of them the web hook, I think, needs a bit more work. uh Nick, thank you for taking that one on uh the users are eight are using.

A

Most of the api is mostly there, and this all leads to what I think is kind of a slightly different proposal than what I've initially thought. I think it makes the most sense to release and graduate to beta a subset of our resources.

A

uh So specifically, I I know that gateway, class gateway and hp route are widely implemented and used. At this point, I feel pretty confident in their capabilities and I think it makes sense to graduate just those resources to beta as part of this release.

A

That means that a variety of concepts and resources, including policy, attachment reference policy, maybe renamed, maybe not, uh and the other routes, would all stay in alpha. There's a few reasons for this one. I think we do have very good signal on these top three resources, but if you try and summarize what we would consider reasonable to graduate a resource to beta, I think it largely comes down to it's covered by conformance tests in at least some fashion.

A

It's implemented by several implementations and users are actually using it and I think we can largely say that's true for these top three resources and I don't think we can say that's true for the rest, uh so with that in mind, I think it makes sense to graduate what we know is is good and and kind of the core part of the api right now and continue working on stabilizing the additional resources and features of the api, but not graduating them prematurely.

A

I think that's a kind of a very natural next step for this api and recognizes that there is a difference in the stability of resources.

A

Any any questions comments, concerns on that idea.

B

You're thinking on the uh what we would hold back on at this point and keep it alpha would that include the uh well. We just went over the route delegation, inclusion yeah, I think so.

A

C

I think that's something that uh yeah, I don't think we can, because we're going to have to make structural changes to the http route to do it.

A

I I'm not so do we, so I that's a good question one. I think what what we'd said is an optional field for name for rule name, section name whatever and two I my assumption was that allowed routes would also be optional.

C

True, so if, if we do it with the allowed routes um thing, then we can, we can take http route, the beta put all of this stuff into experimental channel, so it's beta but experimental and then graduate that stuff to the stable channel when we feel it's ready, which is then the versioning scheme working as intended.

C

um I think so, I'm plus one in general on the idea. I think we'll need to be careful about how we we may have to do some. I've got the uh docs uh assessment of the website or happening already, but we may have to do some fiddling with the docs structure, because now we're going to have like there's not one version of the api. There are two um you know so some object, so you can again we're going to need to restructure this to be via object. Obviously, as always great mice thinking like rob.

A

Yeah, so I this is the much smaller dock, that's kind of it kind of fits halfway in between this other one, but I, I think, there's two different things we're describing here: uh one is resources as a whole when we graduate a resource from alpha to beta we're saying this resource is something that we're confident about we're not going to remove it from the api uh and we're not going to make breaking changes to it.

A

That that's what I think of when I think of alpha beta, when it's still in alpha, we reserve the right to rename remove break whatever it's still in alpha, so as part of graduating http route gateway, gateway class. What we're saying is we're not going to break anything about these resources. We will still add things, but we're not going to break anything.

A

Second field stability is really just kind of a layer on top of a resource, and it's just wherever this resource is any new fields, start an experimental and then graduate to stable, and so they start in this world, where, while they're in this kind of experimental track, we can remove them, we can rename them.

A

We can make breaking changes, but once they get to stable they're as stable as the resource they're contained within um yeah, so that that's I, I need a better way to describe this, but I think this is a really key part of our documentation and kind of well. This needs to be a key part of our documentation, and I think this concept is important to understanding this proposal of graduating. A portion of our api resources up is that does that approach make any sense.

B

Yeah, I think that makes a lot of sense.

C

Cool I like that. I would actually like to I'm sorry. You go.

E

First, mike oh yeah, just I like that. The only thing- and I think that I had previously thought back and reps was required, but I looked more closely as optional, so we wouldn't actually have to make a change. So I think that that should not have any uh impact preventing us from moving forward with the valid pollution. Stuff. Yep, yeah back and rep is optional for redirects.

A

um That was the fun back there yeah.

C

um So yeah before we go on any further, I would like to sort of throw the floor more open to those of us who haven't spoken already, um yeah sort of does anyone else have some thoughts here um yeah. I can see a few people in here who uh definitely feel free to put them in chat as well. If you don't feel comfortable, saying them out loud, but this is a pretty big deal this proposal uh and I definitely don't want to go ahead with it unless everyone's had a chance to uh comment on it.

C

um I know it's going to be complicated for me to explain to internal people at vmware that, yes, it's graduating to beta, but not all of it and so like yeah, so this discussion is complicated and so like yeah. I'm definitely want to hear from all of you thanks um so yeah and again, of course, if you're watching this recording um the place to go, is uh you know the gateway api channel on kubernetes slack?

C

This is a pretty big deal. um We are very much like. We are forging a new path here. um You know we are forging the way to do this sort of thing. um We are trying to build the best way that you can manage all of this stuff. um There is no prior art. There is no one to tell us that we're wrong. There's only us trying to do the best we can right.

C

So even we go to the we've been to the people at api machinery and they're, like I don't know, and so you're like this is going to be us figuring out how to do this. The best we can and then reporting back to api machinery to say, hey as more people bring things out a tree. This is how they should do it and don't do this because it didn't work um so yeah. It's really important that especially people who are you whether you are an implementer or a user of this api.

C

We need this to be easy to understand as easy as possible to understand. I would never say it's going to be easy to understand, but we need to have a way to explain this. That makes sense to people, um and so, if the way.

D

C

D

um Hi, it's candace. um I have just I'm from red hat, uh just a question about the dates that are listed in here, because um we have a we have a monday morning meeting internally about gateway api which I've started attending and we did. We are kind of wondering about the dates, so I mean I don't really. I see dates here, but which is a little surprising, um but I just wanted to check and see. Is it are those dates? um No.

A

D

A

To clarify this specific date here is that what where were there other dates uh that you were referring to.

D

I thought I saw something about november, but that might yeah.

A

Okay, so there it was historical.

A

We just pretend that never existed uh that, but, yes, we had earlier dates in the stock uh that were aspirational uh that we we just did not hit. um I, for example, I think uh it so this dock originated around september and I think we had said oh by the way. uh We expect that we'll have multiple implementations of this api by november, and I think we, I think we actually, that is when we actually hit, but it's not this upcoming november. It's actually the past november yeah.

C

But maybe maybe uh just whack the 20 20 21 in there rob to make sure that.

A

C

A

I think I think I'd comfortably called it complete at this point, but it is still yeah any you keep talking. I'm gonna.

A

Oh, thank you. Yes, I yeah. I did not update this wow. Thank you. Thank you. Okay. I will uh old plan yeah all right. Let me just.

C

A

I'll yeah I'll I'll update this. Thank you for catching that uh very much appreciate it. No.

D

Problem, the march 21 date: that's a um yeah aspirational, aspirational. Okay,.

A

Isn't that we start the api review at that point? Yes, absolutely so! Basically, what I was hoping for is that we could get uh at least this done, and a portion of the docs updates ready uh in the next two weeks, so that we could hand this off to sig network api reviewers on march 21, and there is no telling how short or long it will take them to review and approve the api.

A

I I'm hoping it'll be small, because it's we're just handing this them the same api and saying hey: can this be beta now essentially, uh but want to want to leave them some time? The all the api reviewers we have from sig network are very busy people.

A

uh So that's that's this one right here of uh we need to reach out to them in advance and say: hey sometime end of march, we're gonna be looking for your time. Can you block some time off for us, but these are aspirational dates. I intentionally did not put an eta for an actual release of the api, uh but you can you know extrapolate from there and say that, hopefully, sometime in april, but.

C

I would, I would also say we are hoping and dreaming and aspiring to have the api to have whatever beta we have available for cuban at you. Yes, a hundred thousand percent. Yes, yes, the goal is to have something available in beta before kubecon eu.

A

Yeah, so that that that end goal is, I think, may 4 ish is when it starts. So really. We are strongly hoping to get this to be some portion of this to beta in april uh yeah.

D

C

I have been receiving the exact same questions candice, so I completely sympathize. Okay,.

D

Now, there's just one one phrase that you said that I didn't catch cubecon eu eu. Okay, all right!

D

Thank you. Thanks guys.

C

Driven development is real. Anyone who tells you otherwise is selling something.

D

A

Oh great questions, uh so I I just sketched out some ideas for what I think is between us and beta uh and well in our next release. uh One. We need to find a way to kind of move off our v1 alpha, one docs to somewhere either removed or archived or something, uh and then we really need to update our docs so that they can at least be prepared for v1 beta 1, where it's available, uh nick you're, helping with uh doc's, auto audit and cleanup would be great.

A

You know I I don't know what the the timeline is for that, but any any improvements we get out of that will be awesome. uh And then I I had a few very specific things. I think we need to improve or add documentation for um I I can take these ones on, but if anyone else is thinking of huge gaps in our in our docs or things that should improve, uh please either create an issue create a pr ping, someone on slack whatever um really want to get our docs in a better place and.

C

That's that's why I've that's why I asked for the resources from the linux foundation, but so meha, who is the um the person who's doing actual work, she's um she's, going through and sort of doing a there's a standard. The cncf has a standard docs review process which is going to take a little bit, probably won't be.

D

It'll deliver some useful.

C

Things like you should do this some specific uh outcomes. Probably it's not going to be helpful for this specific stuff um yeah, but I yeah, I guess the I would 100 to echo rob. I would 100 000 uh recommend anybody who is doing an implementation if you find something that's missing in the docs or something we're not explaining. Well, that takes you a long time to understand, even if you're, if you're, not a tech, writer enough or confident enough to update the docs, make an issue to say. I didn't understand this.

C

You know like, or you know or there's a discussion topic uh on available as well. Under the discussions thing that's like I was implementing and here's what happened. Please put anything where it's like. I couldn't understand this. The way you've described this is bad. Like that's cool, like you know, I think there's plenty of things that we have described very poorly uh and we have not documented well uh stuff, like the release.

C

Channels, is a good example of that, um but there's other stuff where we have all spent, I mean rob, and I have spent like two and a half years at this point. Talking about this api so like there's a lot of stuff that we're gonna know.

E

C

Knowing that we know- um and so you, the only people who are gonna, be able to tell us those things are people who are new to the api, and so I would love to see like 50 issues that are nothing but people being like. I couldn't understand this. This is badly explained, that'd be 100, fine,.

A

Yeah completely echo that if anyone has, if anyone has time or people in their networks that want to help out with this just by pointing out flaws in our docs, please yes uh with that, I know we're past time. uh So let me just.

C

Did you have something mike.

A

Nope, nope, okay, okay, cool all right, so yeah, the very last thing we will probably cut a v0.4.2, probably this week uh that will include nothing other than a test of image tagging, to make sure that our web hook actually gets published with a v0.4.2 image.

A

So it should not be yeah. So again it may be 0.4.2 and 0.4.3. I don't know until we get this working, uh but that's just watch out for new releases. They shouldn't be particularly meaningful, but that's a goal for the week next week or two and with it with that. I think we're we're past time, but thank you. Everyone for great discussion uh excited about the future release and uh thanks again for the the great dock on inclusion. So.

C

Yeah, that is a seriously fantastic dock that needs very little work to turn it into a gap. Nice work.

B

Completely appreciate it appreciate it.