API for Default Gateways

[kflynn]

Add API description to GEP-3793. I'm sure this'll be totally noncontroversial. 😇

/kind gep

NONE

[mlavacca]

/cc

[shaneutt]

Looking good. I have a few comments.

The main thing that I need to think about is semantically how we seem to be pushing for "Default Gateway" meaning "one Gateway, which is the default", whereas I wonder if we should be looking at it more like "by default, this Gateway will accept unbound routes given a scope".

Do we really want DefaultGateway or do we actually want AcceptRoutesWithNoParentRefsWithinScope<Scope>: true?

I made some comments about this, and I'm interested in hearing your perspective 🤔

[danwinship]

github won't let me comment on the pre-existing parts of the GEP, but:

1. the links to the personas are broken ("https://https//...")
2. Services of type: LoadBalancer seem like pretty important "Prior Art" for "easy way to get cluster ingress without the application developer needing to worry about how it works"

[kflynn]

I believe that the correct text addresses all the feedback, so I've marked this Implementable.

I suspect that folks may feel strongly about my choices for isDefault in Gateway and defaultOK in Route. BikeshWordsmithing on these names is definitely a thing we can do before we land this PR. 😂

[youngnick]

I kind of liked the previous approach, but this one is more explicit, easier to define behavior for, and easier to write validation policies to disallow if Ian wants to.

/approve
/hold for further review.

[howardjohn]

In the spirit of recent discussions about unclear feedback I want to be explicit: I don't think we should do this.

I don't feel the benefits outweigh the complexity and risk. I don't think its an issue with specific choices the implementation has made, I just think the idea is not one we should do.

It seems I am in the minority, and this is not harmful to my implementation or anything (we can easily implement it just like anyone else can), so not blocking. Just wanted to share my 2c.

[kflynn]

I kind of liked the previous approach, but this one is more explicit, easier to define behavior for, and easier to write validation policies to disallow if Ian wants to.

I mean, I did too, but I can't argue myself out of needing to treat it as a breaking change. 🙁 Good candidate for v2. 😉

[kflynn]

In the spirit of recent discussions about unclear feedback I want to be explicit: I don't think we should do this.

I appreciate both the candor and the willingness to disagree and commit. 🙂

[robscott]

Thanks @kflynn, this is really well written!

[robscott]

I don't feel the benefits outweigh the complexity and risk.

@howardjohn I definitely see the complexity here, can you add more detail about what risks this could introduce for us?

[shaneutt]

I think this is very well thought out, and is close to ready to start implementing and experimenting with it. I have a couple of blocking comments regarding type choices which I would like us to discuss through before any merge.

Thank you @kflynn 🖖

[shaneutt]

We came to some consensus on the types. There are still some changes to make, but I want to approve because I want to unblock, and think we're heading in a decent direction to get this into an Experimental state and start letting people try it out and provide feedback.

So once all the comments are resolved:

/approve

Thanks for all the hard work and conversations @kflynn 🖖

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: kflynn, shaneutt, youngnick

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [shaneutt,youngnick]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[robscott]

Thanks @kflynn!

/lgtm

[robscott]

I think we've got enough approvals here.

/hold cancel