-
Notifications
You must be signed in to change notification settings - Fork 447
Description
Has there ever been any consideration towards the inclusion of a feature gate flag / marker combination that could be used to control the generation of CRDs from the Go code? For example:
type FubarSpec struct {
// +optional
// +kubebuilder:featuregate=MyNewFeature
NewField string `json:"newField,omitempty"`
}
type FubarStatus struct {
}
// +kubebuilder:object:root=true
// +kubebuilder:subresource:status
// +kubebuilder:resource:scope=Namespace
type Fubar struct {
metav1.TypeMeta `json:",inline"`
metav1.ObjectMeta `json:"metadata,omitempty"`
Spec FubarSpec `json:"spec,omitempty"`
Status FubarStatus `json:"status,omitempty"`
}
type HelloWorldSpec struct {
}
type HelloWorldStatus struct {
}
// +kubebuilder:object:root=true
// +kubebuilder:subresource:status
// +kubebuilder:resource:scope=Namespace
// +kubebuilder:featuregate=MyNewFeature
type HelloWorld struct {
metav1.TypeMeta `json:",inline"`
metav1.ObjectMeta `json:"metadata,omitempty"`
Spec HelloWorldSpec `json:"spec,omitempty"`
Status HelloWorldStatus `json:"status,omitempty"`
}
The presence of the marker +kubebuilder:featuregate=MyNewFeature
would indicate to the CRD generation that the type HelloWorld
and the field NewField
from the FubarSpec
type should not be generated unless controller-gen
was executed with the following flag:
controller-gen \
paths=hello-world/api/... \
crd:trivialVersions=true \
crd:crdVersions=v1 \
crd:preserveUnknownFields=false \
crd:featureGate=MyNewFeature \
output:crd:dir=./config/crd/bases \
output:none
if a type does not specify a kubebuilder:featuregate
annotation then it is not gated, but when a type does include such a marker, then this flag could prevent CRDs from being generated with features not yet ready for consumption.
There is a real business need for this because of the way private companies, even when developing in public, may want to align on API schemas in advance of releases. However, this presents a challenge because of deadlines and the risk of a feature not being ready. Still, the API was locked months ago. The flip side is organically updating an API over the duration of a release cycle. This is also not ideal because some API schema version will be constantly changing.
What would be nice is if new features could be gated at the API level behind a feature gate. That way the development could happen in the open, but the feature's API is only included in CRDs if:
- the feature gate is enabled when generating the CRDs -- useful for testing
- the feature gate is removed -- useful ahead of release
In looking into this I did come across kubebuilder:skipversion
, but it does not seem to do quite the same thing.
Anyway, I'd love to hear others' thoughts and feedback on this. Thanks in advance!