feature: implement plugin proposal in #1250 #1290

estroz · 2020-01-08T23:23:41Z

Implements #1250 except for version format enforcement and plugin name resolution (will be done in follow-ups).

TODO:

~~finalize plugin interface set~~
~~discuss pro's/con's of this implementation, smooth over rough edges~~

/cc @DirectXMan12 @droot @Adirio @joelanford @shawn-hurley @camilamacedo86

k8s-ci-robot · 2020-01-08T23:23:46Z

@estroz: GitHub didn't allow me to request PR reviews from the following users: Adirio.

Note that only kubernetes-sigs members and repo collaborators can review this PR, and authors cannot review their own PRs.

In response to this:

First pass at implementing #1250.

TODO:

[] finalize plugin interface set

discuss pro's/con's of this implementation, smooth over rough edges

/cc @DirectXMan12 @droot @Adirio @joelanford @shawn-hurley @camilamacedo86

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.

pkg/cli/create.go

pkg/cli/cli.go

pkg/cli/alpha.go

joelanford · 2020-01-09T14:48:19Z

pkg/cli/cli.go

+func New(opts ...Option) (*CLI, error) {
+	c := &CLI{
+		commandName:    "kubebuilder",
+		defProjVersion: project.Version2,


Given the seeming consensus around name and version, we may need to re-think the --project-version flag and this defProjVersion field.

If we care about backward compatibility, we could keep and deprecate the --project-version flag, and make it automatically choose the "go" plugins. Maybe we don't care since --project-version is used during project initialization only (I think?).

We probably need a new init flag, maybe --plugin, that takes something like <name>/<version>. So for the existing kubebuilder plugins, it would understand go/v1 and go/v2.

Lastly, do we want to have a convention to make it easier to distinguish similar plugins from different authors? Consider two different plugins named foo. Should we include a domain component (e.g. foo.kubebuilder.io and foo.operator-framework.io)? If so, this field starts to look a lot like a Kubernetes group version string (maybe more familiar for users) and it would make it more apparent which binary a given KB project would require. One thing I don't like about this is that it requires more typing from users.

Having name + version for a plugin changes how plugins are accessed, since you can have multiple names for the same plugin version. This is fine and desired, ex. helm/v1 and go/v1 should return different plugins. Name + version needs to be recorded in PROJECT, so after running init the --plugin/--project-version flag is no longer needed.

@DirectXMan12 @droot thoughts on ^?

I kinda imagined it'd go like this:

kubebuilder init --project-version v{1,2} are mostly an alias for kubebuilder init --plugin go:v{1,2} (see below)

kubebuilder init --plugin NAME:VERSION (or NAME/VERSION) initializes a project with the given plugin, writing that to the project file with the special project version of 3x or something. We might want special handling if you actually used --project-version to write 1 or 2

After init, you never specify project version or base plugin again

As for suffixes, might not be a bad idea to encourage it, but I don't expect it'll be a big issue (famous last words) and it is a lot of extra typing. Maybe allow it as a disambiguation form, but don't require it?

@DirectXMan12 Why do you want to upgrade to v3x? I think we can acheive this being fully compatible with v1 and v2 so we wouldn't need to upgrade to v3 as the scaffold won't be modified.

The intention was at least that 3x would indicate to aware things that plugins are involved -- if you try to work with a project scaffolded with a particular set of plugins and aren't aware, things could go awry.

We might want to punt on that for later, though.

cmd/main.go

DirectXMan12

initial pass. A few questions. Doesn't look too bad. The ~~hacks~~ fancy footwork working around cobra doesn't make me feel warm and fuzzy inside, but that what's hot cocoa is for I guess.

pkg/cli/cli.go

DirectXMan12 · 2020-01-14T23:37:39Z

pkg/cli/cli.go

+// empty string and true. Otherwise, getBaseFlags returns the project version
+// and false.
+func (c CLI) getBaseFlags() (string, bool) {
+	fs := pflag.NewFlagSet("base", pflag.ExitOnError)


FYI, this logic yields "unknown flag: project-version" when we get to the main flag parsing logic. We prob want this defined on the main command too.

pkg/cli/create.go

pkg/plugin/plugin.go

DirectXMan12 · 2020-01-14T23:41:04Z

pkg/cli/init_project.go

+
+	// If only the help flag was set, return the command as is.
+	if isHelpOnly {
+		return cmd


doesn't this mean that a plugin doesn't get to modify help?

The intent with this was to handle kubebuilder init --help, in which case we could print out a general help. In this case, we don't know which plugin to use for help output.

Does this have something to do with the use of log.Fatal where you were using cdmErr and return in create api and webhook commands?

pkg/cli/webhook.go

pkg/cli/alpha.go

Adirio

Quite complete review: I requested some changes, suggested others, and asked some doubts. Hope it helps.

By the way, this needs a rebase as https://travis-ci.org/kubernetes-sigs/kubebuilder/jobs/635475321#L637-L644 was solved as a side effect of #1287 (more info in #1288) a couple weeks ago. The rebase will include multiple new lint checks aside from those that are already yielding errors in the current state (https://travis-ci.org/kubernetes-sigs/kubebuilder/jobs/635475321#L253-L350).

Adirio · 2020-01-22T07:52:47Z

pkg/cli/cli.go

+func New(opts ...Option) (*CLI, error) {
+	c := &CLI{
+		commandName:    "kubebuilder",
+		defProjVersion: project.Version2,


@DirectXMan12 Why do you want to upgrade to v3x? I think we can acheive this being fully compatible with v1 and v2 so we wouldn't need to upgrade to v3 as the scaffold won't be modified.

Adirio · 2020-01-22T07:57:53Z

pkg/cli/cli.go

+// Run runs the CLI.
+func (c CLI) Run() error {
+	return c.cmd.Execute()
+}


NIT: Is Run a good method name in this case? I would say that the user executes or runs a command but we are building the CLI. Some ideas (brainstorming): Build, Deploy, Make, Create, Generate, Finish, End. I think I like Deploy the most.

If not Run, Execute would make sense. The CLI isn't really deploying anything, ex. resources, it is a program that is running/executing.

pkg/cli/cli.go

pkg/plugin/plugin.go

pkg/cli/create.go

pkg/cli/webhook.go

pkg/plugin/util/util.go

pkg/plugin/v1/api.go

pkg/plugin/v1/init.go

pkg/plugin/v2/init.go

pkg/cli/cli.go

shawn-hurley · 2020-01-21T22:09:14Z

pkg/plugin/v1/plugin.go

+}
+
+func (_ Plugin) Version() string {
+	return "1"


Is anyone else concerned about versions as strings and the ability to put anything here?

I guess this could be a feature so you could do init --plugin Foo:Bar to have a composable set of plugins by "version" but the same overall plugin? If that is the use case maybe this is not a version field?

I think that may rise a lot of issues as we are expecting the default go plugin to exist for every version and using Bar as version would break that.

Version formatting and plugin composition go hand-in-hand, so we should follow up this PR with a discussion on both. For now we could enforce _, err := strconv.Atoi(p.Version()); err != nil.

yeah. I think for the moment: add a TODO for this, and we'll track them all down before final merge.

We can do the "move fast and break things" strategy on this branch.

shawn-hurley · 2020-01-22T13:46:40Z

Overall I think that this good

some points:

I think we need to discuss the version more.
We need an interface for CLI instead of a struct with hidden fields.

Want to see what folks think about the default for help will show the plugins that can be used as well as the default flags and such? Is that possible or is that already working and I just can't see it?

Adirio · 2020-01-22T22:50:08Z

@estroz merging Master wasn't the best idea IMHO. I think you need to rebase your branch to Master, 257 files changed, and 10k lines modified seem to be a bit too much.

estroz · 2020-01-22T22:54:12Z

@Adirio its because the target feature branch isn't up to date with master. It needs to be updated.

Adirio

its because the target feature branch isn't up to date with master. It needs to be updated.

Oh, right, you are not PR-ing against master. Reviewing right now is quite complex. Would it be better if we change the target branch to master until this is ready to ship, then update the current target branch to that point and swap again this PR to point to it?

Adirio · 2020-01-23T06:54:37Z

pkg/cli/alpha.go

 		Example: fmt.Sprintf(`
 # scaffolds webhook server
-%s alpha webhook <params>
-`, c.commandName),
+%s alpha webhook <params>`, c.commandName),


NIT: From an style point of view I may like more

Example: fmt.Sprintf( ` # scaffolds webhook server %s alpha webhook <params>`, c.commandName, ),

I feel like using backquotes vs \n helps visualizing how it will look like but messes with the indentation. At least in this case we only mess with the indentation of the text itself, the params are well indented.

P.S.: applies to several other parts of the code.

pkg/plugin/v1/init.go

pkg/plugin/v2/init.go

Adirio · 2020-01-23T07:11:08Z

pkg/plugin/v2/plugin.go

-	"sigs.k8s.io/kubebuilder/pkg/plugin/v1"
+	v1 "sigs.k8s.io/kubebuilder/pkg/plugin/v1"


I think this is because it expects packages v1 and v2 to be different versions of the pkg/plugin package. It made me think that we may want to include the plugin name in the package name, either pkg/plugin/govX or pkg/plugin/go/vX. The second will still be interpreted as a version but this time of pkg/plugin/go which would be technichally correct.

estroz · 2020-01-23T17:31:07Z

@Adirio if we can update the target feature branch with master, we should be ok since we don't need to merge CI fixes going forward. The only following merge will be your changes in #1325.

@DirectXMan12 @droot @mengqiy I don't have access to the feature branch. Can you merge it with master?

Adirio · 2020-01-23T19:44:24Z

The only following merge will be your changes in #1325.

I think that #1330 may also be a good idea to merge before, as it targets cmd package. Basically it is making the separation between cmd and pkg/scaffold clearer. This way I can keep working on enhancing the pkg/scaffold while the plugin system gets implemented without requiring too many rebases and conflict resolution from any of the two sides.

DirectXMan12 · 2020-01-27T16:06:13Z

Hey, sorry about that. I'll fast-forward as needed. Feel free to ping me on Slack if I'm not responding here.

DirectXMan12 · 2020-01-27T16:07:48Z

should be up-to-date now

DirectXMan12 · 2020-01-27T16:14:03Z

please do pull out the merge commit though

DirectXMan12 · 2020-01-27T16:43:58Z

approved or almost approved a couple of those PRs from @Adirio. LMK if there's another one blocking, but I think if we rebase on that we can probably merge this as a "here's a working step" and keep iterating.

Adirio

NITs: a function movement suggestion and some non-needed variables removals.

Otherwise, LGTM.

Adirio · 2020-02-09T09:52:13Z

cmd/main.go

-func main() {
-	if err := buildCmdTree().Execute(); err != nil {
-		log.Fatal(err)
+func loadExistingConfig() (*config.Config, error) {


What do you think about moving this to internal/config and calling it MustLoad?

The subcommands under plugin would also be able to use this function if we move it there.

Must implies that the function exits if the operation fails. Is this the behavior you intend MustLoad to have? Otherwise LoadExisting makes more sense.

Must usually means that errors will be handled with a panic, I guess another name could be better. But moving it there seems like a good thing to do.

pkg/cli/alpha.go

pkg/cli/cli.go

pkg/cli/create.go

camilamacedo86

IHMO: it still has a hall to changes and improvements. However, it will also easier to be done properly during and after the phase2 of its implementation. So, it shows ok for me to attend as first step the proposal made which is the goal of this PR.

@mengqiy @DirectXMan12 wdyt?

/lgtm

These changes are the implementation of concepts outlined in designs/extensible-cli-and-scaffolding-plugins-phase-1.md * cmd/: remove all but 'edit' and 'update' subcommands in favor of plugins that implement removed commands * internal/cmdutil: RunOptions configure Run() to execute a command in a generic manner * pkg/cli: CLI interface and cobra CLI constructors. Most commands from cmd/ were move here and modified to initialize plugins * pkg/plugin: Plugin and PluginGetter interfaces for v1 and v2 scaffolds. These are kubebuilider's base Go plugins consumed by pkg/cli.CLI

camilamacedo86 · 2020-02-15T17:06:35Z

@estroz @DirectXMan12.

Should not it be an issue in https://github.com/kubernetes-sigs/kubebuilder/projects/7? as well?
WDYT?
c/c @hasbro17

camilamacedo86

.

camilamacedo86 · 2020-02-20T11:48:13Z

/ok-to-test

camilamacedo86 · 2020-02-20T11:53:04Z

cmd/main.go

-	"sigs.k8s.io/kubebuilder/internal/config"
-	"sigs.k8s.io/kubebuilder/pkg/scaffold"
+	"sigs.k8s.io/kubebuilder/pkg/cli"
+	pluginv1 "sigs.k8s.io/kubebuilder/pkg/plugin/v1"


IHMO: We should not care about V1 since it is deprecated and should no longer be used.
Also, we need to remove the V1 code in order to keep things simple.
However, since it is already done in the PR we can merge with. 👍

Removing v1 may be easier after merging the feature branch with master. @DirectXMan12 @mengqiy thoughts on this? Regardless, out of scope for this PR.

Just to track here: We have a PR for that already: #1355

camilamacedo86 · 2020-02-20T11:59:08Z

pkg/cli/cli.go

+		c.projectVersion = projectConfig.Version
+	} else {
+		return fmt.Errorf("failed to read config: %v", err)
+	}


Just a nit. Suggestion ( I think make more clear when has an error and not what should be done )

if err != nil { if os.IsNotExist(err) { c.configured = false c.projectVersion = c.defaultProjectVersion } else { return fmt.Errorf("failed to read config: %v", err) } } else { c.configured = true c.projectVersion = projectConfig.Version }

This is less clear IMO.

camilamacedo86 · 2020-02-20T12:03:21Z

pkg/cli/api.go

+		tmpGetter, isGetter := p.(plugin.CreateAPIPluginGetter)
+		if isGetter {
+			if hasGetter {
+				err := fmt.Errorf("duplicate API creation plugins for project version %q: %s, %s",


Could not the API be called/used more than once to create different resources?

Each create command is associated with exactly one versioned plugin, otherwise plugin behavior can conflict. If you want to create more than one resource, call create api for each resource.

camilamacedo86 · 2020-02-20T12:05:27Z

pkg/cli/webhook.go

+		tmpGetter, isGetter := p.(plugin.CreateWebhookPluginGetter)
+		if isGetter {
+			if hasGetter {
+				err := fmt.Errorf("duplicate webhook creation plugins for project version %q: %s, %s",


Can we just use/call the webhook just once as well?

See my create api comment.

camilamacedo86

HI @estroz,

Just a few questions and nits, otherwise it shows ok for me as phase 1 and I still thinking that will be easier we check more changes and improvements after phase 2 and its implementations.

However, I have not seen the prow jobs called here. So, /lgtm cancel

Could you please check?

camilamacedo86 · 2020-02-20T12:16:48Z

/lgtm cancel

Adirio · 2020-02-20T13:01:28Z

However, I have not seen the prow jobs called here. So, /lgtm cancel

Could you please check?

This is being merged in a branch that is not Master and thus the tests are not being run.

DirectXMan12

really minor (non-blocking) nits. Fix them in a follow-up.

Are we doing the "layout" field in a follow-up?

/lgtm
/approve

DirectXMan12 · 2020-02-20T22:12:34Z

cmd/update.go

-		Run: func(_ *cobra.Command, _ []string) {
-			if err := run(options); err != nil {
+		Example: fmt.Sprintf(`	# Update the vendor dependencies:
+	kubebuiler update vendor`),


why is this still fmt.Sprintf

DirectXMan12 · 2020-02-20T23:17:13Z

pkg/cli/alpha.go

 	return &cobra.Command{
 		Use:   "alpha",
 		Short: "Expose commands which are in experimental or early stages of development",
 		Long:  `Command group for commands which are either experimental or in early stages of development`,
+		Example: fmt.Sprintf(`
+# scaffolds webhook server
+%s alpha webhook <params>`,


opposite side of same question here

DirectXMan12 · 2020-02-20T23:19:26Z

pkg/cli/api.go

+		),
+	}
+
+	// Lookup the plugin for projectVersion and bind it to the command.


is this comment correct any more?

k8s-ci-robot · 2020-02-20T23:35:29Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: DirectXMan12, estroz

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

The pull request process is described here

Needs approval from an approver in each of these files:

~~OWNERS~~ [DirectXMan12]

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

k8s-ci-robot requested review from joelanford, shawn-hurley, camilamacedo86 and DirectXMan12 January 8, 2020 23:23

k8s-ci-robot added the cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. label Jan 8, 2020

k8s-ci-robot requested a review from droot January 8, 2020 23:23

k8s-ci-robot added the size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. label Jan 8, 2020

estroz changed the title ~~feature: implement plugin proposal in #1250~~ [WIP] feature: implement plugin proposal in #1250 Jan 8, 2020

k8s-ci-robot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Jan 8, 2020

Adirio mentioned this pull request Jan 9, 2020

Hotfix for TRAVIS error introduced by #1016 #1288

Closed

joelanford reviewed Jan 9, 2020

View reviewed changes

DirectXMan12 requested changes Jan 14, 2020

View reviewed changes

Adirio mentioned this pull request Jan 21, 2020

Move configuration file related types and functions to separate package #1325

Merged

shawn-hurley reviewed Jan 21, 2020

View reviewed changes

pkg/cli/alpha.go Outdated Show resolved Hide resolved

Adirio suggested changes Jan 22, 2020

View reviewed changes

shawn-hurley reviewed Jan 22, 2020

View reviewed changes

Adirio reviewed Jan 23, 2020

View reviewed changes

estroz force-pushed the feature/plugins branch from 975a57e to 3045ba7 Compare January 27, 2020 18:58

joelanford mentioned this pull request Jan 30, 2020

Keep autogenerated code in separate package to increase code coverage reports operator-framework/operator-sdk#2467

Closed

hasbro17 mentioned this pull request Feb 2, 2020

Generate CLI completions for bash/zsh #1346

Closed

estroz force-pushed the feature/plugins branch from 420b194 to b35f34f Compare February 7, 2020 19:11

Adirio reviewed Feb 9, 2020

View reviewed changes

camilamacedo86 approved these changes Feb 10, 2020

View reviewed changes

k8s-ci-robot assigned camilamacedo86 Feb 10, 2020

k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Feb 10, 2020

estroz force-pushed the feature/plugins branch from a3c93fe to 358a9f6 Compare February 13, 2020 16:13

k8s-ci-robot removed the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Feb 13, 2020

estroz mentioned this pull request Feb 20, 2020

Feature Request: Plugins Phase 2 #1378

Closed

camilamacedo86 approved these changes Feb 20, 2020

View reviewed changes

k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Feb 20, 2020

k8s-ci-robot added the ok-to-test Indicates a non-member PR verified by an org member that is safe to test. label Feb 20, 2020

camilamacedo86 reviewed Feb 20, 2020

View reviewed changes

camilamacedo86 requested changes Feb 20, 2020

View reviewed changes

k8s-ci-robot removed the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Feb 20, 2020

DirectXMan12 approved these changes Feb 20, 2020

View reviewed changes

k8s-ci-robot assigned DirectXMan12 Feb 20, 2020

k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Feb 20, 2020

k8s-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Feb 20, 2020

k8s-ci-robot merged commit e322071 into kubernetes-sigs:feature/plugins-part-2-electric-boogaloo Feb 20, 2020

This was referenced Feb 21, 2020

kubernetes-sigs/kubebuilder: update presubmit config with plugins feature branch matching kubernetes/test-infra#16411

Merged

plugins: validate project and plugin versions #1380

Merged

		"sigs.k8s.io/kubebuilder/pkg/plugin/v1"
		v1 "sigs.k8s.io/kubebuilder/pkg/plugin/v1"

feature: implement plugin proposal in #1250 #1290

feature: implement plugin proposal in #1250 #1290

Conversation

estroz commented Jan 8, 2020 • edited Loading

k8s-ci-robot commented Jan 8, 2020

Choose a reason for hiding this comment

estroz Jan 10, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Adirio Jan 22, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

DirectXMan12 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Adirio left a comment • edited Loading

Choose a reason for hiding this comment

Adirio Jan 22, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

estroz Jan 22, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

shawn-hurley commented Jan 22, 2020

Adirio commented Jan 22, 2020

estroz commented Jan 22, 2020

Adirio left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Adirio Jan 23, 2020 • edited Loading

Choose a reason for hiding this comment

estroz commented Jan 23, 2020

Adirio commented Jan 23, 2020

DirectXMan12 commented Jan 27, 2020

DirectXMan12 commented Jan 27, 2020

DirectXMan12 commented Jan 27, 2020

DirectXMan12 commented Jan 27, 2020

Adirio left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

camilamacedo86 left a comment

Choose a reason for hiding this comment

camilamacedo86 commented Feb 15, 2020

camilamacedo86 left a comment • edited Loading

Choose a reason for hiding this comment

camilamacedo86 commented Feb 20, 2020

camilamacedo86 Feb 20, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

camilamacedo86 Feb 20, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

camilamacedo86 left a comment • edited Loading

Choose a reason for hiding this comment

camilamacedo86 commented Feb 20, 2020

Adirio commented Feb 20, 2020

DirectXMan12 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

k8s-ci-robot commented Feb 20, 2020

estroz commented Jan 8, 2020 •

edited

Loading

estroz Jan 10, 2020 •

edited

Loading

Adirio Jan 22, 2020 •

edited

Loading

Adirio left a comment •

edited

Loading

Adirio Jan 22, 2020 •

edited

Loading

estroz Jan 22, 2020 •

edited

Loading

Adirio left a comment •

edited

Loading

Adirio Jan 23, 2020 •

edited

Loading

camilamacedo86 left a comment •

edited

Loading

camilamacedo86 Feb 20, 2020 •

edited

Loading

camilamacedo86 Feb 20, 2020 •

edited

Loading

camilamacedo86 left a comment •

edited

Loading