Proposal: Categorize kubectl plugins

[ishantanu]

Hi,

While I was going through the kubectl krew search command, I saw that the plugins are not currently categorized. For now, since the number of plugins in krew is not quite large (52 plugins, to be precise, correct me if I am wrong here), searching the plugin is not a big issue. But, on a longer run, I think categorizing the plugins could be a nice idea.

For example here are a few possibilities:

1. Category RBAC which will include plugins related to RBAC like access-matrix, rbac-lookup, rbac-view.

2. Category Execution which might include plugins like exec-as, iexec, cssh, ssh-jump.

3. Category Networking which might include plugins like sniff.

If the categorization is done, users can search for plugins in specific categories as well. A possibility here is: kubectl krew search -c/--category RBAC which will only list plugins belonging to RBAC category.

I can understand that the categorization of each and every plugin can be a daunting task. But I think, in the longer run, it will make krew more organized. A key for Category can also be added to the plugins.yaml file so that the plugin developers themselves can categorize their plugins.

The adoption of this idea largely depends on what the krew community thinks krew should do.

I also see that, if (a big IF) the idea of categorization gets approved, it will include considerable changes in krew including but not limited to:

1. Adding flags to krew CLI
2. Defining categories
3. Validating new plugins to see if they belong to a valid category
4. Requesting existing plugin devs to categorize the plugins which are already part of krew.

This idea sprung up when I was thinking of readability issues users might face when browsing awesome-kubectl-plugins. A quick search filtered by Category can significantly reduce the time it will take for users to find the right plugin (should the plugins ecosystem keep growing in the future).

[corneliusweig]

Yes, I think categories or keywords is a good idea. It has been proposed before (https://github.com/kubernetes-sigs/krew/issues/26#issuecomment-509596127, https://github.com/kubernetes-sigs/krew/issues/26), but we got stuck in the nitty-gritty details. It turns out fuzzy search or keyword search is not so simple to get right (also see https://github.com/kubernetes-sigs/krew/pull/150).

The first step in that direction would be to write a design document where we can discuss various approaches, but also define the use-cases that we are aiming to solve.

[ahmetb]

Worth noting: We don't know if categorization is a krew problem or krew-index problem. For the private index maintainers, adding a feature like this ideally not add a burden.

I'm currently -1 for categories but +1 for keywords. Other package managers usually don't categorize things, as it's usually a different concern.

We can do something like metadata.annotations, and use that to categorize what's listed in krew-index/plugins.md.

[ishantanu]

Other package managers usually don't categorize things, as it's usually a different concern.

But, is krew really trying to be a package manager? 🤔

Besides, if we are comparing krew with package managers like apt, then ubuntu does have keyword search by UI - https://packages.ubuntu.com/.

Also, for keywords. Would it be possible to specify multiple keywords for a single plugin?

For example, access-matrix plugin can have keywords like rbac and access-control. If multiple keywords can be specified for one plugin, then, how do we limit the number of keywords that can be specified? My question is, do we have a sort of dictionary that mentions only valid keywords that can be specified in the plugin?

In a longer duration, if there is no set of valid keywords, then the number of different keywords can expand vastly which is not really beneficial for the user since they would have to know the keywords first to search the kind of plugin they expect.

So, if we define a concise set of keywords which can be specified for a plugin and make them searchable, how is that different from categorizing them? In the end, all we are doing is to define a set of keywords/categories. The only difference I see is of multiple keywords (if that is going to be possible). And if it is, I am not sure what benefit it will bring instead of specifying a single category (or let's say keyword).

Keywords or category or anything else, what I am trying to propose is something like this:

NAME	DESCRIPTION	STATUS	KEYWORD(S)/CATEGORY
access-matrix	Show an RBAC access matrix for server resources	available	RBAC
auth-proxy	Authentication proxy to a pod or service	available	Authentication

❯ k krew search -k/-c RBAC
NAME                           DESCRIPTION                                        STATUS
access-matrix                  Show an RBAC access matrix for server resources    available

Imagine having more than 100s of plugins and the user having to go through a lot of plugins only to discover rbac-view (since plugin names are alphabetically sorted). Best case scenario, if the plugin which the user is looking for starts with an a or z. Worst case, the plugin starts with letters like k,l,m because the plugin neither comes first from the beginning or from the end.

I am not sure if greping the keywords in kubectl krew search's output would be a good idea either. The correctness of the results could be debatable.

[ahmetb]

I think categories and tags are nearly the same thing. A plugin might belong to one or more.

Now, mainly my hesitation is that we need to solve this in a way that helps krew-index, but it's not required when we allow people to host their own indexes (either on github publicly, or within a private corporate environment). Ideally, we should not require/force a plugin to have a category.

[fejta-bot]

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.

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

[corneliusweig]

/lifecycle frozen We do want this at some point.