Pathological CRD generation when struct names clash

[Miles-Garnsey]

We have two packages/groups defined in our APIs directory. There is a struct with the same name in each; one of which is intended to generate a CRD, and one of which is just a field within another CRD.

Example:

// in apis/ourapp/v1beta2/ourresource1_types.go

// +kubebuilder:object:root=true
// +kubebuilder:subresource:status
// +kubebuilder:storageversion
// +kubebuilder:resource:path=missioncontrolclusters,shortName=mccluster;mcclusters

type Bar struct {
	metav1.TypeMeta   `json:",inline"`
	metav1.ObjectMeta `json:"metadata,omitempty"`

	Spec   BarSpec   `json:"spec,omitempty"`
	Status BarStatus `json:"status,omitempty"`
}

type BarSpec {
...
Foo *Foo `json:"foo,omitempty"`
...
}

type Foo struct {
...
}

// in apis/ourapp/v1alpha1/ourresource2_types.go

// +kubebuilder:object:root=true
// +kubebuilder:subresource:status
// +kubebuilder:storageversion
// +versionName=v1alpha1
// +kubebuilder:printcolumn:name="Error",type=string,JSONPath=".status.error",description="Latest reconcile error"

type Foo struct {
	metav1.TypeMeta   `json:",inline"`
	metav1.ObjectMeta `json:"metadata,omitempty"`

	Spec   FooSpec   `json:"spec,omitempty"`
	Status FooStatus `json:"status,omitempty"`
}

When the CRDs get generated, we're seeing both a v1alpha1 and v1beta2 resource version being created within the CRD.

This is incorrect and results in the spec of the Foo being deleted due to some sort of conversion webhook mechanics.

Is there a documented constraint that a struct with the same name as a kubebuilder object root cannot exist in another API version/package?

[sbueringer]

Is there a documented constraint that a struct with the same name as a kubebuilder object root cannot exist in another API version/package?

Not that I'm aware of. Sounds like a bug

[cbandy]

The following reproduces the issue. There should be no v1beta1 in *_bars.yaml.

diff --git a/pkg/crd/testdata/multiple_versions/testdata.kubebuilder.io_bars.yaml b/pkg/crd/testdata/multiple_versions/testdata.kubebuilder.io_bars.yaml
index 5c5861e5..e3fd8ec0 100644
--- a/pkg/crd/testdata/multiple_versions/testdata.kubebuilder.io_bars.yaml
+++ b/pkg/crd/testdata/multiple_versions/testdata.kubebuilder.io_bars.yaml
@@ -14,6 +14,12 @@ spec:
     singular: bar
   scope: Namespaced
   versions:
+  - name: v1beta1
+    schema:
+      openAPIV3Schema:
+        type: object
+    served: true
+    storage: false
   - name: v1beta2
     schema:
       openAPIV3Schema:
diff --git a/pkg/crd/testdata/multiple_versions/v1beta1/types.go b/pkg/crd/testdata/multiple_versions/v1beta1/types.go
index 207ef5c7..02389b4b 100644
--- a/pkg/crd/testdata/multiple_versions/v1beta1/types.go
+++ b/pkg/crd/testdata/multiple_versions/v1beta1/types.go
@@ -43,3 +43,5 @@ type VersionedResourceList struct {
 	metav1.ListMeta `json:"metadata,omitempty"`
 	Items           []VersionedResource `json:"items"`
 }
+
+type Bar struct{}
diff --git a/pkg/crd/testdata/multiple_versions/v1beta2/types.go b/pkg/crd/testdata/multiple_versions/v1beta2/types.go
index 8d98b876..22e20d0a 100644
--- a/pkg/crd/testdata/multiple_versions/v1beta2/types.go
+++ b/pkg/crd/testdata/multiple_versions/v1beta2/types.go
@@ -44,3 +44,11 @@ type VersionedResourceList struct {
 	metav1.ListMeta `json:"metadata,omitempty"`
 	Items           []VersionedResource `json:"items"`
 }
+
+// +kubebuilder:object:root=true
+// +kubebuilder:storageversion
+
+type Bar struct {
+	metav1.TypeMeta   `json:",inline"`
+	metav1.ObjectMeta `json:"metadata,omitempty"`
+}

[sbueringer]

Definitely makes sense