What to do with variants of CRDs?

[gecube]

Good day!

Today I noticed a very weird thing. Flux Operator patches the CRDs on the fly:

https://github.com/controlplaneio-fluxcd/flux-operator/blob/feb4ccea6f0708585c720bbdce993a5e5421b562/internal/builder/profiles.go#L331

It means that in fact we are getting two variants of the same CRD.

The original one from FluxCD upstream distribution: https://github.com/controlplaneio-fluxcd/flux-operator/blob/main/config/data/flux/v2.6.4/notification-controller.yaml

And the one that appears in cluster after running Flux Operator...

The question is how we should handle this. Because obviously - there are two types of users - who uses operator and who uses bare Flux...

[rouke-broersma]

In this specific case it appears that flux operator patches in fields they use internally to track resources. A user will probably never set these fields so they should not be allowed for user supplied config

[gecube]

Hi! It is correct statement. The issue is that breaks the validation logic as I understand. With the original fluxcd installation you could set a notifications for flux-operator entities. But after the installation of operator - this feature begin to work. So obviously if I want to lint a manifests, I need to select a proper CRD version... or use a broader one and forget about some corner case situations.

[rouke-broersma]

You agree that flux operator uses these fields internationally so a user shouldn't set them, but then you say you can't lint a cr that has these fields. My point is that you don't need to lint those fields as they are managed by Flux operator.

I don't understand, maybe you could give a cr example that wouldn't be properly validated with the current crd in the repo?

[gecube]

@rouke-broersma Sorry, but you did not get the point. Maybe I did not explain clearly. So we have two variants of CRD.

In the official examples we have:

apiVersion: notification.toolkit.fluxcd.io/v1
kind: Receiver
metadata:
  name: github-receiver
  namespace: app-preview
spec:
  type: github
  secretRef:
    name: receiver-token
  resources:
    - apiVersion: fluxcd.controlplane.io/v1
      kind: ResourceSetInputProvider
      name: app-pull-requests

this won't work with flux vanilla installation, but would work with flux-operator. Because of validation here:

https://github.com/brainfair/awesome-flux-head/blob/f16598a24f9aa3f5f4ab0e2f7fe45c7a8e60a0ee/clusters/homelab/flux-system/gotk-components.yaml#L12287

The ResourceSetInputProvider is added to the list inside CRD by flux-operator.