Current CRDs aren't valid against the Kubernetes API specification

[wilmardo]

trafficstars

Describe the bug

The metadata.creationTimestamp must be of the string type according to the schema.

Steps to reproduce

# wget https://github.com/fluxcd/source-controller/releases/download/v0.22.5/source-controller.crds.yaml
# kubeconform -schema-location default -schema-location "https://raw.githubusercontent.com/yannh/kubernetes-json-schema/master/master/customresourcedefinition.json" source-controller.crds.yaml
source-controller.crds.yaml - CustomResourceDefinition gitrepositories.source.toolkit.fluxcd.io is invalid: For field metadata.creationTimestamp: Invalid type. Expected: string, given: null
source-controller.crds.yaml - CustomResourceDefinition buckets.source.toolkit.fluxcd.io is invalid: For field metadata.creationTimestamp: Invalid type. Expected: string, given: null
source-controller.crds.yaml - CustomResourceDefinition helmrepositories.source.toolkit.fluxcd.io is invalid: For field metadata.creationTimestamp: Invalid type. Expected: string, given: null
source-controller.crds.yaml - CustomResourceDefinition helmcharts.source.toolkit.fluxcd.io is invalid: For field metadata.creationTimestamp: Invalid type. Expected: string, given: null

Expected behavior

The CRDs are valid according to the Kubernetes API spec.

Screenshots and recordings

No response

OS / Distro

N/A

Flux version

master

Flux check

N/A

Git provider

No response

Container Registry provider

No response

Additional context

What is the reason that there is an empty creationTimestamp? I could submit a PR to fix this but would that be by removing it or setting it to an empty string? I have no historical knowledge why it is currently defined as empty :)

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

[stefanprodan]

The CRDs are generated with controller-gen, we have no control over this process, please submit this issue to Kubernetes or kubeconform.

[wilmardo]

@stefanprodan Thanks! controller-gen was a good hint to get somewhere with this issue. As seen above I opened an issue over at Kubernetes with my findings. I will keep the issue open for now (if you don't mind) since currently the FluxCRDs are indeed invalid according to the Kubernetes spec:

"creationTimestamp": {
          "$ref": "#/definitions/io.k8s.apimachinery.pkg.apis.meta.v1.Time",
          "description": "CreationTimestamp is a timestamp representing the server time when this object was created. It is not guaranteed to be set in happens-before order across separate operations. Clients may not set this value. It is represented in RFC3339 form and is in UTC.\n\nPopulated by the system. Read-only. Null for lists. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata"
},

The $ref of Time where it states type: string

"io.k8s.apimachinery.pkg.apis.meta.v1.Time": {
      "description": "Time is a wrapper around time.Time which supports correct marshaling to YAML and JSON.  Wrappers are provided for many of the factory methods that the time package offers.",
      "format": "date-time",
      "type": "string"
},

But this could well be that the Kubernetes api spec is wrong or something else on the Kubernetes side of things. So no action needed for now but I can imagine that an update of controller-gen could be needed in the future.

[stefanprodan]

One workaround would be to use a kustomize remove patch that targets the CRD Kind in all these overlays to delete the creationTimestamp field https://github.com/fluxcd/flux2/tree/main/manifests/bases

[stefanprodan]

creationTimestamp has been removed in controller-gen, latest Flux CRDs no longer have it.