Skip to content

Support for a feature gate flag/marker when generating CRDsΒ #600

@akutz

Description

@akutz

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!

Metadata

Metadata

Assignees

No one assigned

    Labels

    help wantedDenotes an issue that needs help from a contributor. Must meet "help wanted" guidelines.lifecycle/frozenIndicates that an issue or PR should not be auto-closed due to staleness.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions