You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The original motivation for this test #1179 was to support git ops tools. Having status fields in resources is problematic for gitops tools because (one proposal) for the semantic are
In general, what is declared in git is "the subset of fields and values that my objects must have set." Other fields and values can be present, but they can not conflict. Empty status is problematic because an empty status in git is essentially declaring "I always want an empty status on this resource." Beyond that, declaring a status in the source of truth is wrong from a semantic point of view.
These are the semantics expressed by ACM at least. Nonetheless, I think it is consistent with the K8s pattern that you should only be updating and specifying the spec.
It looks like the problem might be that earlier versions of kubebuilder were including CRD's in the status.
I think its better if we handle the cleanup of status in kubeflow/manifests and don't force users to have to deal with it.
The unittest is intended to capture examples that break this (e.g. the Seldon CRD) and then fix it. There are a couple approaches to fixing it
Application owners can choose to manually edit the CRDs or other resources and remove status
We can invest in writing a kustomize function to transform all resources and remove resources
#1375 added an exception to our unittest to ensure resources don't have status fields to allow customresourcedefinitions to have
status.
manifests/tests/validate_resources_test.go
Line 233 in 8a95734
I don't think we want to allow status fields.
The original motivation for this test #1179 was to support git ops tools. Having status fields in resources is problematic for gitops tools because (one proposal) for the semantic are
These are the semantics expressed by ACM at least. Nonetheless, I think it is consistent with the K8s pattern that you should only be updating and specifying the spec.
It looks like the problem might be that earlier versions of kubebuilder were including CRD's in the status.
I think its better if we handle the cleanup of status in kubeflow/manifests and don't force users to have to deal with it.
The unittest is intended to capture examples that break this (e.g. the Seldon CRD) and then fix it. There are a couple approaches to fixing it
Proposal
@cliveseldon does that seem reasonable?
The text was updated successfully, but these errors were encountered: