The operator-sdk documentation lays out an operator go project with api in the root directory. It also creates a Makefile with the rule make manifests defined as

$(CONTROLLER_GEN) $(CRD_OPTIONS) rbac:roleName=manager-role webhook paths="./..." output:crd:artifacts:config=config/crd/bases

so relying on controller-gen for generation of the operator CRDs.

While migrating an operator project to using this CRD generation, there exists an issue with apis that have been modularized, ie. api directory with their own mod.go file.

I've created a repository demonstrating the problem using the memcached-operator example.

• An api is generated with a version "v1" and given the kind "memcached";
• A 2nd api is generated with a version "v1alpha1" and given the kind "memcachedext";
• The 2nd api then uses a type from the v1 api hence placing a parent-child dependency on these apis.

For this to compile correctly, the v1 package had to be imported into the v1alpha1 api. This happened to require the api be modularized. Maybe, this is unnecessary for solving the import problem but is required anyway for making available the api as a module in its own right.

Issues:

• make manifests fails to generate any CRDs due to the controller-gen command;
• If the go.mod is removed then things do get generated and this seems to be a possible workaround. However, a further problem emerges due to v1alpha1 depending on v1 with the v1 CRD containing a duplicated schema, ie. 2 versions of schema v1.