kubebuilder: [Discussion] V3 breaking changes

Shows that we could create an EP for the add api option. WDYT?

1. The most common use case by far (anecdotal evidence only) is creating both a controller and resource. I do sometimes see one or the other (or neither) being created to support external types, so having the choice of either or neither mode is still useful. Having a command for each mode confounds the currently straightforward workflow. Therefore I vote to leave the create api command as-is, except invert flag defaults to true.
2. Having an extra flag makes sense, since we need to know where the external types are coming from as they aren’t in api/<version> or apis/<group>/<version>. I like @camilamacedo86’s idea of supplying a module/import path, perhaps with a more descriptive flag like --external-import. kubebuilder create api shouldn’t be doing any go get stuff though; that’ll be done by calling make targets. The input would also have to describe the exact import path, and --group would have to be the full API group:

   kubebuiler create api \
   	--external-import=github.com/openshift/api/route/v1@v0.18.2 \
   	--group=route.openshift.io \
   	--kind=Route \
   	--version=v1
   

   We might also want to add the resource to resources in the config with an external: <boolean> qualifier.

IMO:

Over split the command create api

• Pros: keep concepts such as cohesion and single responsibility in the commands/plugins (maintainability)
• Cons: GKV would be required in both which means that the user would need to inform them twice

So, shows for me that we might be prevailing keep it ease to maintaining instead of user experience. In this way, I am afraid that I am more inclined to vote against since I think the UX is more important here.

Over new flag to work with external types

I totally agree that we need to address this scenario. WDYT about we raise a new specific issue for this RFE? Also, instead of not scaffold the files I think we ought to educate and facilitate to the users how to work with for the external type which could be something such as we have a new plugin for that since we will not create an api but we will add one preexistent into the project.

Example: kubebuiler add api --module=github.com/openshift/api --kind=route --version=v1

• Run go get -u go get -u github.com/openshift/api // run go get -u {{module}}
• Add the schema into the main.go:

import (
	...
	routev1 "github.com/openshift/api/route/v1"  // see {{kindversion}} {{module}} 
	...
)

...

func init() {
...
	   // Add external type  	
           utilruntime.Must(routev1.AddToScheme(scheme))

• Add in the external type in the suite_test.go as well.

import (
	...
	routev1 "github.com/openshift/api/route/v1"  // see {{kindversion}} {{module}} 
	...
)
....
var _ = BeforeSuite(func(done Done) {
...
       	err = routev1.AddToScheme(scheme.Scheme)  // see {{kindversion}}
	Expect(err).NotTo(HaveOccurred())
...
}