Kubernetes API Expression Working Group, 9 Dec 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Gateway API Bi-Weekly Meeting (APAC Friendly Time) for 20201209

Description

Service APIs Bi-Weekly Meeting (APAC Friendly Time) for 20201209

A

All right, it's december 9. This is service api's meeting and uh we've got plenty to discuss. It looks like um I wanted to call attention, even if you're not interested in talking about service apis, that kubecon cfp is coming up way faster than you would think it would. uh The event is until may, uh but we need to get any uh cfps in uh any talk proposals in uh soon.

A

I think it's sunday is the deadline, uh so harry and I have been working on a talk proposal for uh service apis, uh and I this I just would love some additional feedback. It could help us uh help us have a better idea of how we should try to introduce service apis at kubecon, uh but this does not need to be the only talk that exists. um I've also had some interest in something like a panel proposal.

A

If anyone is interested, it could be a panel of people that are either implementing using or even among maintainers of these apis. I don't think that's expressly required, but if there's interest in being involved in kubecon and talking about service apis, I think there's definitely additional space for that.

A

um So uh yeah, just uh you know if anyone's interested feel free to say so now or in slack or whenever that comes out and then in addition, for this talk proposal, if you we've got a lot of different options here so- and this is very rough but we'd appreciate feedback just so that we know that we're we're covering the things that uh that we should be and uh and have the right perspective on things.

A

Cool all right, the next thing uh focus for december we've as much as it. It would be good to get some new things in some new features and some new bits of code, whatever uh we're trying to trying to restrain from that and do the bits of maintenance and maybe less exciting work just so that we have a good foundation here for the api we do have.

A

So that means we really should have a validating web hook, and it looks like chris you volunteered to take this on. Thank you. I really appreciate that. um Chris, do you have any questions about what we're thinking here or any thoughts on on what you might uh do or work on.

B

uh The one question I had is: does anybody know that the examples I mean I'm sure they're out there? I just don't know with it being a outside of tree web hook?

B

um Does anyone know how if anyone else has done that with the sort of template that we've used on github, because I'm sure there's plenty of out of tree admission controllers? I just don't know if there's any special sauce for the uh specific, like project creator thing that we're using. If that makes sense, can you guys not hear me.

C

No, we can. um I mean there are plenty of examples. I have built one validation web myself so and that's open source and kong itself. So I can point you to that.

C

The machinery is, all machinery all exists, but I don't know if in service apis it being like an out of tree thing, does it need a special web hook or just a regular one like how you know like multiple.

D

C

Implemented like hd, also implemented, I think so we can use the same machinery to implement it.

B

Yeah I I worked on the istio uh web hook like sure it must have been a couple years ago and that by now so, but I'm sure some stuff has changed. This is basically just creating like a plug-in per se right.

B

D

B

It's a like a entry, it's everything stored under the plug-in thing, and then you just opt into it by saying at the api level what you want to have, but if it's external, is there a different process behind that? I do remember.

E

Can't you use the q builder stuff.

B

That's what I was wondering like just q, q building.

E

It generates something it.

B

Generates something.

E

I think yeah, I think it already has a code there.

A

We've gotten rid of a lot of the coup builder boilerplate, uh but there the structure is still similar enough. That I think, if you did another uh coup builder generate, I forget the specific command uh you can instruct it to create some boilerplate webhook code that boilerplate web hook code is not amazing at least the last time I tried it, but it is a starting point.

A

B

I might just try that as a starting point and if not I'll just go with, you know what what I know from the normal stuff.

C

And I'll try to send you a link chris, uh I wrote it using. I think client go and some basic machinery without queue builder, and essentially you do like you, implement an http handler funk in go and that's about it right. So it's it's! uh It's not too complicated to do like a simple one. So let me send you that too cool.

B

uh Yeah, I'm gonna start working on that today. Then I'm just working on getting the code base built since it's been a while, since I touched it.

A

Cool yeah and let us know if there's any, uh not obvious parts of that, we could definitely use some better documentation around that process and also sorry, if I missed anything in the first bit of when you were talking, I had some fun audio difficulties where zoom likes to set my audio output to be my microphone, which obviously doesn't work. So I can't hear anyone.

B

uh Okay, yes, I wondered if it was me because I saw you shaking your head, so I thought sorry.

A

um Cool okay, uh well yeah, thank you for taking that on. uh Don't hesitate to reach out if any of us can help with anything um yeah and uh conformance tests. I've volunteered to start working on this, but this is a big uh big project. I think that uh could be oh steve. You have a an example web hook that looks awesome.

F

Sorry I didn't interrupt you yeah. I wrote.

A

That that's cool.

F

I wrote that a while ago, so it it was when contour used ingress route, uh but it looks at a crd, so the the concept should still apply. I think, but again I think it's been two years looking at the history now, so it may not even be things that may have progressed since then, but yeah that.

A

Sounds like around the same timeline that I wrote my last webhook and it yeah. I don't know mine was not pretty so. This is probably a good, a good starting point um cool um yeah, so I I've volunteered to start work on conformance tests, but I am very open to any help. I really want to start with as small a foundation as possible so that we can get more people involved quickly, uh but the the work that I know alejandro and others have done on uh ingress controller conformance- is really awesome.

A

I was digging back in here this morning. I think just to make sure it had everything I actually wanted and there's a lot of great content in here.

A

uh So as an example in state uh there's something that already exists for capturing a round trip request which then goes out to http is the one that has the theme bulk of that logic.

A

But I think I think what they've done here. It obviously overlaps a lot with what we're trying to work on so I'm going to reach out and see if there's any way that we can reasonably share code or if we should really just copy it for now and worry about sharing code a little bit later on.

A

But I do I do like the approach here, and this would be my preference to follow this same approach. uh If you haven't seen these tests, uh it's uh I think it's like a cucumber based approach or similar to that, and- uh and so you see, requests like this uh test written out like this, which takes a bit to get used to, but I think it's a really clever way to do it.

A

So that's what I'm thinking I I think chris you've been involved in this process as well, and maybe others.

B

uh Yeah, I reviewed some of the v1 stuff: okay, nothing for v2. Yet, though, okay cool.

C

Yeah I I had a look at this a while ago and like I found it difficult to wrap my head around like the whole feature thing, and then they opened.

C

It was a yeah, it was not a you like, not the usual conformance way of doing things.

A

Yes, yeah, I I the first few times I looked at this. I didn't really like it. I I'm I'm beginning to come around to this style, but that does not mean we have to use this approach. um Well, is anyone on this call? Where was anyone on this call involved in the design of these tests? I think maybe bowie you did some work.

G

E

A

E

I think yeah there are some automated workflows, uh it's worth just running through them to figure out what needs to be fixed.

E

What I do like is that you have a textual, almost textual representation of what the behavior should be, because, typically I find that the current at least the way the current kubernetes performance tests have kind of come about is just to take existing e2e tests and just kind of say, hey, that's also conformance, whereas this one kind of goes more towards writing out what the behavior should be and then having the tests reflect that it is kind of awkward in that it results relies on some code generation.

E

So that's not super great.

E

But at least the current state is that the code generation is fairly streamlined and there are static checks to if you make a goof that it uh it tells you about it. I, the the uh overall cucumber framework, actually didn't have that, so that was extremely confusing.

E

Basically, it would generate an initial skeleton and then, after that, you're it's you're on your own and then the only way to know that kind of your test didn't match up would be to run the test, and then it would kind of detect that, oh, your, your like text, didn't quite line up, and that was very confusing, so I would run through the workflow just to see if it makes more sense, is that in a make file yeah, so you run make and there's some hack verify that basically validates the the feature that you, the text that you wrote, which is some yaml thingy, actually matches the generated code.

E

Okay and the general. uh This definitely needs a style guide for writing, because you can easily create the yaml representation and make maintaining the test very annoying.

E

But, generally speaking, I think the the style guide is to like use the least um bits that result in like lots of generated code as much as possible and then basically use the yaml just as a way to describe uh the behavior and then put all the logic of like matching stuff into one function that you end up implementing on the unit test site.

E

So in some sense it's like there should be a minimum set of generated code that you're trying to make work out, and mostly it's like it's like a nice way to match up the descriptive stuff with the actual test. It also generates very beautiful reports. So that's like a bonus. Okay, that's nice!.

A

Cool and uh where, where did where does the code gen go? Would that be?

A

I guess that doesn't matter.

E

um You can see the code gen. Is there yeah? Okay,.

E

Got it the the repo could use a little bit of a refactoring um to kind of pull some of the cogent code out yeah? uh What I would do is, I would just try running it and adding a thing and then seeing seeing if you understand how it works, yeah and then, of course, this thing should obviously be improved uh yeah if it's not understandable,.

A

Interesting yeah I'll have to read some more into this, um but it does look like some great work has already been done and a great foundation here. That seems like it's worth. Building on there's going to be a lot of overlap between ingress controller conformance and service, api's conformance, I would think at least in terms of behavior.

A

You know like you, you look at a test and it's basically uh something that will apply some form of vml and then expect a certain behavior uh which usually result. You know, request, foo and expect bar, so that general pattern seems to be very similar to what we're working on or what we want to accomplish here.

A

um Yeah interesting, okay! Well, if does anyone else have thoughts on conformance uh anyone really like or hate this kind of pattern that has been shown with ingress controller, conformance.

E

By the way, the recommendation uh talking to multiple people is that don't use ginkgo, so it's either this or something else everyone I talked to about ginkgo and conformance was like. Oh, I don't. We kind of regret using it. Yeah.

F

Yeah, I'm happy to help two robins. If you want someone else, I don't have.

H

Strong opinions.

F

Either way, but I was I'm looking for a way to jump into this- oh.

A

Hey this is something so.

F

If this is a good spot, then.

A

That's cool for me, this is an awesome spot. This will I'll try and get just like a baseline bit to to get started, and then hopefully we can have a lot of people uh contributing from there. Adding additional tests, because you know conformance, is one of those things that could expand and expand and expand, um but uh yeah that would be awesome. I would love any any help and contributions along the way thanks cool. um The other thing that we want to think about here is docs improvements.

A

uh I know that we've already gotten some or plenty in since v1 alpha one and uh harry. I think your tcp route, one either. No, I guess it's not quite merged, but it's about to be I've lost track, but uh we're we're still getting new docs improvements coming in um one of the ones that uh that came in well that that came up recently is we have discussed in the past that it would be very helpful to have some examples of ingress configuration and show how they could be mapped to service api's configuration right now.

A

We don't have anything like that. So if anyone is looking for, you know some additional docs work, that could be a good area to improve, but also, if you're, if you're, reading through docs and just find something that isn't clear or isn't documented at all uh file an issue and or pr to uh to fix. It would be great.

E

If you're really enterprising, you could write a translator and uh yes and if you're really really enterprising, you could run the translator using and script them and put it on the webpage.

C

I mean it's not a bad idea like we did it for a couple of custom resources internally and like ingress is so simple and like service aps, you know, is a super set so generating http route from ingress resources, at least for the in tree implementation. Right, not taking care of any custom annotations is, is doable.

A

Yeah, that is true.

A

Yeah, that would be fun: okay, yeah, um the the next thing I wanted to say. Oh actually, while I'm talking about docs improvements, the other thing we have an open issue uh to explore other doc, gender alternatives to make docs, because right now the tooling we have has a number of issues most notably.

A

If we try to enable search, it is going to result and get conflicts all the time. Speaking from prior experience and then second with the the system, we have right now, there's not a great way to have version docs. So whenever we start working on v1 alpha 2, it's going to be hard to separate docs for v1 alpha 2 versus v1, alpha 1..

A

So I know there are other docs tools out there. Harry has an issue where we're tracking uh anything on that. But I don't I don't know of anyone uh harry. Have you have you done any further follow-up or research of tools or anyone else.

C

I I spent a little bit of time and looked at what upstream does they use hugo with a boxy theme and that seems to be working? Okay, they have. There is a little bit of you know like helper code that we can borrow like some make files and docker files to do that and that, I think, will work for us.

C

Okay. So I think that seems like a good path to at least experiment and see. If it you know, if we run into any issues uh yeah, I haven't had time to actually try it out, but if somebody is, you know wants to try it out it. It's not too difficult to get like. You know like a simple demo working, I think, getting like you know all bits and pieces together, like okay, versioning works as expected and auto, generating like the the specification and then putting that in markdown.

C

I think a lot of what we have can be reused, but uh yeah. We need to spend some time actually getting that.

A

Cool that'd be awesome. uh Yeah is anyone interested in taking that one.

A

On cool, well, uh yeah just uh looks like harry added, or someone added the uh issue there uh feel free to assign yourself if you're interested um cool all right. So the next thing I had on here was to discuss, release cadence and for release cadence. We obviously released v1 alpha 1 a few weeks ago now and we have had 41 commits, which is a surprising amount uh since v1 alpha 1.

A

and I've been trying to figure out at what point does it make sense to release an update? We already have changes in here that would preclude a patch fix, so we'd have to do a minor version bump uh and so we're talking about an 0.2.0 release. At this point, I I've personally been thinking with holidays upcoming, and everything that may be aiming for sometime in january, is appropriate for the next release.

A

But I wanted to check in with others here see if that that timeline is reasonable or if we should really try and get something out before then or or after that.

C

So so we need to decide if we want to do like a time-based release, or do we do like a feature based release when we have. We think we have enough significant changes and then we do a release right. So I I think we have made a lot of additions to docs and fixed a lot of those things we probably have added in maybe one or two api changes as far as like, I think, uh since, since we even alpha one so um yeah I mean, and how do people feel like?

C

Should we do like regular cadence? You know every two months or something like that or every month, maybe a bit aggressive. But what should we do like bundle in a lot of things together and then put it on.

A

Yeah, that's a really good question. I I had been leaning towards setting a date and saying this is when we will release 0.2.0, but I don't know if I'm ready to commit to a cadence beyond that and that's because at some point we we are going to want to switch gears from updating v1 alpha 1 to you, know preparing for v1, alpha, 2 or v1 beta1, depending on how the api is going and what kind of feedback we get.

A

So if we said oh we're going to release updates every two months, but then you know say two months after 0.2.0 were actually more focused on a v1 alpha, 2 or something else a more significant release.

A

It would be hard to to pull back from that kind of cadence, um so my thought is: maybe we start with a relatively firm date for our next release, but not go any further than that. Yet um I don't know, um maybe I'm open to to locking things down further as well.

C

So another thought that I had was uh so we are working on. You know less flashy things. You know like validation conformance, which is you know our priority right now and documentation so and adding features. uh No, we won't be able to devote much time to that, so those two so having a 4.2.0 sooner uh does not get us much out right because I agree we won't be able to get much features out if you're, focusing on the other things. So maybe we just yeah, I don't.

C

I don't know how to set a date right now, yeah the plan we have.

A

Yeah, that's that's fair, so the things that I'm most interested in getting out right now are actually what I would classify as bug fixes they're, not really substantial, uh but they do include things to uh fix it. Like fixing this default value and fixing some code comments, and I think there was maybe another default or validation fix, I can't remember which we also increased a value, a validation value for k, native and- and I imagine changes like that. That would be helpful for implementations to be able to reference.

A

uh So I I can imag so even if our 0.2.0 isn't necessarily a huge release, if it allows implementations of this api to move forward and still pin to a specific version of the api, I think that could be helpful, um but I I agree uh if, if we re release a new well, uh you know an 0.2.0 inc incremental update to the api uh in january. We're not going to have any significant changes. I I can't imagine.

A

Well, maybe I don't know, does anyone else have thoughts on versioning here.

A

Harry, I think I cut you off. I think you're about to say something.

C

No, I mean, I think in that case. Maybe you know if we don't want to be like a big feature pack release. We can set a date. I don't know like 10th january, just randomly picking up a date and just stick to it and that's that's better right like and then what goes in goes in doesn't go in that's fine, yeah yeah, so yeah I mean we can you can set a date and just do it if that helps another thing yeah. What?

C

If, if there are these minor changes like if we recommend users using like a git commit, you know like using go modules, you can came to a specific commit as well and that that avoids a release.

C

I don't know if that's a good idea or not, but that's that's an alternative option where you know, if somebody is looking for a bug fix that is already in the master branch, we can advise them to pin their dependency the go dependency to that specific version, because if it's a documentation change, they don't need to do anything so manifest because crd definition change, then they do need to pin that.

A

Yeah, it's the the manifest changes that I'm concerned about and and right now it doesn't matter that much like people can just pull from master and be all right uh where this is going to become a little bit more problematic and is going to be when we have the potential for multiple implementations use using and relying on the same crds uh the same version of the same crds.

A

It would be helpful to have some kind of practice of, and maybe this doesn't matter for so early on in v1, alpha 1.. But as we proceed, I think it would make sense to have additional releases or some kind of precedent that will have minor releases through the life cycle of beta and maybe even ga that add features. And so you can say our implementation supports the v1 apis, specifically v1 1.1 of surface apis.

A

I'm not sure what makes sense here versioning is is difficult for a project like this, but I I would hate to to see the long term sustained use of pinning to commits or pinning to master branch, um but for now it. This is probably all a moot point. It probably doesn't matter that much as we're all still early in the implementation side, side of things.

C

Yep, I agree cool.

A

Okay, well, for now I will, I think I will go ahead and create a tentative milestone for 0.2.0 just so we have uh some some semblance of what to work towards and and when something might get out. But I don't I think january sometime is fine.

A

I I don't even know I I'm not sure quite yet what the date is, uh but we can say we will release another version of the api in january and and have something that you can pin to if that's valuable, um but I I think the main thing is that we do not plan on a new versioned release in uh december um yeah.

A

Okay, uh the next bit was issue triage harry. Thank you for adding a few issues. A couple issues for us to talk through uh john, are you on john is not on this call. um This was an interesting issue that got a decent bit of discussion around it. I.

A

I haven't read it fully, but I I seem to remember the key idea being to further subset what a gateway applied to I am. Am I remembering this right. I think uh here you might have responded here.

C

Yes, I mean the gist of the issue, is that you have a gateway resource and let's say you have five proxies. You know in cluster proxies that are running uh now, which proxy actually or which deployment or kubernetes service, whatever you want to you know, specify actually is implementing that specific gateway. So how do you do that? So john here is proposing that uh you know we add a selector on the gateway resource which specifies you know which deployment or which service, so you know implements that specific gateway gateway.

C

So that's the issue and, like my like, that's an inter that's a good problem. I was thinking about the same problem with kong as well, and uh this is apparently very common in like uh eastern service measures, where you can have a number of gateway in cluster proxies and they can implement different gateway resources up until now.

C

I think we discussed this once before in one of the office hours where you're like we, how the gateway is implemented is, is not the concern of the api right like any of the service can implement that gateway or you know, and the gateway status reflects. You know which service is it right, like you could have a named address or an ip address. You know whatever the network endpoint is right, beta load, balancer or a cluster ip or whatever, be it, and that that was it.

C

So that's why this issue is interesting, where you know how much do we want to connect these two pieces together.

A

Yeah this is this is really interesting it I, I think some of the comments had had mentioned, that this feels like something that had originally been intended for gateway class to solve. uh You know, I, I remember, with other ingress controllers, ingress class kind of accomplished a similar concept to this um this. This feels like a little bit more granular than that even and I can imagine that you could have some creative uses of this like uh select.

A

I really want this to be served by some some instance, some something that is in this specific region or zone. As you know, kind of a more abstract idea of this.

C

Yeah and I think, with the gateway class, the point is like the creation of gateway class is considered a privileged operation. Yes, so that sort of creates more modern, creating leaders. So the reason I wanted to bring this up was. I think this is like important early on issue, so.

B

C

Have thought so give it some thought and add in comments.

C

A

The one thing- and I know I know he's not sold on this specific example, but we we have so many selectors in this api and adding one more we'll have to be very if we, if we were to do this, we'd have to be very clear about the name uh so that people didn't confuse this with how I select the routes or resources that this should target. As an example.

A

Yeah, every new field we add had has some cost in terms of complexity.

A

But yeah it's an interesting use case. I don't. I don't, have strong feelings yet on this but yeah. I appreciate you bringing this up.

A

Anyone else have thoughts.

I

Rob do we imagine that things like gateway parameters and gateway class parameters are kind of a staging area for capabilities that we're not quite sure whether they should be first class or not yet, um because, let me really just really parameters is effectively.

I

You know a dumping ground for anything that doesn't go first class into either the qa class or the gateway, and so the exact same thing could be in a custom parameters. Crd, um I don't know it definitely sets some bad practice around, allowing people to just dump a lot of stuff there, but it does could also potentially serve as a staging ground for capabilities not sure about yet.

E

Yeah, that's really good, I would say annotations would be a staging ground really.

A

And so I would say it depends on how you want access control to work. If you want a gateway admin to be able to control this, then yeah an annotation is appropriate, uh but if you want to restrict this to gateway class admins, then yeah gateway class parameters seems to make a lot of sense.

E

Yeah, I think, like staging or not is independent. The choice between class param and gateway is, as rob said, the permissions involved.

C

We don't have a gateway parameters, otherwise that would also be a good place to put that in.

C

Actually that might be an idea of what's exploring.

A

Wait, we don't have a what parameter.

C

A gateway parameter. We have.

A

C

Have a gateway class stick dot parameters, but we don't have yeah.

E

Got it I would say for custom stuff, it would just just use annotations, even though people don't like them.

E

Like a parameters reference that then, is basically a crd, maybe it just seems like you're kind of constructing annotations.

A

What so, why would we have a parameters, reference on gateway class and not gateway like why? Wouldn't we just use an annotation on gateway class? In that case,.

E

I think it's uh well. We can look at the we did discuss this. I think.

E

But the issue with gateway, I think, was that gay gateway class it's hard to see that it's portable but gateway, is intended to be more portable. Sure.

E

Like class, the conception was that, if you're talking about a particular class of gateways, that is inherently talking about some implementation, whereas the gateway- that's probably where the trade-off came from.

D

A

Interesting um yeah, this needs a bit more thought. I think um I I appreciate the the comments, though, that this may not need to be a top level field to start that we can test out this kind of functionality, either as an annotation or a parameter, and uh and if it's a common enough desire, we can first class it at that point.

G

A

Okay, uh let's move on to 451, yes, external traffic policy, um one of the things that I've been thinking about more recently- and this issue is a good example of that is service. Apis is you know partially uh something that can uh build on the ingress api and allow for more complex configuration, but it's also something that can build on and maybe eventually replace the service type load, balancer and things related to that, and so, in this case, external traffic policy seems entirely entirely relevant here.

A

But I I guess we need to think a little bit about.

A

About if, if it, how it exists right now is how we would want it to exist in the future or if there are any changes or differences. We would want at this point.

C

Yeah, I just wanted to get like an initial feel of like how we feel about this issue, because uh this wasn't discussed before, and this is a little bit different than what we have been working on in the api right. It's it's a it's! It's an expansion. You know a valid expansion of the api, but it's an area where we haven't given much thought to. So probably you know another topic where union can.

C

Just you know, have this thread running in the back of their mind and then we can come back to it probably later at some point.

A

Does this feel like it's the kind of thing that should be in scope for this.

C

C

I'm not sure yet yeah. If we do get into the area of okay, we want to take some things inside the service resource and move them inside this new api.

D

C

I think we should start with what will be our objectives and like what things we do want to touch in the service resource and what things you don't want to, because otherwise it's very easy to make a gateway.

C

The kitchen sink of all these problems.

E

Yeah yeah yeah, wouldn't this this almost seems like it would go on the route route, because external or like this would be uh yeah not clear. Like there's external traffic policy, I guess there's internal traffic policy yeah. Well, I'm.

G

E

A particular way to send traffic around.

C

E

Opposed to something that is more at the gateway level.

C

Oh yeah, but this is more like so the service resource has external traffic policy right where you send traffic directly to the service or you can send it to a cube proxy and then there is a client ip that gets preserved or not preserved.

C

So I think this is primarily about that and moving that over into this resource gateway, source.

A

Yeah, and that second part, is what so, there's two components: two main components as I understand the implementation here right, there's any related load, balancing load, balancer configuration based on how it does health checks, basically how it routes traffic uh and so that it only routes traffic to nodes that have ready endpoints for a service. But then the second part of that is a change to coop proxy and that change to coup proxy is where this gets complicated.

A

uh You know is coup proxy, something that should be aware of these apis, because so far we nothing in core has to rely on service apis, and if we were to support functionality like this we'd have to figure out how that would work in proxy.

C

Implementations yeah, so I think we have been having these discussions like a one-off discussion, so service apis is more than ingress right, but we need to probably spend some time or you know have we have to like. If we do want to go in that direction, we'll have to carve out the set of problems we do want to attack and we don't want to right just because of other. Otherwise the scope becomes a bit too large. I think, and we run into the same problem as service.

G

C

And that's something you don't really want so.

G

A

Yeah agree with that cool um were there, it looks like those are the only issues called out, but I think there's a couple more issues uh that have come up recently. uh One thanks for uh following this hairy. We should remove any old references to namespace. In our examples, some of our examples have a hard-coded default namespace, which is less than ideal, so removing that makes complete sense if anyone is looking for a really easy initial contribution, uh this would be it um so there's a good first issue somewhere here right.

A

Yeah uh we have already discussed this one from uh john and the other one was the alternative doc generation uh which we've discussed indirectly uh today. So there are a few open pr's, so I want to go. Go there, uh oh looks looks like some people have approved prs. Thank you um I wanted to. I think this one has been stuck for a bit and I wanted to go ahead and make sure that we unstick it. I had I'd placed a hold on this because I wasn't sure what we wanted to do with api editions.

A

At this stage we had not actually documented that adding fields to the api was actually acceptable. My pr that clarifies that has merged in now, and it has said that we will- or we may add, additional fields to an existing api version. This follows kubernetes versioning, whatever it it. It is a pretty standard idea, but we've now explicitly said it. So I think I can remove the hold on this pr. At least I I think this is a very reasonable request.

A

We have a header filter that allows adding and removing headers, but we do not have a set.

A

So I did a little bit of digging and uh at first I thought it was going to be complicated for some implementations, but it does seem like this is fairly universally supported.

A

um This feels like a very straightforward suggestion to me: um does anyone have any uh any hesitation around letting this in.

C

I think there was another issue that came up of ordering where the way you do set add remove. It makes a difference of you know. The output will be different, so yeah. We should track that. I think now so we can get in and then that remains like a bug or another enhancement, or that issue could block this.

A

Can we uh that's a really good question it remind me for filters: can you define multiple filters of the same type in a row.

C

That, I think, is undefined behavior. I need to go back and check.

A

Because we could potentially make this more of a you know a union type thing where you can well, I don't know if we need to require this, but you could essentially say that each request, header filter, should only contain a set, add or remove, and if you want another one, you add another thing in the list um or.

C

So yeah, so the doc comment we have sorry for interrupting is a core filter. Multiple times has unspecified or custom conformance.

A

A

Okay, thank you. Oh yeah, it was me cool. um Okay. I guess the the other option here is that we have a consistent way where we always we always add before set before. Well, we always what would what would be appropriate appropriate default would always remove before.

A

Add before set something like that, you would have a consistent behavior where, if multiple were specified, it always happened in this order, and if you wanted a custom order, you could split that out into multiple request: header filter statements.

A

Yeah this this does need some more work, but it is not unique to this pr. So I'd agree with the idea that this this discussion does not need to block getting set in.

A

Yet so harry did you say: there's already a follow-up issue uh for the the ordering discussion.

C

There is I'm trying to look for it and I could not okay, 480, okay, okay,.

A

A

A

Cool well does anyone have any uh any hesitation about this addition to the api.

D

If we did specify that you did a remove, you do did removes before ads, then what would this actually do that you couldn't do with removing that.

A

uh Nothing, that's a good point. uh It's just a very common thing that that seems to exist in a lot of uh proxy implementations already and- and so, although it would make no uh fundamental difference, it would require slightly less lines of code and maybe slightly easier to reason about, but you're right that we have the tools in place to do this without a set field.

E

Does it make sense that add also has set semantics because uh oh yeah, actually that's not true headers, you can repeat and they get concatenated together in a special way: yeah yuck. Yes,.

E

And we just double checked like this is not something uh I think every every provider kind of supports this.

A

Yeah yeah, so some have a slightly different, uh so some use add with an option to like a boolean, replace type field uh and others have separate. You know ad set or ad replace. I forget the the terminology. That's common, but but set is a relatively common uh construct.

C

I think some proxies uses append instead of add yeah yeah.

A

Okay, well, if there's, uh if you have any more thoughts, uh definitely feel free to add them here, I'm going to go ahead and remove a hold on this, and if I don't hear anything, if there's no more comments on here in the next 24 hours, I'll just go ahead and prove it.

A

um Anyone else is welcome to do that as well cool. I think that's about it. I know we're close to time here. um Actually damian I saw you were doing a bit more work. I think you were doing a bit more work on this pr. uh Do you have any updates here.

H

um I have not touched that in a while I thought.

A

We were holding.

H

A

Okay, my kaya added some comments. That's what it was. Okay,.

A

H

I put this on hold and you know trying to figure out well is this something that would be in somewhere else in the apis.

A

Yeah yeah, um I'm I'm.

H

Still not sure where this.

A

Where this belongs, I know initially, I thought oh back-end policy would be the place right, um but then kind of backed away from that.

A

um I I'm open to revisiting this uh it you know, maybe in our next meeting, if if we want to there's, there's no more reason to to delay on something like this, but obviously I guess our our main priorities are. You know the web hook conformance and docs, but I know this. This concept has been kicking around for quite a while. So if we want to uh revisit it, I'm I'm welcome to you know I'm open to that.

D

The reason I reviewed it was it popped in my notifications when harry tagged, it v1 alpha 2.. So what.

H

Does that label.

D

Actually mean: does that mean we're considering it for everyone alpha 2 or we're committed, we're, probably going to do it or what does that really mean.

C

I added that before we made that decision, I think where we were going to do additive changes and alpha 1.

D

C

We I think that milestone can be removed. Now I think yeah we can uh yeah, that's the reason I added it and I think I'm so. I have gone ahead and labeled one pr which has a breaking change and added that to the even alpha 2 milestone to keep track of it. Where you know, breaking changes only can go into even alpha 2 yeah, but yeah I mean that was probably not correct. On mobile.

A

Yeah, it made sense at the time where you know like we thought that new significant changes would be resolved for v1, alpha 2, uh but based on our latest versioning discussions, it sounds like we will make additive changes in v1, alpha 1, and this would be an additive change, so yeah. I think we can remove the milestone and reserve it for like you're, saying breaking changes or potentially breaking changes.

H

Yeah right, you notice my comment. There, too, is. I think, if I go back trying to remember how this all started, but I think k native was another big use case uh for adding the connection, timeouts and so forth, and you see my comment that actually deprecated that so interesting.

A

A

Okay, huh do you, I guess they they've got issues I'll have to I'll have to read up on that um interesting.

H

Yeah I haven't, uh I haven't dug into it. It just came across my radar, so I wanted to make sure that.

D

H

That, in the pr.

A

Appreciate it cool. Well, I think we're at time. I thank you, everyone for uh all the great discussion today and I guess we'll talk to you all next week.

A

Don't forget if you want to get anything in for kubecon. I definitely go ahead. It looks like there's some interest in a panel proposal. Maybe we can coordinate a bit on slack. um I think uh I think there there's someone from google that might be interested.

A

I I don't know, but yeah I'd be interested in digging a little bit deeper to see if we have a group that might be interested there um cool, but with that have a great rest of your day and week and we'll talk to you later thanks.

A