🏃 structure and expose cobra cmds

[hasbro17]

Description:
This restructures the cmd directory into pkgs that follows the
hierarchy of CLI subcommands. This helps to expose the New***Command() functions
that return the cobra subcommands so they can be consumed by downstream
projects that need to reuse Kubebuilder CLI for scaffolding projects.

The new pkg layout for cmd:

cmd
├── alpha
│   ├── alpha.go
│   └── webhookv1
│       └── webhook_v1.go
├── create
│   ├── api
│   │   └── api.go
│   ├── create.go
│   └── webhookv2
│       └── webhook_v2.go
├── init
│   ├── go_version_test.go
│   └── init_project.go
├── main.go
├── update
│   └── vendor_update.go
├── util
│   ├── stdin.go
│   └── util.go
└── version
    └── version.go

Motivation:
This follows up on the proposal to integrate the Operator SDK with Kubebuilder.
The goal here is to expose the cobra commands for kubebuilder init and kubebuilder create so that the SDK can consume them downstream in its own CLI.
This allow the SDK to easily reuse Kubebuilder's scaffolding and CLI workflow.

While the plugins-based-extensions approach would still be a long term goal, consuming the Kubebuilder CLI in the SDK in the short run allows us to prototype and make changes in the SDK to make it compatible with Kubebuilder's project layout and expected workflow.

[k8s-ci-robot]

Welcome @hasbro17!

It looks like this is your first PR to kubernetes-sigs/kubebuilder 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes-sigs/kubebuilder has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

[k8s-ci-robot]

Hi @hasbro17. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: hasbro17
To complete the pull request process, please assign mengqiy
You can assign the PR to them by writing /assign @mengqiy in a comment when ready.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[hasbro17]

/assign @DirectXMan12

[hasbro17]

While this does expose all the cobra subcommands functions, the ones strictly needed for our purposes are the NewCreateCmd() and NewInitProjectCmd(), but since the other subcommands are no longer in pkg main they need to be exposed so they can be imported by their parent commands.
We can move the other subcommand pkgs to cmd/internal/... if needed however.

Also since this effectively exposes a public API in Kubebuilder, #1042 would eventually need a fix to allow importing this as sigs.k8s.io/kubebuilder/v2 or sigs.k8s.io/kubebuilder/v3. Although this can still be worked around by pinning to the commit so probably not that pressing.

[mengqiy]

/ok-to-test

[k8s-ci-robot]

@hasbro17: The following test failed, say /retest to rerun them all:

Test name	Commit	Details	Rerun command
pull-kubebuilder-test	02fc1d1	link	/test pull-kubebuilder-test

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

[DirectXMan12]

o_O I was under the impression that OperatorSDK wouldn't being doing a separate CLI like this (hence the plugin stuff)?

EDIT: I can definitely read PR descriptions. Yep. I definitely read that whole thing and didn't skip like 2 paragraphs at the end. Nope, not at all.

/hold

[DirectXMan12]

@joelanford

[DirectXMan12]

While the plugins-based-extensions approach would still be a long term goal, consuming the Kubebuilder CLI in the SDK in the short run allows us to prototype and make changes in the SDK to make it compatible with Kubebuilder's project layout and expected workflow.

This makes me inherently nervous, since it means that things are depending on the internals, more or less. Can we chat about this next week at the meeting? I was imagining prototyping would be done via "fork & custom plugin" or something similar, and then any changes to the plugin subsystem would be resubmitted.

[joelanford]

@DirectXMan12 Sorry, we didn't mean to catch you off guard with this. Let's chat more at the community meeting next week. We can talk through our thought process and discuss if there are any other alternatives.

[hasbro17]

Closing this per our offline discussion to explore a different strategy of reusing the plugin interface without exposing the CLI directly.