Release kn as a kubectl plugin

[cardil]

Feature request

To drive knative adoption, I think it would be beneficial to release kn, also as a plugin for kubectl. That would serve as additional installation way for many users. A lot of them have krew installed on their machines. If we release kn to krew plugin registry, installing kn would be as simple as running:

$ kubectl krew install kn

Use case

Searching

Users could easily find knative by doing various searches:

$ kubectl krew search serverless
NAME      DESCRIPTION                                       INSTALLED
kn        CLI for Knative - modern serverless workloads     no

$ kubectl krew search knative
NAME      DESCRIPTION                                       INSTALLED
kn        CLI for Knative - modern serverless workloads     no

Installing

Easy and cross-platform install

$ kubectl krew install kn

Upgrading

krew updates all installed plugins:

$ kubectl krew update

Users can also upgrade a single plugin as well

$ kubectl krew update kn

[rhuss]

neat idea, and I think we should support theoretically all installations mechanism of kn that make sense (also e.g. chocolatey or rpms).

However, my concerns are:

• Adding an additional command level does not improve the user experience
• The command model of kn ( ) is different than that of kubectl ( ). When using this with the same tool, that might confuse user (e.g. they would try to use kubectl kn describe revision because they can do kubectl get revision).
• There is a notable overlap between kubectl and kn when CRUD managing Knative resources (you can do that with both tools)
• If it is only about installing kn via a package management system, I think we should focus on tools that do exactly and only this. No need to plump into kubectl.
• The general option syntax for kn (e.g. for logging) is different for kn and kubectl.
• kn's plugin mechanism wouldn't work with this as e.g. kn-event would now have to be named kubectl-kn-event. And the detailed resolution plugins is different, like being able to hook into subcommand. E.g. when using a kn-service-log plugin, this would not appear on the list of kubectl kn service --help)

My general take is, if you target kubectl as a plugin you should align with kubectl's UI, otherwise is not intuitive to use it (see the verb vs. noun) ordering, and I'm afraid people are more frustrated because of the different user experience. Mentally having different top-level CLIs the mental switch is easier.

In the future, we could think about having a dedicated knative kubectl plugin that leverages a client API (that, that we plan to put into knative/client-pkg and which is aligns better with the kubectl design principles.

tl;dr - IMO the benefits don't not justify the drawbacks, so I'm -1 for now.

[cardil]

I've double-checked a couple of plugins listed here: https://krew.sigs.k8s.io/plugins/ and I haven't found any alignment between those plugins and kubectl itself. Each one seams to have a completely separate command model, not connected to kubectl at all. I'm not seeing any similarities between them. Could you point out some examples @rhuss? And, even if there are plugins that follows kubectl in some way, does that means kn needs to do it as well? I don't think so.

Secondly, could you elaborate why exactly kn plugins can't work with that? I've done this simple test, and it looks like it works just fine:

$ cd ~/bin
$ ln -s $(command -v kn) kubectl-kn
$ kubectl kn version
Version:      v0.21.0
Build Date:   2021-05-31 17:01:15
Git Revision: 1ceb5318
Supported APIs:
* Serving
  - serving.knative.dev/v1 (knative-serving v0.21.0)
* Eventing
  - sources.knative.dev/v1alpha2 (knative-eventing v0.21.0)
  - eventing.knative.dev/v1beta1 (knative-eventing v0.21.0)
$ kubectl kn plugin list
- kn-event : /home/ksuszyns/.config/kn/plugins/kn-event
- kn-func : Function plugin

[rhuss]

Could you point out some examples @rhuss?

no, not really (don't use many of them), but I guess most of them use an as the first argument, aren't they? My hope is that for kn plugins we can achieve seamless a UI integration, ideally, it should not even be detectable by a user whether they are using a builtin command or a plugin. From a user's POV a plugin is 'just another command'.

And, even if there are plugins that follows kubectl in some way, does that means kn needs to do it as well?

yes, because of the cognitive load that different command schemes put on the user when using the same tool. That's my opinion at least.

Secondly, could you elaborate why exactly kn plugins can't work with that? I've done this simple test, and it looks like it works just fine:

I mean, how would you install kn plugins ? Also with krew ? But wouldn't this only work if they are called eg kubectl-kn-event ? And then called by the kubectl plugin system and not the kn plugin system (which has this mentioned subtle differences).

If we can't install kn plugins with krew but need to copy them over manually or use brew, then I don't see the point of installing kn with krew but not the plugins.

[cardil]

because of the cognitive load that different command schemes put on the user when using the same tool

I see krew purely as an installation way. Most of the krew plugins do that. They all have their scope. I don't see any valid reason why should we care to align with kubectl, if we decide to publish plugin to krew index.

I mean, how would you install kn plugins ?

No, let's not confuse two different things. We currently don't have plugin management infrastructure. It should be addressed separately from this (see #1386 for that).

I strongly believe we shouldn't publish all plugins to krew/brew/flatpak/snap/whatever. That's just dirty, and we would be asking for trouble, even if that would be possible (maintainers could easily block us doing just that). kn installation isn't the same as kn plugins installation.

If we decide to implement proper plugin management, like #1386 describes for example, then we can support many ways (rpms, debs, snap, flatpak, brew, krew etc.) of installing kn itself. kn plugins will work in all of them.

[github-actions]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.

[cardil]

/reopen
/remove-lifecycle stale

[knative-prow-robot]

@cardil: Reopened this issue.

In response to this:

/reopen
/remove-lifecycle stale

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.

[github-actions]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.

[cardil]

/reopen
/remove-lifecycle stale

[knative-prow]

@cardil: Reopened this issue.

In response to this:

/reopen
/remove-lifecycle stale

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.

[github-actions]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.