Kubernetes SIG Network, 23 Sep 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Gateway API Office Hours for 20200923

Description

Service APIs Office Hours for 20200923

A

All right welcome to service api's office hours for september 23.. um This could maybe be a short meeting. I'm not sure um we have uh a dwindling release checklist, which is always great news. um I I want to focus today on the few prs. I think there are four pr's I've identified that are super close to being mergeable. uh Maybe are you know all feedback is resolved and there's some form of lgtm, but not official lgtm on it kind of thing. um So that includes the tls on route listed here.

A

That includes potentially gateway selection. uh This one we're gonna talk about more today. The gateway class authorization. Well, we'll probably talk about all of them, but um there was an interesting alternative proposed for this, but I think the pr itself is mostly good as it stands and then finally backend policy also, I think we've mostly reached a consensus on uh and then today, james pr for gateway status got in as so that leaves, I believe, gateway class as the remaining primary resource that needs conditions added to it.

A

There may be additional work needed, but we're getting awfully close.

A

I have a absolutely massive api cleanup pr. That is a mess right now.

A

I I started it and then I I wanted to prioritize getting my other prs in first just so that I wouldn't constantly be rebasing against myself, which I started doing, and so I'm hopeful that we can get a bunch of prs in today or next 24 hours and uh and then really make progress on that api cleanup, because I think it's it's fundamentally close as well. It just it just needs to be split up a bit and made easier to review.

A

um But that's that's my understanding of where we are beyond api cleanup. We also have some a lot of work to do around documentation and even some improved testing to verify crds would be fantastic, but I think that's it. I think that's everything for v1 alpha 1..

A

If anyone knows of anything that is missing on this list, definitely let me know. I also linked here to the milestone itself, because this in some ways is more up to date.

A

This includes a lot of things that are already in underworks underway. um Some of these are covered by my api cleanup. Pr and the reason I did just one massive pr is: it felt like anything like admin items to all fields is going to just conflict with anything that you know admin length, you know you're going to be changing the same thing. You know very similar fields and very similar files, so it felt maybe less bad just to try and chunk that up into a larger pr um anyway.

A

That was the rationale for that um yeah. That's that's the status of everything, as I understand it right now uh with that said, let's take a step back and talk about back-end policy for a second.

A

Back-End policy was uh or is an uh an interesting concept. uh There has been some hesitation around the concept of a resource at all and then there's been separate hesitation around how generic the backend policy name is, and I thought oh well, you know I can. I can solve this with one of those cool slack polls and we'll have a really clear consensus on what to do and unfortunately it there wasn't quite the same consensus that appeared before I'd say.

A

There was a very slight preference for keeping the name as back in policy and because that is the path of least resistance. That's what I'm tempted to do, uh but I I I don't know of anyone that feels very strongly on name here. I think the two, the two favorites were back in policy and back in connection policy here.

A

um So at least for now uh my my preference is to to stick with uh what we, what had originally been proposed.

A

um The one thing that I know had kind of been mentioned in the documentation for back-end policy, but was never really documented. Well, what's kind of in the back of my head, I've been thinking.

A

Maybe we should allow some kind of superset pattern here, because so gke we already have some kind of crd that is similar in nature to back-end policy, but it includes a lot of implementation, specific things, and we know we can't you know we. You know it doesn't really make sense for those implementation, specific bits of config to all live in open source uh and there are limitations as far as what can be done with extension refs, you don't necessarily want an extension ref for each little. You know policy, you know annotation whatever it might be.

A

uh So an idea that I had- uh which I think may be a reasonable compromise- is to require all implementations to support. Back-End policy and back-end policy is where core configuration lives, but implementations may choose to provide their own version of back-end policy that includes all the same fields, all the same config as back-end policy, plus implementation, specific config.

A

On top of that, this is a pretty different idea and I wanted to throw this out there and see if it sounded like a terrible idea or if it would be useful to any other potential implementations um and to clarify I'm not saying I am still saying everyone should still support back-end policy, I'm just also saying, if you want, you could also do this. One other thing.

B

So that sounds like a promising idea. uh What, if you support back-end policy, and you have another crd to support implementation, specific things right like like things like tls, have like. We have tls right now in back-end policy, if you want, let's say health checking or you have another policy that is implementation specific. If you don't settle on an api in the core or extended part that.

C

B

Lead to, like you know, crd explosion, so yeah.

C

B

One crd does help with that.

A

Yeah that that's, that is exactly the problem we've been trying to deal with, because we already have that you know that kind of custom, implementation, specific config and we're trying to grapple with this idea of okay. So previously users would have to configure ingress, and this you know crp right and now we're saying: okay, you have to consid, you know, configure gateway, class gateway uh route and backend policy.

A

Plus you know our implementation. Specific stuff, um so like, like you say, cr crd explosion is, is a good term. Here um I don't know, there's definitely potential messiness with the kind of superset pattern I'm describing here. uh It's just it's all trying to find the right balance between you know complete isolation and somewhat reasonable user experience. You know one of one of my concerns with two completely separate crds here is that as an example, some users may uh yeah it. It feels it feels not obvious to a user.

A

Why some things appear in one crd and one thing's app. Some things appear in another crd and then yeah that I don't.

B

Know I agree, I agree with that, like I, I get that feeling too. So I understand that.

A

B

A

And it's not yeah. This isn't something we absolutely have to specify at an api level. I mean this is fundamentally, you can be compliant with the api, we're still requiring that everyone support back-end policy. It's just an interesting approach that some implementations.

A

May want to choose, but I I'm not sure we haven't. We definitely have not decided on this approach internally. It's just one of the things that I've been exploring as an option: yeah, okay,.

A

Any other thoughts on that kind of.

A

A

All right well we'll keep on moving. um My guy had a what I thought was a really interesting idea, and we talked about it some end of last week and into this week a little bit.

A

um I I linked to a comment that I think is maybe the best description of what he was proposing, but maybe mike do you want to take a few minutes to explain what you are thinking here.

C

Yeah, I can try to explain so right in this pr. You're, suggesting or you're proposing the gateway class should say.

C

These are the namespaces.

C

Where a gateway can select routes right.

A

C

A

It's where these are the these are the name spaces where a gateway can use this class.

C

Right, okay, yeah. I think I had that backwards um right. These are the name spaces where a gateway can use a particular class, and that's that's a specific api field and it's kind of the intention. There is kind of access control right and it feels like kind of an odd api to have in there uh like a field, that's related to access control when we have a whole rbac system, where you can define cluster roles and role bindings to configure our back.

C

So my suggestion here was instead of specifying it in the object in the gateway class.

C

You specify cluster roles to say uh this role allows you to create a gateway, the gateway class, with this name or gateways of this gateway class. So you would define roles, you might have one role that just allows you to create any kind of gateway of any class or you might have more. This role can create these fancy load, balancer gateway, class gateways, and this other role can only create more basic, maybe less expensive uh gateways of a simpler, more basic gateway class and then uh right as the yeah. This. This is a good illustration.

C

So the suggestion is, you would have, you would use our back to say this role can use this gateway class by gateway class, the gateway classes, resource name, and then you would bind that role to a service account. My suggestion was the default service account and a namespace to allow to allow whoever has control of that namespace to use gateways of the gateway class in question associated with that role and the default policy could be allow any authenticated user to create any kind of gateway class.

C

That could just be the default policy default, cluster role and role binding um and if that doesn't satisfy a particular clusters needs or cluster administrators needs, then that role binding can be modified or deleted and more fine-grained roles and rural bindings can be defined.

C

Does that make sense.

A

Yeah, that's a that's a great description of this and all right I'll just say my personal perspective on this is that I I love I. I love the idea of using our back for this.

A

uh What where it started to throw me off was just this last bit of what you're binding to because- and this is I guess, where I've been as I've been thinking about it more I've been trying to find any component that we could add that would have both access to the resource and the authorization and like and the user or group associated with a request right because it seems, like you know, with a validating web hook, you just get the resource and with authorization you just get the authorization and the resource name, but not the actual resource content.

A

Is that that's my understanding? It's hard it's hard to find something that would enable us to actually bind this to a user or a group, and and that's what I would absolutely love to have work here, because you know if this could work like vanilla, our back I, this would be the dream. In my opinion,.

C

Okay, well, I think that should work fine, maybe I'm kind of used to thinking about service accounts, but the subject in a cluster role by binding.

B

C

Role binding can be a user or a group. I don't think there's any reason that wouldn't work in this case.

A

Yeah I get that yeah. It doesn't. I guess to me it doesn't matter so much whether it's a user service account group, whatever the problem is the actual thing that is creating a gateway like the the way that the way that you've defined this, as I understand it is you- are granting this access to a namespace you're, not you're, not granting this access to a service account you're, granting it to the namespace in a kind of indirect way right, and so this can happen within that namespace. Not ex-user can do this.

C

Yeah so yeah this example here is kind of my attempt to model um what you're doing in the pr that is to enable it for a namespace. um Maybe maybe we can step away from that model. uh I'm not sure why I didn't suggest this before, but yeah we we might as well say this user, or this group.

A

C

Can create gateways of this class is? Is there any yeah yeah that that should be fine there's that should be possible with the cluster role binding here? If you just change in subjects instead of specifying.

B

C

Account name default, you can specify a user or a group.

A

Where would we enforce that so, like I, the r back, there is perfect to me, but I just don't understand how we would enforce that.

C

Right, that's um that would require an admission controller that can perform the subject, access review and reject- if you don't have this use permission for the gateway class in question, uh and that would be an additional piece that we would need to implement.

A

And does an admission controller have access to both the kubernetes resource in question, as well as the authorizations of the users of groups associated with the request.

C

I believe so um I might be missing some detail there, but yeah. I think that should be possible. Okay, okay,.

A

Yeah, no, that that's really interesting, I yeah that's that's where I was getting hung up, was uh finding the place inside kubernetes, where we could actually implement this kind of custom authorization where you like, as I understood so like a validating web hook. As I understand it, you just have access to the resource. You you don't have any concept of who who's trying to create. It is that correct.

C

hmm uh I think you must have uh you must be able to tell who's trying to create it otherwise. Well, I I need to look more at how admission controllers actually work. I can try to put together a proof of concept to make sure, okay, that that is possible.

B

A

Yeah I mean this, you know if, if we can find a way to do this with our back, I am wholeheartedly in favor of that that that feels like especially what was throwing me off with this proposal is that it was binding to something that didn't feel natural you know, but if, if we can find a way to bind to the actual user performing the request instead of this can happen in this namespace um that that feels amazing to me, um I, my my one caution is that this may end up being just too large of a change to try and get in pre-alpha, um but I I am open to uh to feedback ideas whatever on that, um I I will, from my perspective, even even if we roll with this proposal of a selector in v1 alpha one.

A

I can't imagine anyone is going to be upset if we change that to use our back in the next. You know we re, we deprecate this concept and instead suggest using our back. uh I I don't know um I'd be interested in just understanding in the next. You know I don't know a couple days if it's possible to use our back for what we want to do.

A

I I don't know.

C

All right I'll work on a proof of concept. It's been a while I've done.

C

Mission control controllers before but I'll do a proof of concept to make sure this specific um approach is feasible.

D

A

That'd be great, I mean, because I know you can do that like like what you're saying you can do a subject, access review see I I thought that the way you proposed it the way this way is because everything you proposed, you could do with only seeing the resource you didn't need to know what user was performing the action you could.

A

You could do this entirely based on the gateway and what namespace it was trying to be created in, but if you can not just see that, but also see the user or group or service account that is acting on that even better.

A

Yeah, this is an interesting idea.

A

uh I know I've I've kind of said most of the feedback here, but I should open it up. Did anyone else have any any thoughts or ideas on this kind of.

A

E

This only a thought is that I do agree with what you mentioned rob is that um I think for v1 alpha one kind of stick with what we have and then explore this direction afterwards.

A

Yeah yeah, that's this. This feels like a a lot of work to get right and you know it would it. I think it would require having some kind of controller to even really be able to uh to implement it, some kind of shared controller. So I yeah my my personal preference is to push this to v1 alpha 2, but that does not mean to slow down uh looking into it because I think it I I'm I'm really interested in this approach.

A

I've been struggling as we've all seen for a long time with finding the ideal approach here you know, I think a namespace selector is at least there's some prior art and the term. You know network policy or something like that, but it it is never particularly loved. It's a thing that works, but it uh you know if we can use our back all the better because, unlike uh mike I, like, I think many have said, this is primarily an authorization problem.

E

And it's like they're benefits to both ways. Right I mean taking the approach that makai is suggesting or you know we're utilizing existing.

E

You know our back facilities instead of creating something new, um but on the other hand, it's like a lot of people, don't understand our back and, and uh you know, with the name, space, selectors and so forth. It's it's just an easy concept to understand. Yeah. So.

A

Yeah you're completely right.

C

B

C

Of concept and some more examples and yeah, it's fine- I I don't object to. um I don't want to hold up the view on alpha one, so I don't object to working on this um as a proposal for v1 alpha, 2 or v1, beta 1 or whatever.

A

Sounds great thanks so much yeah. I appreciate this proposal. I think it. I think it's worth digging into a little bit more.

E

Yeah great, so maybe I missed it in here. um If you go back so uh is there a like a separate issue that either makai you've created or should be created and kind of port over some of these ideas to that issue for tracking purposes.

A

Yeah, that would be great uh mike, if you don't mind, creating a a follow-up issue, just to kind of maybe summarize the proposal that you've already made in the in these comments, I can probably copy a lot of this content over it'd, be great just to track progress on that separate this pr.

C

Okay, I'll do that.

A

A

Okay, and with that, I think we're good to move on to pr triage uh I'll say you know this. This may be far too optimistic, but in my ideal world I'd love to get. You know. I think there are four pr's that are just super close. I would love to get those in in the next 24 hours and then you know, ideally again perfect world I'd love to spend part of tomorrow's meeting going through uh the cleanup pr.

A

I think, there's a few more things I'd like to discuss as a whole there, but I've already gotten some great feedback. Thank you to everyone, who's already reviewed it, um and once we get these kind of impending prs in, I can do a rebase clean everything up and there won't be quite as many conflicts, so that is that is my goal here.

A

With that said, uh let's start, I, you know we'll get through all of these one way or another, um so I don't think that the order matters too much. um This is the bi-directional gateway selection. We've talked about this a few times. I don't think there's going to be any surprises left in this one.

A

Oh, there is okay.

B

Yeah, so I just was going to approve it, and then I figured that it. I think I think that it is not possible to list a gateway from another namespace, so you know how we have.

E

B

We don't have that so yeah we'll need to change that, and we also don't need a name and a group and a resource here.

E

B

C

Know that we are referencing.

B

A gateway here.

A

Thank you yes, you're right and yeah, so I really just need name name space. Thank you. That is beyond obvious. I will fix that um yeah good catch.

B

See you tomorrow.

A

Okay thanks: this is apparently why every pr should include examples, um and I I'm pretty sure I did not add an example here, I'm sure I would have caught it then so.

C

A

Okay, well, otherwise, I, unless there's any you know additional feedback on this one. I think this is just awfully close at this point. uh Was there anything that I, if has anyone left feedback that I have somehow missed or not responded to on this one.

A

Cool all right, the next one I want to run through back in policy.

A

This one also has some form of unofficial lgtm here, um and this you know, was actually just harry uh deferring to danian in this case, since I know, you've left some comments as well, um so not not to put you on the spot or anything damian. But if, if there's anything, that's left over on here, let me know otherwise. I think this may be.

A

This may be good and yeah.

E

Yeah, I need to take a look at all. The pr's in the queue today have been wrapped up in some other things, so cool yeah and I'm not sure at this point. Can I slash lgtmed or go yeah.

A

Yeah you can, you can absolutely do that. I need to ping bowie to make sure he approves the maintainers pr, but yeah you can. You can so slash. Lgtm is any member of the kubernetes sigs org, which I think you are um and so yeah feel free, um yeah, cool um and then there's just a couple. Tiny ones left uh the downstream tls one I added harry has resolved all feedback.

A

I'm pretty happy with how this looks now. So I added an approve but wanted to. You know defer to someone else, doesn't matter who uh to add a final lgtm on this one. But to me this pr uh looks good. I think you know harry added. I think three different examples now um and otherwise I think it's it's it's in a good place. In my opinion,.

A

And then the very last one that I'll cover is uh the actually no. We should okay, so um this one is generally lgtm. Given our last conversation um again, I think this was just waiting until we could resolve this conversation.

A

Maybe as soon as maikaya uh creates a follow-up issue on this, uh we should go ahead and get this one, and I I think this is probably also good to go, and I I mean really. You know I hate to rush these in, but I would just love to get these in so that you know follow-up prs, don't have to rebase a bunch uh as one each of these move.

A

You know go in one at a time and the very last one is this one, and maybe we should talk a little bit more about naming, because naming is always fun, um it's funny, because, yes, this is a the allowed gateway. Namespace selector was a painfully long name. um Your suggestion was gateway, namespace selector, I elsewhere. I am suggesting allowed gateway namespaces uh and both of these kind of come from the world where gateway class had fields that related to both route and gateway, and we got rid of the route field.

A

So we could, even potentially you know, shorten this further to be. You know, namespace selector or allow namespaces or anything like that.

A

um Don't know I I don't have a super strong feeling on this one. I think I I prefer a loud gateway namespaces over gateway, namespace selector, but I don't know um damian. What was what was your uh motivation for name change here.

E

I mean mainly brevity.

A

Yeah of the of the names suggested here in this comment: do you have uh uh you know like uh it sounds like you might prefer gateway, namespace selector over allowed gateway, namespaces, yeah.

E

The other piece of it uh first was brevity and then that's the second part of it is yeah. I looked at just some other instances in the apis and and saw kind of the the suffix of selector, and so I think that's why I went with dropping a loud and going just with the gateway name, space selector.

E

um So that's fair! That's that's!.

A

What I was thinking um yeah, I don't mind that, do you.

A

Do you have any? Do you think it's important to say gateway here, or could we infer that because this is by definition gateway class like? Could we get away with just namespace selector.

A

A

I don't even know if I'm suggesting this, I just wanted to throw it out there for the sake of brevity.

E

Yeah, we probably can. Let me let me take another look at the pr and um just do one last kind of passover and see if, if I feel otherwise but um yeah, otherwise, namespace selector, I think, will work.

A

Yeah, I don't feel too strongly on this one. I I as long as you know, I feel like gateway name. Space selector allowed gateway, name spaces are both equally easy to understand. I don't mind you know selector, you know I. There are a ton of fields that have selector as a suffix, and that is clear how that field should be used. So I I get that uh idea and then you know again between name space, selector and gateway, name, space, selector, yeah,.

E

I'll I'd also be open to dropping the selector suffix um and you know they're doing the allowed gateways or gateway name spaces, or something like that. I don't know if, if I mean with other fields, do we kind of add a suffix for kind of you know for the type you know what I'm saying.

A

Yeah uh yeah, not necessarily, but I I think the more I thought about this. uh The selector suffix probably does make sense, uh and the reason I say that is: we have a concept of route name spaces on gateways, uh and that is uh not a selector directly. It's route, namespaces namespaces.selector like there's a selector field inside of it. So if we had a gateway named faces field that was a selector and a route namespaces field that wasn't. I think that would be confusing.

A

So, given that I do think a selector suffix probably does make sense. uh It also allows us in the future if we want to support it, to expand this, to have say a list instead of a selector. I don't know if we ever will, but it does make it clear that this is purely a selector, not a list, not anything else.

A

E

All right, let me take another look at this as well. As uh you see, I wanted to put a hold on until 285 merges just um because I feel like this was worth messing up any of the work on 285. So just wait for that to merge.

A

Perfect, I appreciate it. I think I think we're getting awfully close here and uh yeah. Hopefully we can get a few of these in in the next uh 24 hours or so and I'll be shifting my focus over to this uh cleanup pr, and I think uh we've got lots and lots of work to do on documentation if anyone has some uh some time to contribute.

E

Or on the documentation, I started to just kind of think about it and there's an issue on one of the docs or one of the doc issues that I commented on. um The user guide, I believe, is: I can go there or.

D

Did I not add it here, um go back, maybe it's a the cookie. Is it the cookbook or no? I guess I didn't yeah. I did have a cookbooks issue. I thought.

B

D

On this one either, I don't know, I wonder.

E

Wonder what happened there anyways? um Let me go ahead and comment on that and basically I was just trying to kind of sketch out okay. What do we want the user documentation to look like right? I mean like.

B

E

Of the user documentation, it's like, okay, you know, install the crds and that's you know we gonna.

E

Is it simply that easy of make install right um and then you know like a configuration piece referencing some of the config samples? So let me let me make my notes there. I had it. Maybe I just didn't save the comments and uh my uh my mac.

A

Here, updating me yeah. Let me let me dig into this too, because I think I think mark had worked on some kind of uh he's he's a pm here. He he worked on some kind of user guide. That could be generic enough, that you know any any implementation could be plugged in.

A

You know at different parts, um and so maybe maybe we can use some of that here, but that that doesn't answer the full concept of how we should structure our docs as a whole, but I think you're right that we we need to think through exactly how we want to structure a user guide in a reasonable way right, but also in a way that's kind of, like I think someone had mentioned this last week, that's kind of like the current congress docs, where there's uh you know, references to all different implementations of the api.

E

Yeah, it's funny. You mentioned the ingress stocks because that's what I had pulled up to just trying to use that as a reference, um and so you know my mind is basically saying: okay, you know our docs should be pretty similar to what I posted in the in the chat window and it's not necessarily like the way.

E

The current doc site is organized um yeah, but you know I think, using this as a reference model and and then obviously we're dealing with more than just a a single resource like ingress but um yeah. In my mind I was saying: okay, let you know, let's use this as uh kind of the starting point um yeah, which kind of covers all the different things from like how you know. Example, installation- and you know background of what each of the resources would be.

A

Yes- and we have this uh secondary section, which is about different controllers- that yeah yeah- that uh this this all makes sense this. This will be a good, uh a good resource.

E

Here and then I thought also just from a user standpoint is like having that comparison of okay, here's the sample ingress and here's what it looks like the service apis.

D

A

Yeah that that's actually a great point having having some kind of side-by-side comparison, especially, I think what we're going to well. Almost all of this is going to be it. You know: translation between ingress and hdp route,.

A

But I think I think that would be very helpful to see the difference here. Yeah that that's a great idea.

E

So let me make some comments in that issue um and yeah before I think before we kind of dive into okay, we need to create the user guide or this I think, actually just pausing and saying. Okay, let's look at how things are organized.

E

um Let's look at you know references like the kubernetes docs here and figure out. What's the best way that we structure this information.

A

Absolutely agreed yeah. Thank you for, uh for that idea. That's uh that'll be great to have a plan before we really dig into it and uh I'd also yeah. I think any comparison to the ingress api is going to be remarkably helpful because that's where at least initially a lot of potential users are going to be coming from.

A

So yeah that this is a great idea and hopefully we can- uh we can find ways to also make it look relatively similar to this as well yeah, okay, um I I'm I'm hoping that we can have our api mostly frozen.

A

Almost frozen. Well frozen is a strong term, but you know very minimal changes uh by sometime next week and then we can. You know it's a lot easier to work on documentation once the api is pretty stable and I think we're nearly at that point.

A

um You know I I hate to as an example, uh one of one of the prs. I have right now, flattens all http route, I'd hate to have someone go to a lot of work to create all these. You know examples between ingress and http route and then everything gets flattened and you have to redo all the examples, as you know, but hopefully we can get that in really quick, well, relatively quick and just purely focus on documentation soon, yeah, okay!

A

Well, I think that's all I had today uh any any other things we should cover or is that it.

E

I had a question uh just out of curiosity somewhere in one of the pr's or the doctors. I see reference to um validating, webhook and so would the web hook. Would that be part of the service api's repo, or would that be something that implementers are responsible.

E

E

Okay, lose everyone.

C

Hello, I hear you, I think we lost robin.

C

Yeah I hear you dean but not rob yep rob you're unknown.

A

Thank you. I am definitely on mute. I I was, I was telling a great story and you missed it.

A

Yeah, I was, I thought I heard someone talking like well. This is weird: why would someone be talking when I'm talking yeah anyway? Here we are um yeah? We have every intention of uh of making that part of the core open source, not an implementation, but shared code base. If we want to call it that so certainly a validating web hook, you know, just if you think of validation as something that is handled by open source uh like by this repository, then bundling a validating web hook.

A

Inside of it probably makes sense, what is less clear is how that validating web hook will be deployed, even if the code lives here, the image is built here.

A

Maybe it makes more sense, for you know, implementations and their installation instructions to I'm, I'm not sure there. I don't think we've answered that yet, uh but I know I know pretty. Certainly, it does does not make sense for every implementation to try and implement the same validation logic and and as a kind of separate point uh james had uh in one of one of the conditions that that went into gateway yesterday today, whenever it was, as proposed by james, uh was a uh no such gateway class.

A

I think that might be a reason, not a condition. I forget, but the idea that there is something on gateway uh that indicates that there is no such gateway class and I think there are a couple other examples of conditions or potential conditions we might want to add that are going to get messy if we require uh implementations to write them.

A

Okay, that that's that's a a very specific example, because every controller watching that gateway is going to say, there's no such gateway class and if every controller tries to write that- and one controller somehow thinks there is a gateway class matching that you're going to have this like really terrible race, where they're all kind of fighting each other.

A

So there may be some some space for some kind of shared component to update status as well uh for not validation. Like things, but that that has not been, I don't know of any kind of consensus or agreement there. That's just something that uh was mentioned in uh pr discussion.

A

So but yeah I I think I think that's something that uh we have said we'll actually worry about implementing once we release the v1 alpha 1 api, so we'll be based on the v1 alpha 1 api, but we're not actually going to block the implementation. The the api release on the implementation of that webhook.

A

Yeah, hopefully, that makes sense.

E

Yeah it does cool. I appreciate that.

A

All right, well, I think that's that's! It was there anything else that I missed.

A

Great okay, well, thank you everyone. uh This has been uh very helpful and hopefully we can get uh a few more prs in and keep on moving we're getting close.

A

All right talk to y'all later.