Add plugins based CLI

[hasbro17]

Description of the change:
Add a new CLI entrypoint based on Kubebuilder plugins.
Currently uses plugins from the feature/plugins-part-2-electric-boogaloo branch until kubernetes-sigs/kubebuilder#1469 is merged at which point we can update go.mod to use the master branch.

The operator-sdk CLI now has 2 entrypoints:

• The existing CLI (called cmd/operator-sdk/cli/legacy.go now) which has been updated with a hidden operator-sdk init command to allow scaffolding kubebuilder projects. See operator-sdk init --project-version=2 -h.
• The Kubebuilder aligned CLI (cmd/operator-sdk/cli/cli.go) which only shows once you're inside a Kubebuilder project with a valid PROJECT file.

Once the integration is complete and we decide the CLI is ready for a release, we can change the order of the CLI entrypoints to make the Kubebulder aligned CLI the default, and deprecate the legacy CLI.

Also added website/content/en/docs/kubebuilder/quickstart.md as the new quickstart guide that is aligned with the new CLI and layout.
This quickstart guide defers to upstream docs as much as possible since the kubebuilder docs are detailed enough for further reading.
This doc folder will remain hidden from the website, since it has no index, until the integration and corresponding docs are completed.

Some of the advanced sections like metrics and kube-state CR metrics don't apply directly anymore since the Kubebuilder default scaffolding doesn't use SDK helpers for metrics.
So I've marked those as TODOs and we'll need to figure out how to update/remove those docs.

[hasbro17]

This can finally use some reviews.

In particular please go through the quickstart guide to verify the steps (skip the advanced sections), and look for typos/rephrasing etc.
If you have any suggestions for some of the TODOs I've marked feel free to comment although in most cases that's going to be addressed in follow up PRs to keep the scope of this PR limited to the new CLI workflow.

I am having some trouble with the sample-memcached example in the last step where the reconciler is failing to update the CR status:

2020-04-14T21:14:42.978-0700    ERROR    controllers.Memcached    Failed to update Memcached status    {"memcached": "default/memcached-sample", "error": "memcacheds.cache.example.com \"memcached-sample\" not found"}

Debugging this to see if it isn't just my Kind cluster but I could use a verification on the updated sample-memcached reconciler code.

[camilamacedo86]

The changes here shows ok for me. IHMO:

• We could take advantage and create the testdata dir to scaffold a project to test it as it is done in the kubebuilder when we run the command make generate and the add the CI check as well to ensure that testdata is updated with the changes. See: the shell to gen the mock testdata and the shell that is used to check it in the CI here. Then, it would more less a copy and paste which would allow we to check the projects scaffolded with, help us to verify the PR and ensure its quality. We also can run its tests as well.
• Also, I do not think that we can merge this PR in the master until plugin phase 1 be merged there as well.

c/c @estroz

[joelanford]

We could take advantage and create the testdata dir to scaffold a project to test it as it is done in the kubebuilder

IMO we shouldn't duplicate kubebuilder tests. Once we get to the point of making additional tweaks or changes to the Kubebuilder scaffolds or when we add our own plugins with custom layouts, it might make sense to add similar tests. Until then, I don't see how it adds any value, unless I'm misunderstanding something.

Also, I do not think that we can merge this PR in the master until plugin phase 1 be merged there as well.

Typically I would agree with this, but I think in this case, it might make sense to push forward on this since:

• We're not making the KB CLI the default yet
• We're just now introducing the KB dependency, so our existing legacy code is not affected by the use of a feature branch commit.

What do others think?

[camilamacedo86]

HI @joelanford,

I got your point of view over merge based on the branch and then it is OK for me.

Regards the tests I really think that we should add them as soon as possible because as you said now we have nothing on top but we will have it. However, IHMO it is not a blocker to merge this PR at all. Would just make easier perform the review. I am checking it manually anyway.

[joelanford]

Looks great! Just a few of non-blocking nits.

[jmccormick2001]

    Foo string `json:"foo,omitempty"`

in testing this, I noticed that the above get generated by default...expected? I guess it doesn't matter but users might ask about it.

[jmccormick2001]

For this example replace the generated controller file controllers/memcached_controller.go with the example memcached_controller.go implementation.

the link to memcached_controller.go appears to be broken in the quickstart doc.

[jmccormick2001]

the quickstart guide doesn't specifically call out that you need to install kustomize, that might be good at the top of the quickstart unless I missed it somewhere else. same for the kubebuilder installation being a dependency.

[jmccormick2001]

For this example we will run the operator in the default namespace which can be specified for all resources in config/default/kustomization.yaml:

Adds namespace to all resources.

namespace: default

in testing, I noticed that it installs the operator into the namespace of 'memcached-operator-system' instead of default, so the quick start guide might need to be updated.

[camilamacedo86]

Please just check the comments:

• https://github.com/operator-framework/operator-sdk/pull/2827/files#r408935836 -
• https://github.com/operator-framework/operator-sdk/pull/2827/files#r408973355
• https://github.com/operator-framework/operator-sdk/pull/2827/files#r408983434

which are not a blocker for the merge since the goal is just to add the dep and getting started with.

Otherwise, it shows great. Good work 🥇

/lgtm
/approve

c/c @hasbro17 @estroz @joelanford

[hasbro17]

@jmccormick2001 Addressing your comments here but for follow ups it'll probably be better to add direct review comments on the PR files so I can respond to them more easily.

Foo string json:"foo,omitempty"
in testing this, I noticed that the above get generated by default...expected?

That's the default scaffold in Kubebuilder for the sample CR so it's expected.

the link to memcached_controller.go appears to be broken in the quickstart doc.

That link is currently pointing to the file on the master branch which should work once this PR is merged.
https://github.com/operator-framework/operator-sdk/blob/master/example/kb-memcached-operator/memcached_controller.go.tmpl

the quickstart guide doesn't specifically call out that you need to install kustomize

Yep good point. I'll add that to the pre-reqs.

in testing, I noticed that it installs the operator into the namespace of 'memcached-operator-system' instead of default, so the quick start guide might need to be updated.

I'll make the following statement more actionable to get users to actually change the kustomization.yaml file so they can run in the default namespace. Probably with kustomize edit if possible.

For this example we will run the operator in the default namespace which can be specified for all resources in config/default/kustomization.yaml

# Adds namespace to all resources.
namespace: default

[estroz]

Non-blocking note: the way init is retrieved prevents global flags set by root, which contain --plugins, from being retrieved. This is not blocking because right now only one plugin is available. Once kubernetes-sigs/kubebuilder#1465 merges, --plugins will be local to init, so we can bump kubebuilder commits to get --plugins registration.

[hasbro17]

Updated for review comments. Had to rebase for a conflict from master though.

[estroz]

/lgtm

after addressing nit

[openshift-ci-robot]

New changes are detected. LGTM label has been removed.