GEP-3793: Default Gateways

[kflynn]

/kind gep

What/Why/Who for Routes attaching to default Gateways, rather than needing to specify the Gateway.
Fixes #3793.

NONE

[candita]

We could permit multiple gateways that are still easy to identify by allowing one default gateway per namespace. Ana should be able to identify the namespace to use.

[youngnick]

I think the thing that's the most important to remember here is that choosing a default Gateway is also choosing a default GatewayClass and implementation, so we'll need to be deliberate about how we do that to ensure that multiple-Gateway-implemetation clusters work well too.

[kflynn]

I'm not completely opposed to the idea of a default per namespace, but the more I think about, the more potential I think there is for confusion: while a great many people run namespace-per-tenant, others e.g. use namespaces as logical divisions within a single application, or a namespace per dev team, or whatever. So it's kind of less clear to me that default-per-namespace should be an initial goal.

[candita]

Can you explain why we need separate features for separate route types?

[kflynn]

Maybe we don't -- as I note in the next line or so, though, GatewayDefaultGateway seemed silly. Have another suggestion? 🙂

[youngnick]

There's not really a specific line to make this comment on, so I'll do it globally:

One of the key things I want to make sure we consider is that requiring explicit config does help Ana in the troubleshooting case - because there is an explicit definition of hierarchy via parentRefs and spec.gatewayClassName on Gateway, it's easier to trace out the full tree of related resources.

Each thing that we do that makes that less explicit will add some more cost to troubleshooting and make it a bit harder. So we need to make sure that we're both weighing the difficulty of troubleshooting against ease of initial creation.

Personally, one of the reasons I've pushed hard for so much explicit behavior is not only because we need to service Ian and Chihiro, but also to make the troubleshooting case easier for Ana. I believe that, like code, config is read orders of magnitude more than it's created, so I've tended to err on the side of making things explicit, because that makes troubleshooting easier.

I've seen this before in many contexts, like in network engineering, where BGP is way more explicitly configured than OSPF, and so I found BGP way easier to troubleshoot than OSPF. And in programming, one of the things I personally like about Go is that it encourages an explicit, if verbose, coding style - because I personally spend way more time reading code than I do writing it.

I definitely don't dispute that making it easier to get started is useful - I just want to make sure that we're being conscious about what we give up as we do it.

[robscott]

Thanks @kflynn! This is a great start, looking forward to discussing the details in the next phase of this.

[shaneutt]

(see additional review below)

[shaneutt]

Looks good to merge as Provisional.

/approve
/lgtm

However there are a few lingering comments with concerns, we should create a "TODO" list of sorts under the graduation criteria enumerating these concerns to point out that we need to address them prior to any further graduation.

/hold

After those are documented, we are good to release the hold and merge.

[kflynn]

One of the key things I want to make sure we consider is that requiring explicit config does help Ana in the troubleshooting case - because there is an explicit definition of hierarchy via parentRefs and spec.gatewayClassName on Gateway, it's easier to trace out the full tree of related resources.

Updated with a new Debugging and Visibility section.

[kflynn]

This should be ready to go!

[shaneutt]

Looks like comments are resolved and there are no reviews that are blocking. We appear to be ready to move forward as Provisional.

/approve
/lgtm
/unhold

If anyone reviewing this does have a lingering concern that we missed, please feel free to create a follow-up PR adding anything you feel is missing to the GEP.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

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

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:

• geps/OWNERS [robscott,shaneutt]

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