Support hybrid operators

[hasbro17]

EDIT(@estroz): this issue originally addressed a bug where users could create apis, controllers, and k8s deepcopy code in non-Go projects. Since significant discussion related to hybrid operators is present here, I changed the title and am keeping this issue open to further track hybrid operator discussion. #672 fixed the original bug.

---

Original issue text:

The following SDK commands are only relevant to a Go type project and should not run in another project type like Ansible(or Helm in the future).

• operator-sdk add api ...
• operator-sdk add controller ...
• operator-sdk generate k8s

[hasbro17]

We need to consider the use case of transitioning from a pure Ansible type project to a hybrid or Go type project before we restrict these commands from running in an ansible type project.

[shawn-hurley]

I was thinking that the steps for transition are:

1. In Go path.
2. drop cmd/manager/main.go on disk (this will need to be the correct main.go though maybe there is enough overlap between helm and ansible here that we can make this really easy and only 1 file?).
3. add/change dockerfile to incorporate the binary
4. dependencies for golang.

All of these are steps I could document today and we would have a transition path, before or after operator-sdk add api is called. Maybe it makes sense that we have to do these steps before you can call these? I am torn here because I could see myself creating the API and then doing the main file bits etc..., but on another hand sometimes taking away options just leads to fewer bugs.

I think either way the above commands must be in the gopath is that correct?

[joelanford]

2. drop cmd/manager/main.go on disk (this will need to be the correct main.go though maybe there is enough overlap between helm and ansible here that we can make this really easy and only 1 file?).

@shawn-hurley I think the only differences would be loading the watches.yaml file and calling Add() with the correct controller. If those aren't the only differences, I would think we could get there.

Also, do we need to consider transitions between or hybrid combinations of arbitrary types (e.g. Ansible to Helm, or hybrid Ansible/Helm)?

I think this discussion raises the question of what the strategy for the CLI design should be. The current design holds up well when there's only one operator type, but now that we'll have three, each adding new subcommands and/or implementing existing subcommands differently, some issues arise:

• As a user, how do I know which subcommands make sense for my project?
• If we support hybrid operators, what should the SDK do when more than one of the operator types is present in the project and a subcommand is executed that has different implementations for different operator types? Maybe we detect that multiple types exist and fail telling the user that --type is required for hybrid operators?

Is it possible to invert the precedence of operator type and subcommand in the CLI so that the operator type drives what subcommands are available and makes the subcommand execution explicit?

[estroz]

A combination of good transition/hybrid documentation and strict checks/plenty of warnings on CLI usage should be enough.

Instead of thinking of all the ways a user can combine operator types, we should be opinionated about how they should be combined, and to what extent combination is allowable, if at all. For example, what parts of an Ansible project can be customized with Go, and what cannot?

If we want to allow hybrid projects, we need to reconsider how OperatorType is used since type checks are currently exclusive. I suggest we implement a bitfield.