Proposal: Add support for internal plugins

[rhuss]

kn provides a plugin architecture that allows calling to external commands via a naming convention (much like kubectl). This proposal suggests a small modification in kns plugin handling algorithm to allow also to include golang-based plugins internally plugins so that are compiled together with kn and that implements a Plugin golang interface. The required changes are implemented in PR #902.

Use Cases

Allowing to package plugins together with kn during build-time allows for an easy distribution mechanism with a single binary, so a plugin package management (like krew for kubectl) is not needed. It also allows third-parties to provide value-add by maintaining a curated set of plugins and align them dependency-wise so that they can be compiled together.

kn itself is agnostic of the underlying platform and only uses the endpoints that the Knative API defines. However, a vast majority of Knative installations run on Kubernetes, so having Kubernetes specific functionality implemented as kn internal plugins that integrate seamlessly into the given command structure is valuable for Knative Kubernetes users.

Examples of such Kubernetes specific plugins:

• kn admin for managing the Knative configuration
• kn service log for showing the Knative logs

Additionally, inlining plugins for managing Event Sources also helps in creating a better user and installation experience:

• kn source kafka for managing a Kafka source
• kn source github likewise, for a GitHub source

Scope

This proposal suggests only to offer the infrastructure for allowing such tight integration. Creating custom distributions of kn is out of scope for this proposal and left to third-parties. The integration must be minimally intrusive and not conflict with externally managed plugins.

From UX perspective, inlined plugins (as well as externally managed plugins) should integrate seamlessly into the command structure of the builtin commands so that from a user's POV there is no notable difference between built-in commands and plugins (i.e. the should appear on the same help pages as the commands and also follow the same CLI conventions for subcommand and option names).

Code & Examples

• PR 902 which implemented the lookup and management of internal plugins via a global slice to which plugins can add to via their init() method.
• kn service log plugin that uses this implementation
• Demo [5:34] which shows the kn service log plugin used as an external and internal plugin.

[rhuss]

Closing as dup that happens because of the GitHub outage this morning.