Kubernetes SIG Contributor Experience, 12 Sep 2023

Previous Meeting

Next Meeting

⏯

youtube image

►

From YouTube: SIG Network Gateway API meeting for 20230912

Description

SIG Network Gateway API meeting for 20230912

A

All right welcome to the Gateway API meeting for September 11 2023.

A

uh We've got uh fairly LED agenda today, but, as always feel free to add things to the list as we go. This is a kubernetes community meeting, which means that we abide by the kubernetes code of conduct in general. That just means to be nice to each other. uh Thank you.

A

Everyone I think everyone on the call I recognize, but uh if I missed anyone, uh we usually do give some time if someone's new and they want to introduce what you know themselves and give it a little bit of background as to what interests them in Gateway API happy to leave just a minute or so for that. So if anyone does be like volunteering, this is a good time.

A

All right no worries, okay, so first step on the list is uh 0.8.1. This is coming up awfully quickly. um We missed something like uh in the release process. So if you take a look at uh this one in particular thank you to Frank uh for fixing this. uh We we uh had something wrong with the cell validation for listener. Uniqueness Frank fixed that uh we need to get this fixed out because it could affect people that are upgrading to the 08 version.

A

So that means, unfortunately, we do need a 081 we're going to have a lot of releases in a pretty short time by Gateway API standards, but my goal really how this uh released this week.

A

uh There are just I think four things that made it into this release so far: there's the cell validation, oh, that that's double counted because of cherry pick uh update to the changelog, because we had missed, uh highlighting that you can now specify more than one mirror back end more than one filter and then finally, a conformance fix, so pretty small set of things that have made it in 208 right now. If there's anything else that you can think of that, you would like to get in.

A

This is probably hopefully our very last release between before 1.0.

A

uh So if there are any other little patches or fix-ups, please let us know ASAP, otherwise, we'll be waiting, not very long, but until 1.0, hopefully in October.

B

Before we start the release candidate process and stuff like that for 1.0.

A

Yes, yes, yeah once we start release candidate, uh that's the point of no return. uh You know we have uh For Better Or, first largely followed the kubernetes Upstream release process, which means that there's no branching or anything to prepare for a new release instead or just everything, is on Main and what is what is released on day of release. Day is head of Maine.

A

Okay, Dave I think you've got the the next one on here. A question about 1911.

C

Yeah things got pretty heated with the Gateway TLS, especially with like hey. We need to be able to at least do something what we considered kind of like minimal for GA, I kind of view like back-end protocol to be kind of in those. So, for example um like if some ingresses have websocket support off by default.

C

How do we allow people to do that um to specify the back end? Shouldn't then enable that protocol, and so what this was proposing? The mechanism was to just use the app protocol label on the service as the hint um and we sort of as like some unknowns.

C

But like I think the the ask for me was to go back to um link Sig Network and do they like surface this and there wasn't really any sort of objection to it from my perspective, but this was I think like two months ago now at this point, so I guess my my appeal here is to be like. If not this app protocol approach, then like can we come up with some way or some other mechanism to allow users to potentially specify like how do I enable HTC and so forth, like that.

A

Yeah I mean it seems, like a reasonable request. I think uh what always scares me when I see a a cap, a gap. Sorry like this is all these tables require a fair amount of thought and it it's it's useful, but it requires a fair amount of thought to make sure that we're not you know missing missing something uh that we should be. You know, by being this specific uh it, it kind of requires a lot of thought in the review process.

A

I I think what you're really asking for here is just some kind of high level agreement that implementations of Gateway API should honor app protocol and yeah I mean basically that uh so I'm curious I'm, starting to think there may be a a simpler way to add that guidance without being too prescriptive, in terms of which I don't I know.

A

This is kind of the reverse, the inverse of what I'd usually say, usually I'm, asking for a lot more information about every corner case, whereas this in this case, by being very prescriptive about every Corner case, I, wonder if there.

C

Was a request in the past, so yeah.

B

Yeah I think I think this is one of those things where it seems it's it's the classic problem where it seems like you should be able to get past without being specific, but you can't um yeah yeah, so I think yeah I'll have another look over this I. Think from my point of view, I think it's um it's really good. I need to sit down and spend the time passing the table.

B

um uh I think that's probably the as Rob says. That's the part. One of the parts that takes the longest um I mean I. Think that um and then the other thing. The other thing we will need to be more specific about is uh how it will interact with uh to uh back into this policy.

B

Oh thanks, Lewin AWS have designed a CID for this.

C

A

You this looks really interesting if you mind giving a little bit more information about how it works.

D

uh Yeah, so we Define a new crd um I think we got a lot of requests on our customer. Is they want to? uh You know today, there's no way define whether the backend, HTTP https or uh those kind of you know protocols.

D

So uh for that we Define a crd for that, and you basically attach this policy crd to the service and if service is referenced by the HTTP route back in ref- and this is basically acrd your spec for that which protocol whether HTTP https- and we also you know in the bundle of this crd- we also Define the health check.

D

um So basically you could for this particular backend ref um you can Define the you know it could be for there's no way of specify the house check. So we also have a lot of health check for that. In addition to the protocol, yeah.

A

Cool okay, so this is uh more than just back-end protocol like protocol the back end. This is health check and, if we're okay, so this is this- is basically all the configuration like a policy that extends service with the AWS.

E

Specific yeah, okay, exactly.

A

Yeah we there there's something similar on gke as well uh and yeah. uh We we have yet similar kind of protocol type thing that is different than app protocol, but I I think we would love to love to have app protocol as as soon as you know, as it's more well defined now, can.

C

You um because the folks who have policies that do similar things, do you mind, adding a comment to the Gap, so I can incorporate it in the reference references, yeah, good, okay, yeah.

C

F

C

First, pass of this was a resource that would like essentially Target and reference a service, but that has a can of worms.

C

Easier, if we can all agree on it,.

A

Yeah no I agree, yeah protocol is, is likely a better mechanism here.

A

um I think the the history of the the GK specific policy was was just that there were gaps in that protocol and and also there are some uh some weirdnesses with the with our definition of protocols that uh there may not be quite as standard as we would yeah yeah.

A

um Okay, uh so I think we have clear follow-ups on this. One uh I know myself and when are going to add and anyone else are going to add references or just comments with references to uh any config that we're aware of that could overlap with this uh and just for prior art as an example, and then Nick has volunteered to do a past uh for review here.

C

All right, thanks cool.

A

C

Thanks for pushing.

A

This one through it's a I I yeah this has been a complicated one and I appreciate your your patience and I know. You've been going back and forth between kubernetes Cygnet and this and that yeah and it.

E

A

I appreciate you pushing this one through.

B

Yeah um Travis did call out in the chat that uh we uh we could conceivably just have the the Gap say just do app protocol using the well-known names um this one's also adding names for uh websockets and HTC, which are not well-known names, um I. Think that probably we would need to do uh websockets and HTC so soon afterwards that it's not really worth splitting them apart. We should just do it all at once. It's going to be easier.

A

Yeah I'd agree with that. I I think it's kind of inferred that you know do our protocol or something that should be done, but it isn't stated as clearly as we should make it so yeah.

B

Yeah yeah I should know that um I will add that to um I have been working. I have been chipping away at a PR to add a um uh actual implementer's guide right now.

B

The implementer's guide that we have is actually uh uh API designer's guide um that has tips for Us in this meeting who are working on Gateway API, but we don't have a guide for I want to make a Gateway API implementation and the things you need to know that um so yeah and there's a few things in there that are that are tricky that that are inferred inferred or implied in the spec.

B

But it's we don't have the right place to call them out so uh that my idea there is to add a document that does that which would be things like hey. You need to consider.

B

You need to consider uh you. uh You need to consider various objects.

F

B

Make sure you're reconciling them and things like that.

A

Yeah uh that'll be really helpful. I am looking forward to that because yeah our our current guide is, is kind of this weird hybrid of of both. You know, and uh you know we could split it out. um Cool okay, so I think we're we're good on this one.

A

Let me keep on moving then uh I added a PR that I would love to get some additional feedback on, especially from people that are implementing this API, because this is something that would require more work from all of you and I want to make sure that it makes sense before we go ahead and merge it.

A

uh The thing that I am trying to accomplish with this this is trying to resolve an issue that I think is going to become increasingly more common, as this API evolves and grows, and as the number of releases of Gateway API just continues to expand or starting to release more and more versions, which increases the chance that the version of a Gateway API controller you're using uh may be older than the version of Gateway API crds that you have installed in your cluster, for example, and there's not a good way to surface that right now and I'm particularly concerned that we're going to run into a situation where uh users are not understanding why a certain feature is not working and there's not really a way for us to surface that, and you know the the supported features.

A

Work that Leora is doing is very related to that and I'm I think that will help. But I think this idea of a supported version is also uh very useful. uh There are a few different ways we could take this. The way I've proposed is adding a new condition to Gateway class itself.

A

That uh controllers would publish on Gateway class status to indicate whether the version of crds that are present in the cluster uh represent a version that they support. This is most likely to be false if the controller was built with, say 080, and it sees that the crds are actually version. V, 1.0, I.

F

A

Not represent an issue, it may still work fine for most cases, but I think it's still worth. You know, raising some kind of warning here to say.

C

A

By the way, this controller does not understand or is in, is not as new as this version of the API, so that you can hopefully update the controller or whatever it might be. Candace got a hand.

F

Yes, I was just wondering uh for the case where there are multiple implementations in the cluster. um What would happen in this case? Is this always going to be her Gateway class that the condition.

A

F

A

F

No, the last word was exists, but it.

A

F

While to spit it out great.

A

Yeah uh yeah, so this is proposed as a status on Gateway class. uh What you may be alluding to is that we, we don't have any coverage for gamma right now because, again similar to supportive features. We have this these Concepts that exist kind of per implementation. So with Gateway we have a very straightforward way. You drop it on Gateway class, okay with class data specifically, and the controller is the sole owner of that thing, and it's basically providing metadata and information about that implementation.

A

We don't have a similar concept for mesh, yet uh we've played around with a mesh resource, and that has not gotten as much traction as I'd like, but maybe as we're, adding more things to Gateway class. That could also be useful for mesh for a mesh resource. uh Maybe that will have some better traction but but yeah for right now. Yes, this is per Gateway cleanse, which means it is something that is clearly owned by that implementation by one implementation. Only uh so I hope there wouldn't be any kind of multi-tenant uh issues here.

B

Yeah um I had a bit of a look at this already, but I haven't done a proper review, but I really like it um I think. One thing that's important to call out that you that you did put in here Rob is that um this is. This is very informational for the user. So the idea here would be that you um implementations must populate this one way or another, but you but implementations don't have to not accept a Gateway class if, like Mark, the Gateway class is accepted.

B

If if they don't think that that it will be a failure. So in the case that Rob mentioned before, where you're written with uh 080 and you see a v 1.0 uh set of crds, then um you may implementations may say: hey you I'm, going to accept the Gateway class anyway and just and just say oh, this is not the version of crds I was written with.

B

So you know, if there's any weird problems you know then it's on you like, but like the yeah, the the um yeah, but also as it says there that you know implementation is made to just choose to say no wrong version. I'm not working, um it comes down to the it's. That's up to the implementation of what you do, but the there must be a uh supported version, one way or another.

B

um So I really like that part, but it's very informational and very easy to explain to people, and it will make it easy as an implementer for you to be able to say um hey, can you please post the status of your gateway class object uh in a sport issue uh and uh yeah that way, um you know as an implementer as an implementor, you will be able to uh see if they're running the right version of cids immediately.

A

Yeah I I hadn't even thought of that as a support issue, but that's yeah. That is actually a really great idea. I think we're getting more and more information in Gateway class status as we go here that will become invaluable uh for support going forward.

A

Okay, so it sounds like there's not much in the way of pushback here. I do just want want to call out to make it very clear that this I expect for many controllers will be the first time they're actually required to watch, or at least look at the crds themselves.

A

uh So just this may this is a potentially or likely an additional API call that you'll be making, um and it's just catching up on chat here. uh Actually there's a couple hints so I'll catch up in chat, uh but go ahead. John I think have.

E

You run this by any of the API missionary folks. The reason I ask is because we do actually read certes and we got yelled at by the API missionary folks that we shouldn't actually be relying on things being crds and should just treat them as resources and if they happen to be serious, that's fine, but not something that our controller should be aware of.

A

Yeah, that's good feedback. uh I will do that. I have not done this by then.

E

A

Was Jordan.

E

Or what it's worth.

A

Yeah good to know.

B

You wouldn't have strong opinions, I'm shocked.

B

uh Dave, did you have your hand up? Were you gonna say the same thing.

C

uh I was gonna highlight um watching the crd might not be enough, because, even though you have like storage version but like you might have a Gateway release that adds a field that would then be kind of like I guess, but in theory, that field should be behind a supportive feature.

A

B

Yeah exactly yeah, that's because the only way that the only reason this is viable is that as maintainers, we are extremely careful about uh not make ensuring that there are no breaking changes. There are no backwards, uh incompatible changes between uh upgrades between release increments, um so we will only ever add optional Fields or do other non uh non-breaking or compatible API changes between versions.

B

um I literally have large sections of that dock memorized. So um yeah.

E

Yeah sometimes.

B

Sometimes one of the reasons it takes us a while to review things is that we have to spend a lot of time like uh in the event we change this. What's the default value, what's the zero value, how does the options work? What happens you? Can you round trip this information between versions and all those sort of API, Machinery kind of uh considerations.

A

Yeah no well said and I think one other part to respond. Is uh it's not obvious? This attempts to make it a little bit uh more prominent, but every Gateway apscrd has this little bundle version annotation on it, so you actually get a sember version instead of like just hey, V1 beta 1 is present in the crdi support that, but you actually get the actual sember Gateway API release number, uh which is something like that has been hard to do with other kubernetes apis for.

B

Yep yeah so like I, think that, in my mind, is the reason why we need to. We need to watch the full Gateway, API I think that yeah I can understand where Jordan comes from, but in general uh you know it's not a great idea, but for Gateway API, because we are Distributing this uh as the thing and we've already defined that there is that label um and we're not. We are reading to look for the labels, not for anything else about the about the schema.

B

um I think those are the important points, probably that since I won't be able to be at an API machine, um yeah.

A

And and I think this is uh yeah I'll see I'm very interested in what that feedback will be and I think that's a good good call out, because you never know uh but I I think with uh with Gateway API. We basically have this mandate that we are going to be a crd based API one of the first, and that is that is our journey, and so we got to make the most of it.

A

I, don't think we're ever going to change that stance, um but uh we'll see and yes, uh metadata watch yeah, maybe I mean this- could maybe use some implementation guidelines as well, um so yeah I think it could be a metadata watch uh and it could potentially look for a specific label. It's so your.

F

A

Watch of a subset of those crds uh would be all you need for this, uh and you yeah. There are some implementations out there. Dave is calling out cross plain, which has thousands of crds, uh so yeah being able to limit the number of resources. You're watching is a pretty big one um cool all right, any any last feedback or comments on this one, I I will there's a hold on this already I'll make sure I get some feedback from API machinery and others before removing that hold.

A

But please also, if you're somebody who would be on the other side of this is actually implementing it. uh Feedback would be very welcome.

C

B

C

B

Is definitely relevant to that thing that I mentioned beforehand about the implementer's guide.

A

Yes, yeah very much yep cool all right, I'll keep on moving, then uh timeouts Gap is coming up. uh I think this one is just Simone's.

F

A

Implementation of this uh we've gone back and forth on a few review details, but it's approved it's waiting for someone to just do the final LG TM. uh That was uh some test issues, but I think we've cleared everything up. So if anyone is available to do one last round of review, we can get this one in and it will fully be in scope for the 1.0 release of Gateway API um yeah.

B

We'll probably hold off on merging this one, though until 081 comes out right, Rob.

B

A

That's the the one place we actually Branch, For, Better or For. Worse is uh all the releases so yeah um yeah, and that's it for that one. The other thing I just want to celebrate. uh Thank you, Candace. Thank you. Everyone who reviewed this the TLs tobacco and GAP is finally merged.

A

uh It has been a long process, but uh thank you for the persistence. Everyone. uh There is a pretty clear, Next Step, uh and that is that, because we're introducing a multi-tenant what I would call a multi-tenant policy, which is something that will expect many different implementations to support. uh We need the policy to also be able to expand to the policy status, to also be able to expand to represent this, so this will almost certainly look uh like route status.

A

I think Nick has volunteered to actually Define what that looks like in just uh basically one more extension of the existing policy Gap, but that's the next step on this one, uh but we are making very real forward progress and definitely hope to get this in scope for 1.0 as well.

B

So yeah I think um Rob has called out a couple of times that that Gap is very long uh and is hard to pause as a result. um I agree, but I also think that um sorry.

B

I also agree that um but I think that, uh once we can finalize more details of the Gap um that it will be better to um uh to uh split up the document and um and fill out the document then, and actually probably once it goes to I, don't know how.

B

If we, if we're going to call this standard um once it goes to standard, then then we should split up the documentation and make it just a part of the website documentation instead, rather than it being all in one big Gip um right now, I actually did the opposite of that, and I have actually pulled all the documentation off the website and said: go read: The Gap um while we get the details finalized, but once as this gets closer to standard, that will be a to-do that I'll take as well as to break this thing.

B

Apart into um a more readable plausible doc that has better headings and more and better navigability, um yeah.

A

Yeah now that makes sense. uh Thank you for kind of being the steward of that cat of that Gap I know it's a massive one uh and I look forward to the day when we can get it to standard when we can split it up, and you know whatever, but there's a lot of work streams in progress around this one.

A

F

D

A

Those are the main things that I'm aware of on 1.0. Usually I go through the release, blockers list as well, but I think right now, if I remember correctly, every single one has someone assigned so I'm going to call that uh uh a success and.

C

A

We'll we'll go with that um next up, just uh real quickly want to call out kubecon, unlike previous coupons, we're actually considering doing something like that. We would actually need to have a headcount for in advance and actually you know, send out, invites and and all the rest and so having an idea of who's actually going to be present and interested in being part of Gateway API. Anything, please do. Let us know uh you know reach out. I guess on slack is maybe the best way uh to to follow up.

A

uh We have a rough idea, but please, if you're gonna be there just just let us know so we can make sure that we uh invite you to to anything, that's Gateway related and that we have enough uh enough space.

B

I actually suggest everyone put your if you're going to be a keep going put yourself down in that underneath that agenda item I will start.

A

Yeah that works for me.

B

That way, we've got who's going to be there and we can make sure that everyone who's going to be there gets invited if they wish yeah and if you don't feel comfortable. Putting your attendance in a public document. That's fine, being Robert.

E

Yeah I was going to say there might be somebody who does not want that to be public information. So, like.

B

Yep, that's fine ping, one of the maintainers. That's fine, but like the.

B

And I I see you Dave wow Dave.

C

Yeah yeah, who.

A

C

What's going to happen, October 30th.

A

Oh man uh yeah, so they have to definitely uh understand uh you know and I know not everyone knows everything, but if you think you might be we'll invite you we'll make space for you just just you know want to make sure that we uh include as many people as we can.

E

Yeah yeah I decided a few links to talks as well. I probably miss them so feel free to add some, but this was just a few weeks ago, I or whenever it came out. I looked around.

E

Related ones, yeah.

A

If, if you, uh if you didn't see Tim's, this is going to be a fun one uh talking about all the failures of service API service, the API uh in kubernetes- and he only has five minutes so we'll see what he can put together. Yeah.

A

uh Actually, speaking of Tim, I I think uh oh uh yeah, how do we get across to the slack channel? uh Maybe yeah? Maybe somebody else can can drop a link in there, but it's uh if you Google kubernetes slack, it is not trivial. There's! Actually one thing you have to do to request an invite to slack and then you'll you'll be added in, and somebody can probably link yeah kubernetes dot slack. Thank you um all right. So yeah. Thanks for adding the Kube contacts, I am looking forward to seeing people there.

A

Whoever can make it and uh also appreciate and understanding that not quite everyone will be able to be there either um yeah. You know one of the things that uh so uh John added a link to a talk that Nick and I are planning to give the most collaborative API in kubernetes history. At that talk, we are trying to do everything we can to represent and thank all the people that have helped make this possible.

A

uh This has been a very much a team effort, so, uh if you're able to to make it to this specific talk, we we would like to recognize people that have contributed there. uh So again, just uh yeah want one more thing, uh but there will be others.

A

So, just if you, if you uh know that you're going to be there I, will try and find you on slack this way to get more information like your contact information, uh if we don't already have it, uh but if you're not easy to find on slack, maybe just you know put a parentheses slack handle.

A

If you know, if we don't know who you are um yeah I think that's it uh I don't have anything in triage and it looks like nobody else does either so I'm going to call that uh the end of the meeting. Unless anyone has uh any last things to.

B

Say here, Candace Candice has a good question in the chat Rob.

A

Oh yeah, well, that's uh I mean it's official, uh no I I, don't know I I would say it. Hopefully is um you know one of the things that I think is very unique about. Gateway API is that we have more than 100 contributors uh that have contributed to this API already and that continues to grow.

B

A

B

Think I think it's actually correct because, because most of the time the API design stuff in core kubernetes is, you is mainly done by like a very small group of people, because the API design in core kubernetes is pretty scary.

F

A

Yeah the way, the way we could measure this would be. You could look at uh the people who have contributed cats that have modified service. Api I. Think it's a pretty small list.

A

um We have tried I I, remember with Ingress when we tried to go from Ingress beta to Ingress GA and made many mistakes along the way I'm very familiar. uh But you know that was. That was an example where we had meetings. We tried to get uh as many people as possible to contribute, but in the end it ended up being uh basically two or three people that helped contribute uh that that API transition and it's it was just really hard to collaboratively work.

A

Entry on core kubernetes apis um yeah, so anyway, I I think it is. But I am I'm happy to be proven wrong, um good question and and yes, we can always use uh Shane's uh Shane's terminology, the most collaborative Network relate related out of free API. So anyway, um yes.

B

John has a very good point. Yes, okay, where uh talk titles are not the place for nuance right.

E

Just make it the case before the talk right, yeah, yeah, I'm, sort of meant, giving a talk about something that doesn't exist yet so why can't we make it the most collaborative API yeah.

A

Cool all right, well, I, think that's everything for today uh thanks everyone I look forward to seeing some of you at kubecon and uh please, as always, don't hesitate to uh to add things to next week's agenda, to help with reviews Etc um see in slack on GitHub Etc and have a good rest of your week.

F