Update GatewayClass status based on EnvoyProxy validation

[arkodg]

• Refactor EnvoyProxy's Validate API
• If a GatewayClass references a EnvoyProxy resource, ensure that that the GatewayClass status condition is based off the EnvoyProxy validation result

Relates to #31

[arkodg]

@Xunzhuo, Im unable to generate the manifests for the webhook by adding the kubebuilder annotations to the file and running make manifests, has something changed with the helm stuff ?

[Xunzhuo]

Nothing changes except the output path in make manifests.

Can you tell where,what annotations you add? I will have a try too

@arkodg

[zirain]

kindly ping @arkodg , are you still working on this?

[arkodg]

kindly ping @arkodg , are you still working on this?

yes 😅 will resume next week

[arkodg]

Below logs highlight that the the Accepted condition is set to False with a reason of InvalidParameters when validation fails on the referenced EnvoyProxy resource

🐳 ~/go-workspace/src/github.com/envoyproxy/gateway$ kubectl get envoyproxy/ep-config -n envoy-gateway-system -o yaml
apiVersion: config.gateway.envoyproxy.io/v1alpha1
kind: EnvoyProxy
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"config.gateway.envoyproxy.io/v1alpha1","kind":"EnvoyProxy","metadata":{"annotations":{},"name":"ep-config","namespace":"envoy-gateway-system"},"spec":{"bootstrap":"blah","logging":{"level":{"system":"debug"}}}}
  creationTimestamp: "2023-04-05T21:58:31Z"
  generation: 2
  name: ep-config
  namespace: envoy-gateway-system
  resourceVersion: "5009"
  uid: ee973c95-a96f-49f3-90ec-233349dbe1bc
spec:
  bootstrap: blah
  logging:
    level:
      system: debug
🐳 ~/go-workspace/src/github.com/envoyproxy/gateway$ kubectl get gc/eg -o yaml
apiVersion: gateway.networking.k8s.io/v1beta1
kind: GatewayClass
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"gateway.networking.k8s.io/v1beta1","kind":"GatewayClass","metadata":{"annotations":{},"name":"eg"},"spec":{"controllerName":"gateway.envoyproxy.io/gatewayclass-controller","parametersRef":{"group":"config.gateway.envoyproxy.io","kind":"EnvoyProxy","name":"ep-config","namespace":"envoy-gateway-system"}}}
  creationTimestamp: "2023-04-05T21:54:21Z"
  finalizers:
  - gateway-exists-finalizer.gateway.networking.k8s.io
  generation: 2
  name: eg
  resourceVersion: "31384"
  uid: 0db8dcfd-b3f7-4cff-8c82-acedc388b78f
spec:
  controllerName: gateway.envoyproxy.io/gatewayclass-controller
  parametersRef:
    group: config.gateway.envoyproxy.io
    kind: EnvoyProxy
    name: ep-config
    namespace: envoy-gateway-system
status:
  conditions:
  - lastTransitionTime: "2023-04-05T22:10:54Z"
    message: 'Invalid parametersRef: invalid gatewayclass eg: invalid envoyproxy:
      unable to unmarshal user bootstrap: proto: syntax error (line 1:1): unexpected
      token "blah"'
    observedGeneration: 1
    reason: InvalidParameters
    status: "False"
    type: Accepted
    ```

[codecov]

Codecov Report

Merging #1107 (14da7f5) into main (d53b561) will decrease coverage by 3.22%.
The diff coverage is 90.00%.

@@            Coverage Diff             @@
##             main    #1107      +/-   ##
==========================================
- Coverage   63.95%   60.73%   -3.22%     
==========================================
  Files          80       84       +4     
  Lines       10010    10542     +532     
==========================================
+ Hits         6402     6403       +1     
- Misses       3184     3715     +531     
  Partials      424      424              

Impacted Files	Coverage Δ
internal/provider/kubernetes/controller.go	50.38% <0.00%> (+0.22%)	⬆️
api/config/v1alpha1/validate.go	75.58% <100.00%> (ø)
internal/xds/server/runner/runner.go	30.09% <100.00%> (ø)

... and 5 files with indirect coverage changes

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[zirain]

what's the expected behavior when apply a wrong EnvoyProxy? EG use last correct EnvoyProxy?
what will happen when EG control plane restarts after a wrong EnvoyProxy applied?

[arkodg]

what's the expected behavior when apply a wrong EnvoyProxy? EG use last correct EnvoyProxy?
what will happen when EG control plane restarts after a wrong EnvoyProxy applied?

thanks for raising this, even w/o this PR we were failing fast - removing the GatewayClass from being accepted if EnvoyProxy was invalid, causing entire deletion of data plane. Imo this should be discussed in a separate issue if we want to handle this more gracefully

[zirain]

Overall LGTM, can you open a ticket for the discussion?