Be able to execute the commands operator-sdk generate k8s and openapi…

[camilamacedo86]

Description of the change:

• Change sub-commands for no longer relay in the Dockerfile and main.go files.

PS.: It was tested/review already for 2 teammates but we revert this one in order to not risk the release. Also, the Changelog was improved as suggested by @joelanford.

• See the original PR: Allow some commands to generate k8s, without requiring build files. #1966
• See the revert one: Revert "Allow some commands to generate k8s, without requiring build … #2039

Motivation for the change:
Closes: #1804 and #1686
PS.: Helpful for #1964

[camilamacedo86]

/test e2e-aws-subcommand

[camilamacedo86]

/test e2e-aws-ansible

[joelanford]

I'm not sure I agree with the motivations from #1804 and #1686. For those cases, it may be more reasonable to tell users to use controller-gen directly. That would give users total flexibility for generating CRDs and code outside of the context of an SDK project.

IMO operator-sdk generate is effectively nice wrapper of controller-gen for use in SDK projects. It knows where to find APIs, and it outputs files in known (and non-overridable) locations that are specific to SDK project structures. For those reasons, I think it makes sense for the operator-sdk binary to check that it is in an SDK project.

In the future when we have integrated Kubebuilder scaffolding, the generate subcommands will be replaced by make targets that call controller-gen directly, and this problem will be solved. In the meantime, I would suggest that we close #1804 and #1686 by commenting in them with the equivalent controller-gen command to run and link to #1600 (comment) for background about why we're hesitant to support more flexibility in the existing subcommands.

[joelanford]

/hold

Based on my above comment, I think there needs to be more discussion about whether we want to take this approach.

[camilamacedo86]

Closing this one as defined.