kubernetes: creationTimestamp: null is invalid since it isn't a string
What happened?
There seems to be a discrepancy between the Kubernetes openapi spec and the Go package with the creationTimestamp
What did you expect to happen?
CRDs generated by controller-gen
which uses k8s.io/apimachinery/pkg/apis/meta/v1
to be valid according to the Kubernetes openapi spec.
How can we reproduce it (as minimally and precisely as possible)?
# 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
Anything else we need to know?
At first I raised an issue at https://github.com/fluxcd/flux2/issues/2623 since they seemed to be the culprit.
But received a response that they use controller-gen
to generate the CRDs. So I looked into controller-gen and they also do not set the creationTimestamp
they import k8s.io/apimachinery/pkg/apis/meta/v1
for the generation of the metadata (where the creationTimestamp is part of)(source).
So now the issue, in the package documentation (link) of k8s.io/apimachinery/pkg/apis/meta/v1
it says the following about the creationTimestamp
// 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.
//
// Populated by the system.
// Read-only.
// Null for lists.
// More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
// +optional
Creation[Time](https://pkg.go.dev/k8s.io/apimachinery/pkg/apis/meta/v1#Time)stamp Time `json:"creationTimestamp,omitempty" protobuf:"bytes,8,opt,name=creationTimestamp"`
So there is something in the docblock about Null for lists(?) but in the openapi spec of Kubernetes is this Time
resource marked as 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"
},
https://raw.githubusercontent.com/kubernetes/kubernetes/master/api/openapi-spec/swagger.json
So now, what is wrong here? Is it indeed allowed to be a string or null and should the openapi spec be an enum? Or is there something ink8s.io/apimachinery/pkg/apis/meta/v1
wrong? Or should controller-gen
explictly set the creationTimestamp to an string?
The last one seems kinda wrong to me since it seems to me that the k8s.io/apimachinery/pkg/apis/meta/v1
should return data valid to the api spec.
I am sorry for all the text and if I did not understand something correctly š I donāt develop in golang (or at all really) and the relation between the package and the openapi spec is quite vague for me.
I opened the issue here since it seems an issue affecting multiple things within the kubernetes namespace (golang package, openapi spec in this repo).
Kubernetes version
Cloud provider
NaN
OS version
No response
Install tools
No response
Container runtime (CRI) and version (if applicable)
No response
Related plugins (CNI, CSI, ā¦) and versions (if applicable)
No response
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Reactions: 2
- Comments: 16 (10 by maintainers)
Would be great if this can be fixed, so that we donāt have to remove lines with
creationTimestamp: null
manually for our CI linting./cc @jpbetz @sttts /triage accepted