Kubernetes SIG Network, 15 Oct 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: SIG Network Gateway API Meeting (EMEA Friendly Time) 20201015

Description

No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).

A

All right we're recording uh it is october 15.. This is service api's meeting and uh we've got plenty to get through. So, let's start off just with a little bit of a recap of the v1 alpha 1 milestone, we mostly went through this yesterday and I think we've covered or discussed everything that is new now, but I just want to make sure we haven't uh missed. Oh harry harry got one beat that I didn't notice.

A

um You want to describe this really quickly, harry or not that quickly.

B

Yeah I mean so here we have an example of doing a tcp listener and if you observe the default of host name is hostname match any right, like that's the default for that field inside a listener, and that does not really make any sense in the context of tcp or udp right.

C

B

So that's that's the one I caught I was addressing. One of you know points that tim has released in the pre-alpha review doc and I came across this, so it will we'll have to either. You know not have a default for that field so that that that's what I've commented below that we have two options: either we don't default the host name field inside a listener or we introduce a match type of none.

A

Yeah and match type of none is going to be an unfortunate default. I mean this whole field doesn't seem to make a lot of like it. It it's fairly protocol specific.

B

Yeah directly, so I mean my vote would be to remove the default for hostname match field yeah, but in that case the the getting started yaml becomes two more lines so.

A

We remove the default. Can we go a step further and basically say that this is the uh interpreted default? If that's, if that's a way of saying that, but basically, although we don't actually set a default for you, controllers should interpret the absence of a hostname being specified here as match.

A

A

Because I I hate to I hate to require this field, uh you know, obviously, if this field doesn't add anything for other for udp or tc, you know whatever it doesn't. It seems strange to require it.

A

So it seems like the best option is to make it optional and if the protocol is http or something where that's meaningful, if it isn't specified just match anything.

B

Did yeah, I see what you're saying I don't have an opinion right now, I'll need to think more. Okay get back yeah! That's fine!.

A

um Yeah we we haven't, we haven't followed that pattern very much of the uh interpret a default without actually setting it, but I think there is room for that. That approach I I can. I can follow up afterwards uh had a comment here just uh for the record, um but I I obviously also have not thought about this very much so there may be. There may be flaws with that approach too.

A

um Yeah thanks for catching this.

A

Cool all right, uh the next one I think we have almost entirely overlapped from office hours yesterday, where we were discussing you know, do we want to revisit any of our resource names and specifically gateway.

A

At that point, the answers that I remember were gateway is still a very popular name and it was chosen for a reason uh and it it makes sense. uh There is some hesitancy uh because it conflicts with uh istio and and others uh as far as a common resource name.

A

um We briefly mentioned uh other potential names. We could look into app gateway, router, and I also I mentioned what sig multi-cluster had done when they were unsure about naming and uh jeremy had actually led this off earlier this summer and yeah. They actually started with super cluster, which was always meant to be a placeholder, and they went all the way through a long list of voting, set up a survey etc and did a few rounds.

A

So they got some suggestions here. Put them in a spreadsheet, uh took out any that were really. You know, offensive or didn't work or whatever and then voted after that um and they actually ended up. You know I thought that they had settled on super cluster, but, as I looked back uh through, they actually settled on something entirely uh different. I think it was cluster set, um but you can see they got a lot of uh a lot of suggestions here and they they sent this far and wide um so anyways uh this.

A

This is the approach they took. um I don't know that we have to, but it seems like there's at least enough um hesitancy that maybe we can at least throw it out there see if we get any interesting names and if we don't, then we don't and we stick with gateway and we're done. uh But if we do we vote on that, and maybe we still stick with gateway. Maybe gate was still the the preferred name um but yeah I don't know I had anyone who was here yesterday or has any thoughts on this.

A

uh Do you do you have any? You know new thoughts, any any new names, any thoughts of. Maybe we should avoid this entirely.

B

One name that came to me was sort of being more elaborate. You know like app proxy or something like that, because what we are doing is essentially a proxy. It's it's a proxy layer right technically, which is also a very widely used name.

D

Does it have to be a proxy I mean, couldn't a load balancer implement the apis.

E

I was thinking that we should try to shy away from specifying the implementation, which I think is why gateway ran into trouble, because people have a very fixed idea of that. A gateway is like a certain thing. Like a box.

B

Yeah gateway does have that heavyweight sort of feeling or notion to it in the.

A

Industry, okay, well, it sounds like there's enough interest to at least start the process and see what kind of suggestions uh we get in. I you know I. I don't know that there's that much prior art here, but I think what jeremy and multi-cluster did the sig multi-cluster did seems to have worked pretty well. So I may just try and follow their process here for soliciting feedback and ideas from the sig.

A

um Does anyone have any alternative suggestions or workflows, or does this kind of approach uh seem to make sense.

D

Yeah I like the idea of doing a survey monkey or a spreadsheet and just getting it out and saying you know, place a vote so that at least you know when it's all said and done, we look back and say we did everything we could to try and get the naming down.

D

C

Yeah, I think all the all the people who have api gateways um can then just be satisfied that we at least went through the process.

A

That's a great point: yeah, okay! Well, we I'll uh I'll start that uh you know. Obviously I think we're too late into this, and we want to give this enough time this process enough time to get enough feedback and take the time to think about it. So this is not a v1 alpha 1 thing, but I think if we at least start this process of getting community feedback, we can launch v1 alpha 1, with a caveat that the name of gateway may change, so don't get too tied to it.

A

um Yeah so anyway, uh with that uh harry had mentioned uh just before this, that it might be good to update the pre-alpha review dock, which I had been keeping up with a little bit.

A

uh I think I, the last time I updated it was around the last time tim did an api review, which is probably a couple weeks ago, is my guess right now, um since we happen to have a sig network meeting this afternoon, I think I'm going to try to update that dock once more to match our current api, and then I was. I was hoping that maybe we could spread this to the broader community if you have anyone on your teams, that is great at api review and might have some good feedback here.

A

I feel like this is a good time to really circulate our api. um Obviously they can look at the repo too, but it's a little bit harder to give feedback on something that isn't a pr. So that's why the doc exists.

A

um So, if you I can, I can post something like in slack this afternoon, once I've updated the the dock to be current again, and maybe we can get uh a little bit more feedback here.

D

um Yeah I was gonna ask if you could uh provide a link in slack after you update it, because I would like to disseminate it within red hat.

A

Awesome that'd be great cool um and with that I think we're we're good for pr and issue triage and uh we've got plenty coming in now. So uh thanks, uh you know, harry has put in a lot of prs. I appreciate that um and there's some others as well, um but let's go through.

A

I think we'll have time for all of these, so in no particular order um this one. I I want to say this was resolved. I think I already.

A

Proved until I did, I approve harry: what's: uh what's the current status of this I've lost track? I.

B

Think so there were like there was a life cycle problem and then I sort of overloaded the pr with this other problem of you know what happens when the allowed gateway name space selector is violated and you know, provision gateways, problem comes up and danian is pointing to a solution here, but I think we can count on that because we are removing that.

B

This is almost ready, I think, let's go on to the reviews. It probably just needs a merge right now. As far as it's a pretty small change.

A

Yeah and since I am removing this in another pr, this diff becomes just this, which is you know basically to the suggestion to add this finalizer.

A

On a gateway, that's.

B

A

Cool okay, yeah I'll I'll, take another look at this as well, but this this looks entirely reasonable. To me, um one question I'd have is: if we need anything in the docs uh to describe this finalizer pattern.

B

You mean the concept stock.

A

Yeah, do you all right yeah, I'm not sure where it would belong. Yeah.

B

It did so, maybe I can add this to the gateway resource. It's a gateway class resource itself can add, I can add, in a document line which will get reflected on the references page.

E

B

That makes sense.

A

A

This one also I've approved it just needs someone to fly by and do an lgtm.

A

um This is something that I actually suggested, so I didn't want to be the one to you know unilaterally get this in, um but it's a simple rename and let me go down to some of the examples that you've updated, uh so it changes route selector to selector and route namespaces to namespaces, because this is all nested inside of a routes obstruct so routes, dot, route, namespaces and routes.route selector felt awfully repetitive.

A

One of the concerns that I had, I think everyone had was that in certain cases you know if you indented a selector one level too far, it would have kind of catastrophic. You know it would apply to something entirely different.

A

You know where it might have applied to routes, it would now apply to namespaces and that could get confusing. um I think that's relatively low risk, and this would not be the first time yaml indentation was annoying. I I like what harry has done here. He moved this around a little bit so that namespaces came second in all our examples.

A

So if someone is referring to our examples, they're always going to use this syntax, where you cannot have that same selector, indentation problem, which I think is a good start, and the other thing is the namespaces selector is only going to be used when you have from selector, which I don't imagine being super common anyways. So I think this to me. This seems like a reasonable update.

A

Does anyone feel compelled to add an lgtm to this one or have any any hesitation about this.

D

I know I have it up right now. Let me just uh take a quick review of it and I'll tag. It awesome thanks.

A

uh This one is mine, it is what we talked about yesterday and that to a point last week as well uh kind of sad, but uh it is the end of allowed gateway, name spaces. uh This this one was, uh you know when I look back at the the life cycle of this field. It went through so many iterations.

A

I tried so many different things and still just could not get it to work.

A

um So thank you to everyone for the patience on this, um but in the end, I think it probably is the best to pull this out, at least for v1, alpha, 1 and and revisit this as we're preparing for v1 alpha 2, and I link to the issue that discusses this a little bit more um and also that includes a link to the doc um so yeah. I think this is straightforward. I don't know, go ahead.

D

Yeah rob I just want to make sure I understand uh correctly so with that pr merged uh use of the core apis, there's no functionality to um restrict yeah namespaces. So obviously, then, by default um routes from all namespaces can be used by gateways.

A

D

Is so, this is a little different.

A

This is uh gateways.

A

Gateways can use any class in any namespace by default. That's all so. It means, if you have a gateway class in your cluster, it can be used anywhere in that cluster um and which is not. You know you could say well, we already have the same problem or issue with ingress. We already have. You know like it's, not necessarily new here, but I know we wanted to provide a better solution.

A

So I I updated the dots here to uh describe that. This could be something administrators would want to do, and I linked to where we're exploring options and that issue- and you know until then recommend using a policy agent to enforce these kinds of policies, and hopefully soon we can actually provide examples or templates that people could use with opa.

A

To make this even a little bit easier.

E

Rob do we have an issue to track, adding examples, because I think that's required and we should be linking it from here. Okay, yeah, I can do that.

E

We shouldn't just be dropping it and then not having those examples.

A

Okay, yeah, I can do.

A

A

All right, um the next one is uh probably something that needs a bit more discussion, so I am glad that we have some time now. um Let me first just go to the diff um actually harry. You want to provide a little bit of background on this.

B

Yeah so this started, I think, with a from a comment with from tim, where uh how are we going to future proof, this protocol uh type, where you know, if somebody introduces a protocol- let's say ftp into this- you know a bad example, but let's- and you know, has you know, implemented a ftp route type.

B

How and then you know we decide to introduce ftp. How will that operate right?

B

So so I talked to rob about it and I think I've borrowed this exactly how it is defined inside app protocol field in service which was introduced in 116..

B

So here that's what we are here and then I've gone a little back and forth between this change, where a protocol by itself does not make much sense in this api.

B

It's the combination of the protocol and the route type right, so I could be defining an http that we have http and http route resource in the core. Somebody can define an http and you know acme dot, io http router resource which can have a different connotation to it or a different semantic to it.

B

So that's what we are here james is making a good point where you know we are referring to the rfc 6335, uh which has no service names like http ftp, but it does not have things like http 3, I think, or even udp and tcp. So how do we define like those protocols here.

A

Yeah, I remember thank you for adding spr, because this is something that would be good to have and for v1 alpha 1.- and I remember this discussion and I recognized that app protocol is, is different than what we're trying to define here, but the the general concept felt similar in the sense that we want to.

A

We want to avoid cases where you have different ways to specify the same protocol as an example, so we wanted to provide some kind of standard set that you could pick from and when you chose that protocol, it meant that thing and you specified it with that specific name.

A

uh You know, and then we also wanted to provide a way for users to specify their own custom protocols, uh and so this was the least bad solution at the time. You know refer to this rfc, which unfortunately, is just service names and, as james points out below it may not be specific enough for some use cases.

A

Obviously, with this approach you can always do acme dot, io, slash, h2 or grpc or whatever it might be, but it would be great if, if there were some kind of standardized list that included these things as well.

A

B

The other thing is pr actually does. Is it removes the validation, the enum validation for the protocol yeah? I think that we can put in um in this research this one. I don't know if people have thoughts about it, we can improve.

B

This seems like a.

B

Having something is better than nothing.

A

Yeah I mean one thing I would say is starting the api. More restrictive is going to be preferable and less restrictive and and not to say I. I absolutely think we should get rid of this. I I think that we do want to support custom protocols, but maybe this is the best option we have right now until we can come up with a better and less restrictive uh list of options, I I'm not sure um and the the other problem with this list is it it.

A

It includes some things that likely don't make sense for gateway protocols.

A

Yeah, I don't know uh bowie or danian. Do you have any any thoughts on this.

E

Yeah, let me take a look. uh I'm sorry harry. I haven't had time to read through this.

B

D

Yeah, I think james brings up a good point in that comment. There.

D

It's like the protocols that we currently cover, aren't or don't reside in a specific layer, the osi model. So it's it's hard to refer to rfc 6335.

D

But you know harry, since this is largely borrowed from app protocol um rob or bowie. Is there some history there on the decision to.

A

Yeah this yeah.

A

This is something that I had discussed with tim back in the day, and uh the goal was that we wanted to support as many protocols as possible here, but we wanted to avoid different ways of specifying the same thing like uh you know like we wanted to avoid variations and say capitalization or you know whether a dot you know what whatever it might be, and so with that in mind, using some kind of standard list.

A

In this case, service names was seen as a reasonable starting point and then using prefixed protocols like domain prefix protocols uh for things that that were beyond that list seem like a way to support custom things, but also have a common standard list of that we could use here. uh Obviously this list is not it's probably not sufficient.

A

It is you know it. It is lacking key things here um and the solution in the current spec is just while I use a domain prefix thing for that, uh which may be less than ideal.

A

Yeah, I don't know this is this- is a a tough one to get right.

D

I wonder if one option would be is right now: we've got the protocol type values that include application level protocols, as well as transport level protocols like tcp and udp.

D

Would it make sense to actually have two different kind of split that into two and have app protocol types that are http https?

D

um You know some of these kind of custom mobile app protocols and then have transport protocol types that would be tcp udp.

D

I guess the question is: where does tls fit into.

D

A

Yeah, that's a good question.

A

Yeah I mean at splitting these up could add a bit more overhead for users or or even for validation, in the sense that uh you know, someone specifies http and udp or something something like that right and, and you then need to add something to status or validate it with a web hook, or it adds one more possible invalid combination.

A

But that would simplify what can what can live in each field.

A

Well, I I guess we may not come to a conclusion today, but I would encourage everyone to think about this and give some feedback here as you're thinking about it. Some more.

A

All right, the next one.

A

This is a huge pr. Thank you harry. uh This uh is adding all our tls documentation. I think you resolve most things now. uh What do you need from us to move this forward? I think danian.

B

Has added a review and I haven't got time to respect it yet, so I think that's the one if anybody has additional comments please put in, but otherwise this is oh. I see my guy has also done that nice. So.

C

B

For the reviews, uh yeah I'm going to get through the reviews. This is essentially taking the tls examples and adding stories like you know, explanation around it. My personal opinion. I think that's the way we should have examples right like if I just have a directory full of yaml files, it's pretty intimidating and I usually get lost. So I'm doing that to tls have changed the website. You know it's embedding the examples as well. So uh let's get this merged in.

B

Let's see how's the user experience of this, and if everybody likes the way it's presented, we can do more for other basic examples as well.

D

Yeah and harry I mean my stuff was all kind of little knits, but I just I definitely want to give you kudos on this, because I thought the way that you put this together was was top notch. So thank you very much and uh I think uh it almost becomes kind of like a reference model for a lot of the documentation that um that we should do so kudos to you, and I actually did the make serve and took a look at it locally and it just it looks awesome.

B

Thanks daniel yes, and like once, we have these more of these dogs. uh I also briefly chatted about this, and slack is reorganize the website a little bit. It's like all over the place right now, but that's probably once we have some of these current activities.

A

Yeah, I I completely agree- and I think uh just to echo what daniel said. I think this is a great pattern going forward for how we can write documentation. I think you've you've set some good patterns here. I really love uh this like this is so cool that you can. You know just embed an example, so we we have everything in sync um and I yeah I I the structure here it it's great, um so excited to see.

D

It is that's nifty how you embedded the examples, and those I mean. Those are the examples that live in the examples directory right, yep or yeah yeah. That's awesome, yeah that caught my eye too, I'm like! Oh, how did you pull this off? That doesn't mean I've never done that markdown so learned something new. Every day.

A

Yep yeah you. uh What was it you? uh You, you filed another follow-up, pr that added this: that functionality really quickly to make docs.

B

Yeah and I think we had to add a plug-in to to actually make that possible. So so there's a comment in the screen like git log, where it wasn't possible, but we added a plug-in yeah.

D

Yeah I tried to make serve initially and ran into that plug-in issue, and so I made the docs and then I was able to make sure um yeah. It worked like magic.

A

Nice, yeah and and that's uh hopefully, our examples will never go stale, but we'll see uh that that obviously is dependent on the other uh work to actually validate our examples uh on each commit, um but yeah we're getting there um cool.

A

Okay, the uh let's see, got a few more minutes here, so this one is also worth more discussion. um I I looked through this and I I thought yeah. We should just discuss this um so harry if, if I'm understanding this you're trying to add documentation that you cannot merge listeners from multiple gateways, but you can, but you can merge listeners within it, the same gateway right. Yes, yes,.

B

This is primarily, you know the ingress resource you know like we started. It has such a weak specification that some controllers do ingress merging some controllers. You know have like a dedicated gateway for each ingress resource and it gets so confusing. I think we have solved that problem with http route now because increase resources, essentially http route in the new model, but uh I think we discussed this briefly in one of the you know one of these meetings and so yeah that does.

C

Not make sense that.

B

You should not be able to merge gateways and each gateway is a different networking point. So that's what that's the problem I'm trying to solve. I'm not sure if this is the right way to solve it.

E

B

Didn't know where exactly to put in the documentation for that so, but this is where I thought. Maybe this is a good place.

A

I think so I think this is a good. I think this is the right area to put it in. I I think, like I I'm glad john pointed this out as well. I think, if you read the next paragraph here it because there's the the paragraph and above describes a compatible listener uh and then the paragraph below describes the gateway class collapse, incompatible. Listeners and you know it makes sense to say I I think this just needs a little bit of tweaking, but I'm not sure what it should say.

A

That's that's a problem like I get the confusion, but I also haven't thought yet of how to reword this, um but I think this is the be right, the right area um and it's tricky to get the wording right um in the context of everything else saying you know compatible listed listeners collapsing, etc, but you can't collapse these one thing you know, um but I I think this is good and important to add.

B

I completely agree: I'm not super happy with what I have here right now, so this is more meant as a conversation, starter, yeah.

A

Yeah, let me let me think about this. Some more I yeah I I started typing a couple things last night of oh. Maybe it could be that no, I don't like that. Maybe it could- and you know I just could not come up with a a good way to say this, uh but uh yeah I'll- think about this some more too and if anyone else has any other ways, we could approach this. I don't know, I think it's it's awfully close. I just want to make sure that it's not confusing with the follow-up down here.

A

Cool um defaulting to same namespace and route selection. I yeah I commented here and I got confused a little bit um so in the past, when we've done defaulting, we've, we've done it on, like you know the parent object here of route name spaces. You know like because my my understanding and it sounds like my understanding- may be wrong, but my understanding was that if, in this case, route namespaces was not set, the default would not get set down here.

B

Yeah I mean I agree and I think let me go back and try that again I tried that it didn't work, and so I was like sort of I don't understand how this defaulting and optional thing work. Yeah me. Neither so let me go back and see if what happens with that behavior. I remember I did try that, but it didn't work as expected. So I did like this magic, so I'll try to get that working and if somebody else also can verify that would be missed.

A

So yeah, so I guess what so this is optional, but it's not omit empty and because it's not omit empty. Maybe something gets set enough that this default applies. I don't actually know how any of this is implemented.

B

I look up to damian on this one, so yeah I mean if it's.

D

Yeah it's just kind of conflicting there right is, I mean if we gotta, if it's truly optional, then it needs to include omit empty.

D

We can make it we can make it required.

D

D

Default and then we include the omit empty so that a user can, you know, can have uh you know, submit an empty uh or submit a yaml that we're with it's empty and then the api server will will default it for us, so that would be required, omit empty and then the default.

A

So, to clarify optional in this sense means that a field can be empty and if something is not optional, there must be a value there and by putting optional on anything that has a default or being misleading, because we're requiring some kind of value to be set there. So optional doesn't mean a user whether a user has to specify something or not. It means whether a field can be blank or not.

D

Yeah and I think the optional or the required right when we're defaulting, you know I don't I don't know what crew builder you know is doing in the background for that, um and maybe it's worth testing, because I guess it just it comes down to what are we talking about? Is it optional for the user to specify, or is the field optional, as it's realized within the system?

D

Right, so I mean, unless you've got like what the meaning of op, that optional tag is off hand. You know what we have gone with is that we have been saying.

D

um I believe this is off of memory, but I think we've been doing where we say you know optional, meaning that it's optional for the user or I need to remember.

A

C

D

Pattern does anyone remember the pattern is.

C

A

That's required.

D

When we specify a default.

A

Yeah we used to we used to we used to have optional tags on default fields. We have since removed them and made them uh and made them all with omit empty, removing the optional tag and adding a default where possible.

D

Because when we remove the optional, the default is required, we're so we're defaulting and it makes sense to remove the omit empty because or oh. I need to go back and look at this even.

E

When I don't look at.

D

It for a while, I forget what you know: what that combination.

D

A

And I definitely agree with what bowie put in chat, that uh we should absolutely record all our confusion here and let you know maintainers of coup builder know that you know these things feel confusing to us at least um but yeah yeah, okay! Well, thank you for this pr and uh I'm super curious to figure out exactly what combination we want here.

E

A

uh And I know we're past time now, uh there's a few more pr's. If anyone has time to uh to take a look um but otherwise have a great uh great rest of your week and we'll talk to you next week, all right.

D