Kubernetes SIG Network, 2 Dec 2020

Previous Meeting Next Meeting

⏯

youtube image

►

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

Description

Service APIs Meeting (APAC Friendly Time) for 20201202

A

We are recording this is service, api's meeting it's our first meeting at our new time december 2 2020, and also our first meeting uh once we released uh v1 alpha 1.. uh This agenda ended up being fairly long for the day. uh It's mostly just because I added a bunch of notes, questions comments. I don't know that any one of these things will take uh forever to get through, but I did want to at least.

A

Add them to the list to make sure we covered them so with that bowie, I think you wanted to talk a bit about the landing page and uh how we might be able to improve it.

B

Yeah I was uh looking at this. I think the landing page is good in if you wanted like a deep dive on the service apis.

B

The one thing I kind of wanted to see how we can to sort of add to this is like there should be a quick start link, at least from the very top like a tldr that sends someone to one of the guides uh getting started or sample gateway.

B

I think this one right now, it's a little bit intimidating because you're first thrown into the whole multi-role uh business. So I was wondering if other people kind of went through this.

C

Bowie one one thing I was thinking is that we would minimize to take the um basically take the example out of this page and just have this about installing the crds and then maybe links to. We could also maybe put links to you know open source implementations here which would link out to those pages and then um and then the next one would be simple gateway, and then, after that would be, you know, basic http route matching and then so on.

B

Yeah, I think like right now from our landing page. um I think these are okay. We can work on them, but basically from the landing page. It's just like uh it feels like a college textbook kind of like like here. Are these, like you know, super big concepts, uh very, not as much concrete stuff to kind of for the common user to kind of grapple with.

B

uh So my main comment is like: we should probably throw something at the very top that basically gives like a fork in the road.

D

B

You care to learn the concepts or do you just want to see examples and learn that way and then just kind of shut them off to one side and then the other people who want to go and deep into the concepts can have another route.

A

Yeah, that's an interesting point. I I think for me. If I were browsing this site, I would immediately see guides and just go over here and run like this is probably what I would focus on first as well, but but you can get to it, but maybe there is a better way, a more prominent way to link to this, because I do think uh for a number of people. They will want to just walk through introduction, getting started, etc.

A

To understand this, um but that's not going to be everyone.

B

Like, for example, I was going through the introduction page, we don't link at all to the guides here. I don't think until they're, like pretty it's yeah, it's down at the end here, yeah yeah, like you, can't find it so I will send a pr, but basically like it, should be at the very top that you go to landing page.

B

If all you care about is just like a concrete example, then you can just go through it right away.

D

A

Yeah this, this will be a lot more helpful when we have uh implementations that we can list here, um which I guess is a good segue into uh your next topic. Bowie.

B

uh Yeah, like I think um now that the api has been cut, we should start tracking in this group uh sort of how people are progressing on the implementation uh number one couple of things like one is, you know probably the next thing we're looking at is conformance, so we can start that up, while people are booting up their implementations, the other one is like as soon as you guys have something available.

B

We can throw it on the page or try to think about how this would appear on the page, so that people can try it out uh and then third, it's like it's cool to basically pc demos from various groups who are implementing the api.

A

John, it sounds like istio is fairly far along here. um What uh is there any anything we can link to for something that could be useful right now, like used to test this out.

D

Yeah we, we have a small dock that basically says install the crd flip this flag on because it's off by default and then link to these docs because we don't want to you know, maintain a copy of everything here. Basically so that could easily be linked from here. I suppose, okay cool, is that it's.

A

Basically, like installation.

D

Okay, uh yeah, let me send it to you, I'm pretty sure it is. uh I maybe I didn't get it merged. uh Let me get the pr merge and then I'll send it to you.

E

E

I know the contour team is looking at spinning up an implementation soon and nick was working on some design docs for that, but nothing nothing had to link to, but I know that's going to happen soon. I know the the redhead folks also want to get want to use that as well. So I think we'll have a something to play with soon.

E

Cool that'd be awesome.

A

Bowie or mark, do you know of other implementations that are are in progress here or anything yeah.

B

I was just going to say to mark that uh we should reach out to some of those other folks who are participating.

C

Yeah, I think traffic had something uh that they were ready to share.

A

Cool I've noticed uh we've gotten some great uh prs coming in from k native maintainers, so maybe there's something like on that front as well um harry what? uh What do you think this might look like for kong.

F

Yeah prioritized it. uh For the month of december, there have been some other priorities which have come up, so it's put on hold right now uh the team is growing, so I'm hoping we will have something, maybe towards the end of q1, but nothing before that.

A

Okay sounds good.

A

All right, I guess that's uh all for that. One I'll keep on moving then, um and uh we can get into the gateway naming results. uh It is, uh I guess, unsurprising, uh router router based names were the next most popular after gateway based names.

A

But if I'm looking at these results- and I can show you the the actual form responses and when uh people actually responded to the survey, it seems like the vast majority came in when we first sent it out uh and then I pinged again yesterday on sig network and got a few more responses.

A

I that uh really you know, almost every response that came in in the past couple days was for gateway uh gateway was already in the lead, but this just kind of extended that lead.

A

With that said, gateway has 11 first place votes, which is more than double any other alternative, and you can see that router was and anything related router was second most popular. um Given the this outcome, I can't think of any kind of compelling reason to change the gateway name. It seems like this is the one that the community prefers, and it certainly is the path of least resistance for us.

A

So I think this may have been what a lot of us were expecting, but this is okay.

B

Are you sure we captured the app uh community? I just wanted to make sure that it wasn't just a network that was involved.

A

uh What uh so you mean, are you? Are you meaning end users specifically yeah yeah end users, apps, okay, uh yeah I mean we can. We can leave the survey open and I can uh I can send this out to a broader audience if we want.

C

I was gonna say: has it been much discussion on why people feel a certain way or another um like I? Is there like I've been a thread I'm like? Oh, I feel strongly that it's router, because blah blah blah.

A

No, I I have not seen that on github at least I think we've we've had brief discussions in community meetings around naming, but I I wouldn't say, there's been any uh I'd say among the maintainers who attend community meeting. The uh the general uh support has been for gateway that I've heard, but we are. We are also most familiar with what we've already been working on, so we're a very biased group.

B

Yeah, I don't expect it to change significantly. I just wanted to make sure that we captured, like both the end users and the implementers.

A

Do you have a a suggestion for a good way to reach out to end users? You know, as as an example, it seems like kubernetes dev is not necessarily end users, I'm just trying to oh.

B

They're gonna tell you to go somewhere else: yeah.

B

Is there a general list I just want, like you know, we don't have to deliberate too much. We just ping it out to a couple more broadcasts and then close. It.

B

Okay, yeah, I mean I was.

A

B

Just have a mention of the community meeting, maybe.

A

Okay, yeah. That seems like a reasonable thing. I'll look up when that is I'd. Agree, I don't. I don't anticipate. This is going to change very significantly um but yeah. I I don't mind uh finding the next community meeting and and showing up there getting this on the agenda.

F

C

All right start some discussion. I know there was an issue about the naming. There just wasn't much discussion on it, so I mean I'll just throw out some opinions and see who wants to argue okay, because I didn't hope to kind of talk about well. Why do we feel these names are, you know, is gateway to overlapping with the term api gateway or you know, are there other uses cases like grpc that might make gateway?

C

Look. You know like a jrpc route or something like that that might make gateway the wrong term for those kinds of use. Cases like I think that discussion would be helpful to kind of help drive.

A

C

In one direction or another.

A

Yeah, that is, that is true, and we do have an open issue. There just hasn't been much discussion on it, so it'd be great to to see if we can drive up a little bit more discussion there as well.

A

A

Cool, um let me keep on going here. I meant to I just added this at the the last minute here I know in our last meeting, I'd said that uh we needed to clean up ownership, diversify project ownership.

A

uh I think we've accomplished that I, I think really I'd been overthinking it and looked around, talked to uh contributes and looked around and saw what other projects were doing under sigs and it seems like we really should just have all maintainers the owners and approvers at this case, and that's uh what I, what I updated a week or so ago, can't remember the exact time timeline there.

A

uh Hopefully, everyone saw that, but that means that, uh in addition to bowie and myself, uh james, harry and damian are all now approvers in the repository, uh so we have a little bit more diversity there and we cleaned up the the owner's file as a whole to more closely match the lists that are maintained elsewhere. uh So, uh hopefully that's a good start, but always open to uh future changes.

A

uh There are good kubernetes guidelines for uh who a reviewer, approver, etc should be, and what uh what each should have accomplished to reach that that goal- and I think everyone that we graduated from reviewer to owner uh very much met the requirements uh for an approver. So yeah, um that's, uh I think, that's a good change and thank you to everyone for yeah. Thank you for the link, who's up, whoever's, taking notes um if I can actually go there, um but yes, oh yes, the other change that we've added is this mirrored.

A

I think it was cluster. Api did something similar, but we added the sig leads here as well, so that sig network leads can approve everything, and actually I can remove you here.

A

Oh yet I just left you in in case all my aliases didn't work for whatever reason, uh but now that they have shown that they work I'll, probably remove this one reference to a name, um yeah cool, all right, I'll, keep on moving here, because yeah we've got plenty to go through today, one of the things that has been relatively confusing to me and we just kind of punted until after we released v1 alpha 1 uh was what do we do for new changes? uh This is really uh all of this discussion right.

A

uh What still makes it into v one alpha one. What goes into v one alpha two, and how do we structure those changes? How do we structure our repository up until now? We've just kind of been. You know everything we do goes into master when we're done. Docs updates everything, because we didn't don't. We.

B

Have to create a new directory.

A

Anyways rob for v1 alpha 2.. We do have to create a new directory regardlessly. Yes,.

B

I think we just don't branch in that case.

A

So, okay, so there's there's some extra bits of weirdness here right. uh I think we want to our docs to mirror v1 alpha 1. Until we have v1 alpha 2 ready. uh It would be strange, I think, to be updating docs to include things that weren't actually usable for our users.

A

So that means that we probably want some kind of separate branch or something some kind of separation for v, one alpha, two docs that is different from v, one alpha one dots and right now uh make them yeah. I think, like.

B

We'd have to do it explicitly in the code yeah rather than yeah. Someone has to go. Do some surgery, usually what I've seen that works? The best is, you have like docs for a particular version and then one for unstable, that's just generated at head yeah, something like that, because the the fact that you have a separate directory for alpha 2 makes it so that, if you branch you both have a separate directory and you have a branch which is probably pretty confusing.

F

Yeah but you have a separate directory only for the code right or like the go spec or the package right for the it's. It's a little more fuzzy.

A

Exactly yeah I mean we can, we can restructure.

B

Our dogs, sorry yeah, like we should just restructure the dogs and like make a generator kind of know about all the versions because yeah, as I said before, like you, have both us like two directories and you have a branch on top of it and then I feel like just the amount of stuff you have to update. When you update the docs. Let's say you had to like backboard something to the it just.

B

It gets kind of hairy uh in terms of like understanding where your changes are going and like what is actually the current published state.

A

So there there are other tools that make this a lot easier, like as an example uh read the docs ties, docs releases to you know, versions, and they and those docs are frozen with that version.

A

uh This that this is based on my very short reading of their their docs, so I I could over be oversimplifying or getting something wrong there. um This does seem like something that is here's the.

B

Other thing is like go ahead: yeah someone needs to explore if mk docs some set up. um The other thing is like: do we like mk docs, and should we switch to something else? If it's not going to make sense.

A

You know, I think this is actually tying into a pr that harry raised earlier.

A

I think this week, which was to re-enable search in our docs, our docs, have gotten fairly large and search would be very helpful, but, as we experienced before, search in mk docs is incredibly painful for all the merch conflicts it causes, and now that we have our api spec indox, it's then indexed by search, which means any change to docs, which, by definition, includes any change to even a go comment somewhere in our types file is going to conflict with any other change, so we have tons of rebasing and pain and all because we want search and mk doc's way of implementing search is not great.

A

B

Maybe maybe it's working.

A

One other thing is.

B

Just to throw another wrench into this is that now that we've moved to alpha, one is now the time to talk to contrib x, about putting it on the official dock stuff like how does it work for this kubernetes six repos? Yes, we're kind of using the github, auto docs thing, but like the rest of kubernetes, documentation actually lives somewhere else, and it has like a different format.

A

Yeah so I've I've gotten general uh support for adding references to service apis and maybe even a page about service apis on kubernetes docs kubernetes website, but I don't think we'd want to have our entire documentation living on kubernetes website.

A

um I think that I think it really is more just a a entry point to point to wherever our docs live.

A

I think you know I often think of cluster api, as uh maybe one of our best reference points here uh of docs that have been done well uh and- uh and in that case they they have their own docs, that are maintained and, I think referenced from uh kubernetes website.

A

And they use a github posting, I I'm just nervous, I don't believe so. I I looked and they they are using uh kate's dot io domain, uh which I think we could do as well. I would just need to figure out. I mean.

B

Yeah, how did they get that.

A

F

So is that also a requirement that we do have to get to like that or like? Can we be independent and hydrate here.

A

So they use a they use a kate's. I I o don't domain, but it is their docs are in their repo still.

F

Do we have to move our dogs is what I'm trying to understand, or can we like continue what we have been doing till we yeah.

A

No, I I think we should, and we should continue to and can continue to, host our docs in our repo. I just think we could improve how they're deployed so that they so that things like versioning are maybe a bit simpler um and search.

F

I see so I mean yeah. I think we need to explore either use, read the docs or use jekyll or use a hugo. I mean I think, used by upstream, so they they do have enough templates that you know enabled us to support.

F

You know versioning in the docs, you know in the spec and the way we want to so yeah. That's, probably an action item that uh that needs to be taken care of.

B

Yeah, I I agree yeah I would like to align with upstream and then at least get the vanity domain somehow and uh we can still host and we'll still have like owners and approvers on our dog stuff. It's just that. I think like mk docs, it feels like at some point we're gonna have to like hack it significantly to make it do what we want, which would not be fun. I see so boy.

F

So help me understand you're, making two points. One is get our dogs to a sub domain of k, test io and second is move away from mk docs to something different, and hopefully something different is same as what upstream uses.

B

I I'd say like if we move into something different and that's also different from upstream, then that probably doesn't make sense. uh The only thing we should move to is something that upstream can support and then some like long-term image plans like when it goes to beta and then eventually ga like. Where does it actually live permanently?

B

uh It's fine. If it's still hosted by github, it just seems like we probably want to have some other.

F

F

Got it okay, so there are two action items in the future home and the second is, you know, let's move towards whatever upstream uses and ensure that it like we whatever we want. However, we want to structure the docs it's possible within the realm of what upstream uses.

B

Yeah, like eventually, we would want to benefit from whatever docs thing. Improvements are happening there, rather than trying to maintain it. Ourselves makes.

F

Sense, yeah so yeah, so I'll try to drop, maybe I'll open an issue to, and I think there is already an issue around this of organizing our docs better, but I think the tooling needs probably another github issuer to explore what upstream uses and see how we can incorporate it in our current docs.

A

Yeah, absolutely that would be great to have as another issue. I know uh it's probably a couple months ago now I talked with bob killen about what they've used. I think it was for the uh kubernetes contributors website. I forget it one of the newer kubernetes websites out there um and they seem pretty happy with the tooling they used there. So I I think that would be a good reference point as well.

F

Yeah so um yeah, I think let let me open a github issue to track that and if I'll see, if I have some time to do that, so that that's takes care of dogs, I'm more interested in the the next question of you know what still makes into v1 alpha, because that also influences stocks a little bit.

A

Yeah, I I agree uh so um there's a a couple things here. I I think I think it's pretty clear that bug fixes need to be backported to v1 alpha. One we've already had a few go in. Most of these bug fixes are, you know, related to comments or other things that did not match up with our most recent changes. As an example.

A

um On the other hand, uh I think it's pretty clear that anytime we make a breaking change like either renaming a field or removing a field that should not be part of u1 alpha 1 and that should be reserved for v1 alpha 2. If we do it at all.

A

What is less clear to me are what I would consider these kind of middle ground things. One would be breaking go. Changes harry has a pr that does this right now and that's uh just trying to clean up our go types to. I think you, you merged a type. I I forget exactly what you did, but it it's it's a net positive, it's a net cleanup, but it could be a little bit annoying if you're a consumer of the api um using go and uh the the sec.

A

So while before I before, I go to the second one, how do we feel about this break and go changes or clean up that changes go types in any way. uh Does that seem like something we should include in v1 alpha, one.

F

My opinion is that should be a vivian alpha. Two thing.

A

Okay and then maybe the last one is new fields, and I really don't know about this one. I think it makes a lot of sense uh to keep new fields wherever possible. Well, I don't know the argument for adding new fields to v1. Alpha 1 is that you get to test out new functionality and you avoid the significant overhead of a new api version.

A

The downside of adding new fields is you introduce some level of confusion over which version of v1 alpha 1, a user.

A

Has yeah um the the fear is that we, if we don't allow new fields into an existing api version, then we'll end up with you know: v one alpha three or 4, or I don't know how many alphas and that will get painful in and of itself. um So I I'm not sure where the balance is here. Yeah.

F

I mean that's my concern too, like having, like crd versions, are heavyweight right and like in terms of impact. They have on end users, docs and you know, charging issues and whatnot. So that is like an overhead and the second overhead is, you know, having different fields for different apis right. We don't have like a version to tag on to like like in kubernetes. You can introduce new fields, uh but you know you have kubernetes version to go along.

F

This field was introduced in a kubernetes version and we don't have that, so it is definitely a little tricky and the other another aspect is maintenance. So if you keep introducing new fields, you know even alpha one, then you know you and then we have breaking changes and even alpha two, then you know there are two branches that you have to maintain and then you know, merge them make sure things are not conflicting, semantically right not in terms of like it conflicts.

F

So that's the other aspect to it as well.

B

A

Yeah that makes sense.

E

um Just to look at two is this: is your time to to get it right in the alphas right yeah, so you can turn them now and then not turn them later. So whatever you go with yeah, it's a better spot to do it now. Yeah.

A

Do you do you have a recommendation if, if you had to choose one way or another, would you be prefer adding new fields to an existing api version to avoid lots of new alpha versions or more api versions, but less changes between you know between them?.

E

um I know like on contour we allow new versions or new fields to come into the spec yeah, but we can't break backwards so because it is heavy I mean when you have to add. um We did this with envoy. Having that support, different versions of of envoy xds was a bit painful to have to have all that different logic to you know, watch them and change them and can figure all that out so yeah we do that in contour.

E

We allow add fields to be added, but I understand both sides of it for sure yeah yeah, because then you have to.

A

E

Cadence, if you are going to add a new sorry, you have to add a new version. You have to have a release cadence to figure out. Well, how often do you release that version to let people then consume them? You know.

A

Exactly yeah yeah that uh and so we've we've already left room for that in our versioning strategy. We have said that you know we have semantic versioning for service apis and we will release a new minor version. Occasionally that could include new api fields um but would not necessarily include a new api version.

A

um So it's it's a thing that we can do and and like you're saying like there's plenty of prior art for it. So maybe uh maybe we should start down here and say yes to to at least start, and if we get to a point where, where that becomes uh troublesome or we're adding too many fields, uh we can revisit it uh in the future.

A

um But but right now I I have seen you know that that's that's what we're doing at upstream kubernetes! That's what other projects are doing.

A

uh It seems reasonable to allow new fields, uh in which case I think we have a lot of flexibility in what we can add to v1 alpha one without needing a new api version. Anytime soon um does that sound, reasonable.

F

Yeah, I think yeah, okay, the bike's, a good balance. I think so.

A

Cool I'll, uh I can't remember yeah, I do. I do have a github issue uh that somewhat covers this uh I'll I'll go through and try to update this and maybe make a docs update as well to clarify exactly what we want to include in v1 alpha 1., okay,.

A

So, based on that, it sounds like we probably can continue to punt on v1 alpha 2 for some time. I because I don't imagine we're going to need breaking changes soon and if we're not planning on making breaking changes anytime soon, uh we can continue to just work and iterate on v1 alpha 1. and.

F

Go ahead, but then we do have like one pr, which is a breaking change right like do we just round or like do we create an alpha to directory and continue? I trade there too.

A

My preference would be to just hold that because and if we create a new view on alpha 2 we're going to have to make any updates to both. You know, like I'm, adding a new field. Let me add it to v1 alpha 1 and v1 alpha 2. and let me like, and then we I don't know, I I think that over complicates things um I I I am happy to be corrected on this one though, and just I hate to add complexity until we have to here.

F

Yeah I mean I totally agree there right like it's, it's much more maintenance overhead, so we should definitely should do that, but then we need a way to track the braking changes that we do introduce right and maybe, if that can be, you know a simple label on a github issue or just you know have prs that go stale, but you know we know that we do want to get to these point or something like that right. So.

A

Yeah yeah yeah, exactly, I think, once we get you know, some kind of critical mass of these are the things that we know we want uh and to to have, but they are going to be somewhat breaking changes.

A

I think that's the point where we have to branch out: do v1 alpha, 2 and and really revisit these options again, but for right now, since it, the only thing I think we have is that bit of go cleanup. I don't think that's enough on its own to require v1 alpha 2. Quite yet we agree cool cool, okay. uh The next little bits here um are what we should focus on in december. I think this is something we've already mostly covered here.

A

uh Obviously, a lot of us are going to be working on building implementations and getting feedback for those implementations.

A

Beyond that, I know that we talked about a validating webhook. I created this tracking issue yesterday, there's a few things that we've already identified, that would be included or need to be covered with a validating web hook, and actually one of those isn't would be more of a mutating web hook, because uh you know setting a default class, specifically um anyways. uh We would need some kind of web hook to enforce this kind of behavior.

A

um So this is one bit of work that we should be focused on and the other, relatively large bit of work is conformance tests. uh This is a old issue, but now that we actually have v1 alpha 1 out, it's something that we've identified is a high priority item.

A

These are both relatively large large projects and I imagine we'll want to have one person focused on well.

A

A group of people focused on each one and not you know like different people working on conformance tests that are working on the web hook as an example with that said, we have a fairly small group here today, so maybe, when we have a few more people, we can get some volunteers for either web hook or conformance tests or if anyone right now feels like they have some time to work on conformance tests for this or a web hook, implementation definitely feel free to volunteer, assign yourself to the issue.

A

Both of these issues right now are not assigned to anyone, but would be great to get in place um yeah and the last little bit here uh the. What do we want to have in v1 alpha 2.? I started to create a list.

A

I think v1 alpha 2 is far enough out, and I think these additions are far enough out that I don't want to focus on them very much right now. I'd say our focus on december should not be new fields, new features. It should be making sure what we have work. So that means conformance test that means validating web hook.

A

Those kinds of things docs improvements, building implementations that actually work with our setup. um So with that said, I just I created this list initially. I thought it would be good to talk through each of these, but, as I thought about it more, I think this is more of an aspirational thing that we can revisit say january once we have uh some good progress on a web hook.

A

Once we have good progress on conformance tests once we are pretty happy with what the base that we have already, then I think it's time to start discussing these fairly common uh feature requests here.

F

uh Like so that is like whatever you have listed under december is takes priority over the second list right.

A

That's my preference uh yeah. I I think you know it's very easy to get carried away and just keep on adding new things to the api, but if we don't have sufficient validation or conformance tests around what we already have, we, we may not be in the best position to add new things.

F

That makes sense. Yes, I agree cool.

A

There were a few issues that came in in the past a few days. One is really straightforward: we need tcp route examples, we've kind of uh ignored tcp route in our example. Well, okay, we have examples in yaml, but we don't have examples. I think we have examples in yaml, um but I do know yeah, but we do not have a guide.

F

We have a half big guide on that. So can you assign that to me I'll, send a piece.

A

F

I never got around to completing it, but uh I do have like a guide for it. You know like how we have a guide for tcp route, so.

A

That would be amazing, cool.

A

All right, I'm validating web hook conformance format. This is a new one. It looks like mark had to drop off the call.

A

This one feels like it's going to be complicated to get right.

A

But some kind of generic way to say this: uh this gateway class supports http, but not tcp or udp, uh and did support it.

A

This uh this feels a little complicated to get right, but, but there probably is something here, some some kind of generic way to describe what an implementation supports, as we add additional route types as we add, etc.

A

One of as I've thought about this I've I've wondered if we can make our output from conformance tests sufficiently helpful that it can just say hey. It doesn't support this, but it does. It is conformant with htp and it is conformant with uh etc. uh Maybe that's uh not enough.

A

um I'm just it seems like it would be difficult to get this into I'm assuming this would have to live in status. um I'm not sure how we would fit this.

F

In but yeah a little bit of more discussion and laying out examples.

A

Yeah yeah, I I think this is going to become increasingly clear as we start to see more implementations and see what what are the common things that are difficult to implement and where are the bits of confusion. And how can we communicate differences between implementations.

A

I think this is a this is a very real need. It just may be a little too early in the process to to have a good solution.

A

And this one I I have no issue with- we just probably need to have a good reason for whatever our new upper limit is uh this. I think uh this person is a k-native maintainer and uh they mentioned that they support a 10 uh traffic splits, which is great, but you know like where, where do you put that upper limit that is not going to run into someone else's upper limit, but also is reasonably straightforward for other implementations to support?

A

um So I I followed up on this uh issue for a little bit more uh information, but I I generally agree that it. It makes sense to have this number be higher than four just as long as we can make it reasonable, supported by most implementations and not an unbounded list.

A

And do we already? No, I don't think we already covered this one.

A

So I, yes, this is a good one.

A

So we is this something that can be accomplished just with a godoc update.

F

Yeah, we need to figure out the order that can be supported by multiple implementations. I think yeah a bigger goal. Otherwise it's probably a godoc update.

F

Okay, also, I mean this is probably not, but could it be considered as a breaking change? I don't know.

A

Oh that's yeah, but yeah. I I had not uh there's there's a couple other ones here that uh I can add this to the issue, uh but we uh so as an example. Validation changes so we'll never increase validation, but we could loosen validation.

A

uh I don't know, and the other one that you're talking about is uh breaking go doc. Changes.

F

F

It's it's changing semantic behavior right like something like that right like so. It's.

F

Yeah so yeah that loosening validation is something like adding new fields to me.

A

Yeah to me, I think it's fine as long as we have a new release, uh it's that the this one feels like you're saying this is this is a breaking change?

A

uh Could it be a bug fix like like.

F

That's like that's, you know that comes up in most projects like oh, no, this is a bug fix and we're changing it. It's fine. I don't know this is a breaking change.

C

F

It's a little hard to categorize. It.

F

A

Yeah, that's going to be hard to to uh write some guidance around. I I'm curiou I'll have to do some digging uh for prior art and in upstream here, because I know I know there have been some things that have updated comments part way through release, but I don't know that any of them have really affected behavior, um but there there's a very thin line between a bug, fix and a breaking change here.

F

Yeah and it gets like you at least, you know internal.com, it gets like debated quite a bit, but uh it's usually a case-by-case thing because you know yeah the the visibility of that feature matters. The adoption matters right and like there are. There are so many nuances to each and everything there so.

A

F

The case in my experience.

A

Yeah that makes sense.

A

A

um The last thing on this list is uh from john, uh and I think I think that's something we all agree with, uh but maybe this is a little bit further in scope than we've discussed before uh and that's uh as we start getting. You know further into implementation, there's probably going to be a fair amount of code that most implementations are going to have to implement. That could potentially be shared.

A

um The the example given of how you determine if a gateway is selecting a route.

A

Yeah, that's that's a good one. I don't know because, because it's so tied to informers. Well, I guess again it depends on your implementation, um but yeah. You basically would need to. I guess.

A

In an ideal world you would have a helper that accepted a gateway and and a list of routes and return the list of routes that should actually I'm not sure.

F

Yeah I mean something like conflict resolution right like was given a set of listeners. Are there confliction conflicting listener yeah, something probably we cannot have in a helper library, and you know like. I think this has come up again and again. It's just. We haven't had like more concrete discussions.

A

F

A

Yeah, I I agree with that. um This. This could probably use saudi go ahead. Okay, this could probably use a a tracking issue, at least.

F

A

F

I was going to say so: yeah.

A

Yeah, okay, I I can take the action item to uh create a tracking issue for this one and I think that's all we had to discuss today. There's obviously a ton going on. uh We've got uh lots left to do here, but I'm just excited to start seeing some implementations coming out. That will be we'll be using this. That looks like sdo traffic, contour kong. I guess obviously uh somewhere in here we should add gcp.

A

uh I don't actually know when our when, when we're actually releasing what we have. I know we have an internal alpha right now.

A

um Yeah I'll just say that, um but I don't know when that's going beyond that, um yeah, okay cool, I think that's uh all. Did anyone have anything else uh we should discuss here.

A

All right: well, uh thanks everyone. I will talk to you next week and have a great rest of your week thanks everyone, goodbye thanks, yeah, bye,.

B