Support setting a default GatewayClass

[robscott]

This should mirror IngressClass behavior:

You can mark a particular IngressClass as default for your cluster. Setting the ingressclass.kubernetes.io/is-default-class annotation to true on an IngressClass resource will ensure that new Ingresses without an ingressClassName field specified will be assigned this default IngressClass.

Unfortunately this would mean that we'd need a mutating webhook to implement this.

[hbagdi]

Don't you also need a mutating webhook to inject the default if a class is not set?

[robscott]

🤦 Thanks! That's what I meant to say, updated the original comment so it's more clear now.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[hbagdi]

/remove-lifecycle stale
/lifecycle frozen

[hbagdi]

@robscott Is adding a default considered a breaking change? In some cases yes, here I think we should be good. Want to confirm.

[robscott]

Yeah I don't think this would be a breaking change. This would require:

1. Supporting a new annotation on GatewayClass to mark it as default.
2. Making GatewayClassName on Gateway optional

When GatewayClassName was unset, a webhook would fill it in with a default value. If there was no default, maybe we'd have to reject the Gateway entirely? I'm not exactly sure on the specifics here, but it does not seem like it would be a breaking change to me.

[shaneutt]

Just out of curiosity is the onus to implement this based on a specific implementation's needs or is it an effort towards further feature parity with Ingress?

[shaneutt]

While grooming we saw that this one was open for a long period of time without anyone with a strong use case to champion it. We're going to close this as we don't expect anyone's ready to drive it forward, but if you still want this feature and have a strong use case we will be happy to reconsider this and re-open.

[james-callahan]

I'd still love to see this feature.

It shouldn't be up to the ClusterOperator to know the name of the GatewayClass chosen by the Infrastructure Providers.

In the more general case, it means there's no sensible default for any Gateway specification: if it's part of a kustomize application or helm template then it has to be fully plumbed through and a value provided.

[shaneutt]

It shouldn't be up to the ClusterOperator to know the name of the GatewayClass chosen by the Infrastructure Providers.

An understandable position (and it might be worth noting that we're discussing a similar topic about roles, and which should have to know about what over in #3385).

There's a proposal in there to simply provide a default. Would that potentially help here as well? Definitely something worth thinking about 🤔

[youngnick]

GatewayClass processing is more complicated than the Gateway parentRef, because it's cluster-scoped.

That said, it might be possible to change this, but would require replicating some functionality like IngressClass: having a way to mark a GatewayClass as the default for the cluster (with rules for which wins when multiple set it), and then making Gateway's 'spec.gatewayClassName` field optional (with the understanding that not specifying a GatewayClass when there is no default will do nothing).

Again, the reason why we didn't do this before is it is risky. If Ian the infra admin changes the default GatewayClass, then all non-specified Gateways will need to be re-provisioned, which probably would involve an outage. That makes changing that field a very risky operation.

Basically, every default we add adds magic, and magic adds risk. Explicitly specifying things removes risk, because the owner of a resource needs to take definite action for a change to occur.