kn plugin management

[cardil]

Feature request

I think kn CLI should provide an easy way to manage and discover plugins for itself. By this, I think of adding a couple of sub commands to kn plugin.

My idea for this is to rely on container images as transport layer. I imagine a kn to have configurable list of plugin index images, by default equal to (can be configured by kn config command):

{
  "default": "gcr.io/knative-releases/knative.dev/client/plugins-index"
}

Such container image will contain just a file database (format TBD, SQLite maybe?!? YAML files?!?) of plugins metadata. We can set up this in the way that every PR merge to repo like https://github.com/knative-sandbox/client-plugins will build and publish new index image, so users will see new content.

This index database will contain information such as plugin name, version, container image, description, maturity level, keywords as well as previous releases of given plugin.

Using the information in such index container, the kn plugin search will perform its operations, as well as kn plugin install

Such operation is cross-platform, and don't rely on any external tooling to be installed on user's machine (see: github.com/containers/image/v5 as example implementation).

Use cases

• As a kn CLI user, I would like to discover, install and remove plugins easily
• As a corporate kn CLI user, I would like to publish, discover and install my own kn plugins in addition to upstream ones
• As a knative vendor, I would like to publish productized plugins for knative

UI Examples

Searching plugins

$ kn plugin search event
NAME   DESCRIPTION                            VERSION  MATURITY  PLATFORM
event  Build, send & listen to cloud events   v0.3.0   alpha     amd64

Installing plugins from index

$ kn plugin install event
INFO Downloading event plugin
Using tag: v0.3.0
latest: Pulling from gcr.io/knative-releases/knative.dev/client/plugins/event:v0.3.0
fdd5d7827f33: Pull complete
a3ed95caeb02: Pull complete
Digest: sha256:e7d38b3517548a1c71e41bffe9c8ae6d6d29546ce46bf62159837aad072c90aa
Status: Downloaded newer image for gcr.io/knative-releases/knative.dev/client/plugins/event:v0.3.0
INFO Installing event plugin
INFO Plugin event successfully installed. Call: `kn event --help`!

Installing custom plugins (Ad hoc)

NOTE: by configuring custom plugin index, vendors and corporate users can utilize previous method as well.

$ kn plugin install costsavings --image=registry.example.org/kn-plugin/costsavings
INFO Downloading costsavings plugin
Using latest tag: latest
latest: Pulling from registry.example.org/kn-plugin/costsavings:latest
546ce46bf621: Pull complete
7d38b3517548: Pull complete
Digest: sha256:d0b2326c74911ac7a3cb5a2775fc6b696371557751ab004a8d13a7998027c518
Status: Downloaded newer image for registry.example.org/kn-plugin/costsavings:latest
INFO Installing costsavings plugin
INFO Plugin costsavings successfully installed. Call: `kn costsavings --help`!

Updating single plugin

$ kn plugin update event
INFO Updating event plugin
Using tag: v0.3.1
latest: Pulling from gcr.io/knative-releases/knative.dev/client/plugins/event:v0.3.1
a471bb98a512: Pull complete
fdd5d7827f33: Already exists
a3ed95caeb02: Already exists
Digest: sha256:6a117897d88659e22b221ea420af5953f1b2b97e70560e39369dd0193c39808b
Status: Downloaded newer image for gcr.io/knative-releases/knative.dev/client/plugins/event:v0.3.1
INFO Installing event plugin
INFO Plugin event successfully updated.

Updating all installed plugins

$ kn plugin update
INFO Updating all installed plugins
INFO All plugins are now up-to-date.

Removing installed plugin

$ kn plugin remove event
INFO Plugin event has been removed.

[cardil]

/kind proposal

[lionelvillard]

This is interesting. An alternative proposal is to incorporate krew as an kn plugin. I think 99% of the krew code can we reused (things like where is the index needs to be changed). The index is just a GitHub repo (can be private/enterprise), so adding a new plugin is equivalent to opening a PR.

[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]

/remove-lifecycle stale

[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]

/remove-lifecycle stale

I like @lionelvillard idea of reusing krew as well. Either should support all use cases I've listed.

[cardil]

I think using krew has the downside of being harder to productize. We already do the disconnected installations with container images, by mirroring the registries.

If we choose to go with krew path, the vendors would essentially need to provide their own download service to work in disconnected installations, that could be mirrored, and will serve krew index, and plugin downloads.

Am I right, @lionelvillard?

[lionelvillard]

@cardil I think so, though I'm not sure I understand what you mean by to work in disconnected installations. Do you mean GitHub is not reachable?

[cardil]

Yes. The disconnected installation may range in meaning, but essentially, we should be able to operate in the network of limited or no external connectivity.

[lionelvillard]

ok, just making sure we are on the same page.

the vendors would essentially need to provide their own download service

backed by git: https://krew.sigs.k8s.io/docs/developer-guide/custom-indexes/

I wonder how hard it would be to extend krew to support OCI registries. Maybe fork krew, replace git by container registry and call it kn plugin ...?

[cardil]

That maybe a good idea. We could propose to change the krew to operate on container images instead of git repositories. That could make krew much more "cloud native" IMHO (the container images are easier to handle, mirror, etc.).

[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]

/remove-lifecycle stale

[rhuss]

An FT Knative Catalog has been opened to hold the metadata that plugin management commands could leverage. Maybe not directly, but I can imagine some automatic job that would create a single plugin descriptor file that this downloadable for a central place that a kn plugin search could leverage.