Panic on two gatewayclass definitions about stunner

[imcom]

@rg0now It works like a charm! Although I have not had enough resources to test it thoroughly, but no errors found in stunner pod in production namespace. And it no longer affects live traffic in staging namespace

Thanks!

[rg0now]

Yes, running multiple Gateway hierarchies side by side is supposed to work; in fact, your use of multiple gateway-classes is exactly the way we also had in mind.

Problem is, this mode is not supported yet: what is really funny here is that the panic occurs in the operator exactly in the code where we try to warn that multiple gateway-classes are not supported: :-))

log.Info("multiple gateway-class objects found %s: this is most probably UNINTENED - "+
	"the operator will attempt to render a configuration for each gateway-class but there "+
	"is no guarantee that this will not result in an error - this mode is UNSUPPORTED, "+
	"if unsure, remove one of the gateway-class objects!", strings.Join(names, ", "))

The fix is trivial but we'll have to roll a new operator release, please bear with us a couple of days until we get to this.

[rg0now]

This should be fixed in https://github.com/l7mp/stunner-gateway-operator/releases/tag/v0.11.4, could you please give it a try? Make sure the operator is re-deployed, otherwise you won't get the fix. Multiple gateway-classes are still completely untested so we fully expect that you see further issues.

Just to be entirely clear, the bug was in the operator, so the dataplane (stunnerd) does not need to be updated.

Another note: if using multiple gateway-classes you should deploy two separate stunner dataplanes into separate namespaces. This will make sure that the two stunner dataplanes can run each with their own configuration.

Here is how this should work:

1. Install stunner twice, each time into separate namespaces:

helm install stunner stunner/stunner --create-namespace --namespace=stunner-production
helm install stunner stunner/stunner --create-namespace --namespace=stunner-staging

2. Configure the gateway-class hierarchy for the staging namespace:

apiVersion: gateway.networking.k8s.io/v1alpha2
kind: GatewayClass
metadata:
  name: stunner-gatewayclass-staging
spec:
  controllerName: "stunner.l7mp.io/gateway-operator"
  parametersRef:
    name: stunner-gatewayconfig-staging
    namespace: stunner-staging
---
apiVersion: stunner.l7mp.io/v1alpha1
kind: GatewayConfig
metadata:
  name: stunner-gatewayconfig-staging
  namespace: stunner-staging
spec:
  ...

3. Similarly for the production namespace:

apiVersion: gateway.networking.k8s.io/v1alpha2
kind: GatewayClass
metadata:
  name: stunner-gatewayclass-production
spec:
  controllerName: "stunner.l7mp.io/gateway-operator"
  parametersRef:
    name: stunner-gatewayconfig-production
    namespace: stunner-production
---
apiVersion: stunner.l7mp.io/v1alpha1
kind: GatewayConfig
metadata:
  name: stunner-gatewayconfig-production
  namespace: stunner-production
spec:
  ...

4. Now, whenever you add a Gateway with gatewayClassName: stunner-gatewayclass-staging the corresponding Gateway will be attached to the "staging" gatewayclass-hierarchy and the corresponding configuration will be picked up by the stunner dataplane running in the staging namespace, and similarly for the production hierarchy. I think you'll need separate UDPRoutes for both hierarchies but this shouldn't really be a problem.

Don't forget to leave a note here if this works, or reopen if it does not.