Would one possible approach be to migrate a lot of the logic from kubectl into self-sufficient modules in something like pkg/client/tools?

@ghodss That's along the lines of what I was thinking, yes.

The commands should take interfaces directly for their type specific behavior (Reaper, etc) when specific code is required per type. Those interfaces should be provided by the factory to the cobra initializers, but the Run behavior should take generic options.

An example from Openshift: https://github.com/openshift/origin/blob/master/pkg/cmd/cli/cmd/request_project.go - flag and argument handling is distinct from execution.

On Apr 24, 2015, at 5:35 PM, Brian Grant notifications@github.com wrote:

Too much kubectl business logic resides in pkg/kubectl/cmd. I'd like essentially all of kubectl to be callable as a library, and functionality like run-container and rolling-update should be configurable declaratively, as well.

Some of the logic (stop #1535, resize #1629, rolling-update #1743) belongs on the server side, too, but that's a separate issue.

An example that's close:
https://github.com/GoogleCloudPlatform/kubernetes/blob/master/pkg/kubectl/run.go
No mention of cobra, no flags, no reading files/URLs/etc.

Additional changes I'd like to run.go include accepting its config as an object and/or json (rather than the simple array), and moved to a more generic client directory/package. For generators specifically, we need some sort of plugin mechanism and/or should just make them into simple services (#5280).

Examples that don't obey this principle:

updateWithPatch: https://github.com/GoogleCloudPlatform/kubernetes/blob/master/pkg/kubectl/cmd/update.go#L122
RunRollingUpdate: https://github.com/GoogleCloudPlatform/kubernetes/blob/master/pkg/kubectl/cmd/rollingupdate.go#L67
Additionally, for declarative updates (#1702), it needs to be possible to specify the update policy in json, accompanying the objects to be updated.

At a glance, pkg/client/clientcmd looks like it respects the separation that we should strive for.

Related: Clients shouldn't be using the internal rep. #3955 #4874 -- only apiserver and kubelet should be using it. Even our controllers should only be using the latest stable API version.

Internally our command-line tool grew more and more functionality, and it became very hard to tease apart. Applications were linking in essentially the whole tool (flags and all) just to use specific bits of it, such as to take a list of objects and send them to the API.

Of course, these principles should be documented somewhere. (Related, but not identical to #6797)

@smarterclayton @lavalamp @ghodss @jlowdermilk @deads2k @ironcladlou @brendandburns @thockin @erictune

—
Reply to this email directly or view it on GitHub.

See also #12143 re. functionality that should move server-side.

@bryk ok, get it.

@jwforres how do you feel about this? I'm thinking new-app and a few
specific flows. How might you use this in Openshift console?

I thought this issue was about creating composeable command objects for clean re-use (our complete, validate, run methods) and #12143 was about moving the client-side logic server-side.

We are probably also going to want to split generic API functionality from Kubernetes-specific API resource types, as we try to make the API machinery more generic and reusable.

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

/remove-lifecycle stale
/lifecycle frozen

I think, we have run a long way to achieve this decoupling and it is time to close this issue. If there is any, we can track the work in a new issue.

/close

@ardaguclu: Closing this issue.