Typo in Knative Quickstart

[rupipal]

The command should be kn-quickstart (hyphen to be included) in the step "Install Knative and Kubernetes on a local Docker Daemon using..." under section 'Install the Knative "Quickstart" environment.' Here, https://knative.dev/docs/getting-started/ .

[JeffNeff]

/assign

[psschwei]

While the binary is named kn-quickstart, kn quickstart should work if (1) you're using v0.25 of the kn client, and (2) the kn-quickstart binary is on your PATH. @rupipal is that not working for you?

[rupipal]

Hi @psschwei It didn't work for me. Following https://github.com/knative-sandbox/kn-plugin-quickstart/blob/release-0.3/README.md , the first thing I did was to try by placing it in ~/.config/kn/plugins. So I placed it in/usr/local/bin, which is already on the PATH as kn-quickstart. And my client kn version is v0.25.

[psschwei]

Couple of questions to help debug further:

• What error message did you see?
• What does kn plugin list show?
• What operating system are you using?

[rupipal]

Hi Paul,

Thank you for taking it up.

I am using Debian 11 Bullseye.

I'v tried to reproduce whatever had happend. By repeating.

With the executable kn-quickstart in ~/.config/kin/plugins,

kn plugins list does show this plugin as placed. So, when I run kn quickstart kind,

Running Knative Quickstart using Kind
✅ Checking dependencies...
Kind version is: kind v0.11.1 go1.16.4 linux/amd64

Error: creating cluster: existing cluster: check cluster: exit status 1
Usage:
kn-quickstart kind [flags]

Flags:
-h, --help help for kind

creating cluster: existing cluster: check cluster: exit status 1
Error: exit status 1

To be sure, I did,

$ sudo kn quickstart kind
[sudo] password for rupinder:
Error: unknown command "quickstart" for "kn"
Run 'kn --help' for usage

Clearly, that points me to expected usage. And of course, I took a quick look at [ https://github.com/knative/client/releases https://github.com/knative-sandbox/kn-plugin-quickstart/blob/release-0.3/README.md] too. These instructions doen't require that ~/.config/kin/plugins be placed on PATH too. And so, next, I placed it in /ur/local/bin as named kn-quickstart. And as I shared earlier, it works as we would load with shell. That is,

$kn-quickstart kind

It does so even if it is named quickstart. So,

$quickstart kind

I think what is happening is. Based on [ https://github.com/knative/client/blob/v0.25.0/CHANGELOG.adoc https://github.com/knative/client/pull/1422 https://github.com/knative/client/pull/1412 ]. In v0.25, they've deprecated plugin.path-lookup property of the client kn and enabled lookupPluginsInPath by default to make kn plugins behave as system-wide brew plugins as well. By even requiring ~/.config/kin/plugins to be on the PATH. It seems, it might not work in this manner for one who didn't install brew way ( brew install knative-sandbox/kn-plugins/quickstart) and/or doesn't use MacOS ( I'm sorry I am not aware if this system-wide plugins thing is available on GNU/Linux and could not find as well in this time.) So,at least, the README needs to be updated.

[psschwei]

Thanks for the response @rupipal .

I am using Debian 11 Bullseye.

I haven't run the plugin on Debian, but I can't think of any reason why that should cause any issues. I

I'v tried to reproduce whatever had happend. By repeating.

With the executable kn-quickstart in ~/.config/kin/plugins,

kn plugins list does show this plugin as placed.

Ok, this is good. That means that the plugin is being recognized by up by the kn client.

So, when I run kn quickstart kind,

Running Knative Quickstart using Kind
white_check_mark Checking dependencies...
Kind version is: kind v0.11.1 go1.16.4 linux/amd64

Error: creating cluster: existing cluster: check cluster: exit status 1
Usage:
kn-quickstart kind [flags]

Flags:
-h, --help help for kind

creating cluster: existing cluster: check cluster: exit status 1
Error: exit status 1

This looks like an error when checking if there was an existing Kind cluster on your machine. Basically, we're running kind get clusters -q to get a list of clusters. No idea what would cause this to fail, especially as it worked when you ran just the binary. But it's a separate issue from the name/location of the plugin.

To be sure, I did,

$ sudo kn quickstart kind
[sudo] password for rupinder:
Error: unknown command "quickstart" for "kn"
Run 'kn --help' for usage

This makes sense, as /home/<user>/.config/kin/plugins won't be on the PATH for root.

Clearly, that points me to expected usage. And of course, I took a quick look at [ https://github.com/knative/client/releases https://github.com/knative-sandbox/kn-plugin-quickstart/blob/release-0.3/README.md] too. These instructions doen't require that ~/.config/kin/plugins be placed on PATH too.

Yeah, we missed updating this section when we did the release. We got the update in this morning. The proper workflow should be to add the plugin to any directory on your PATH.

And so, next, I placed it in /ur/local/bin as named kn-quickstart.

Just to confirm, did this work?

And as I shared earlier, it works as we would load with shell. That is,

$kn-quickstart kind

It does so even if it is named quickstart. So,

$quickstart kind

That is really strange that it works when running the binary directly but not via the kn client.

I think what is happening is. Based on [ https://github.com/knative/client/blob/v0.25.0/CHANGELOG.adoc https://github.com/knative/client/pull/1422 https://github.com/knative/client/pull/1412 ]. In v0.25, they've deprecated plugin.path-lookup property of the client kn and enabled lookupPluginsInPath by default to make kn plugins behave as system-wide brew plugins as well. By even requiring ~/.config/kin/plugins to be on the PATH. It seems, it might not work in this manner for one who didn't install brew way ( brew install knative-sandbox/kn-plugins/quickstart) and/or doesn't use MacOS ( I'm sorry I am not aware if this system-wide plugins thing is available on GNU/Linux and could not find as well in this time.) So,at least, the README needs to be updated.

That's right, the newest release of the kn client (v0.25) defaults to looking for plugins on the PATH, so there's no need to use the ~/.config/kn/plugins directory anymore. I've tested this on both Mac and Linux (Fedora 34), and per your comments it seems to be working for you too (finding the plugin that is).

So, a couple more steps to troubleshoot. Can you run kind get clusters -q, then try the plugin again (kn quickstart kind), and post the full output of both commands here?

[rupipal]

Hi Paul,
Thanks for your response.

I think running kn plugins list doesn't show kn recognizes a particular plugin. I haven't taken a look at the kn code; it is merely throwing up the list of plugins from ~/.config/kin/plugins because it has that property plugin.path-lookup (deprecated but not not disabled; it should lead kn to the list; something like that). For it to recognize a particular plugin, it should execute that plugin when its name is supplied as 1st argument on the command (here kn quickstart ) for a particular task that is specified as a 2nd argument (e.g. kn quickstart kind). Something like that. If this is not happening on my Debian 11 installation, it could/might be some other thing, but the fact is that the plugin is a full executable.Yes, it runs when placed in /usr/local/bin.

$ kn-quickstart
Get up and running with a local Knative environment running on KinD.

Usage:
kn-quickstart [command]

Available Commands:
completion generate the autocompletion script for the specified shell
help Help about any command
kind Quickstart with Kind
version Prints the plugin version

Flags:
-h, --help help for kn-quickstart

Use "kn-quickstart [command] --help" for more information about a command.

That ouput shows it works standalone. It works and sets up a cluster called knative with namespace and sets up hello-world service that works and as per that knative quickstart. And I have deleted and again set up the cluster many times. The cluster works and sets up a kubernetes API server at an endpoint.

I'm a bit short on time today; travelling outstation shortly. Will post those two outputs on Friday or Saturday.

[rupipal]

Hello Paul,

Wait a sec :). It does work in /usr/local/bin like kn quickstart kind too. But with sudo. I think I didn't try sudo in the first few attempts. Here,

$ sudo kn quickstart kind
[sudo] password for rupinder:
Running Knative Quickstart using Kind
✅ Checking dependencies...
Kind version is: kind v0.11.1 go1.16.4 linux/amd64

Knative Cluster kind-knative already installed.
Delete and recreate [y/N]: n

Installation skipped

🍿 Installing Knative Serving v0.25.0 ...
CRDs installed...
Core installed...
Finished installing Knative Serving
🕸️ Installing Kourier networking layer v0.25.0 ...
Kourier installed...
Ingress patched...
Kourier service installed...
Domain DNS set up...
Finished installing Kourier Networking layer
🔥 Installing Knative Eventing v0.25.0 ...

So, that system-wide plugins thing (that is installing plugins in /usr/local/bin ) seems normal behaviour on Linux too. But all this points, to as tried to I explain earlier, quickstart seems to be a full executable and not merely a binary (e.g. a Java class loaded by an executing code). If I am correct, this is not uncommon for a plugin, unless we want it to behave merely as a binary.

[psschwei]

It does work in /usr/local/bin like kn quickstart kind too. But with sudo.

Hmm, that sounds like it might be the permissions on the file (?).

So, that system-wide plugins thing (that is installing plugins in /usr/local/bin ) seems normal behaviour on Linux too. But all this points, to as tried to I explain earlier, quickstart seems to be a full executable and not merely a binary (e.g. a Java class loaded by an executing code). If I am correct, this is not uncommon for a plugin, unless we want it to behave merely as a binary.

Yes, that's right. Plugins for the kn client are standalone executable files, whose names begins with kn-. This is pretty much the same as how plugins work with kubectl (other than the file prefix :) ).

[rupipal]

Hi @psschwei Thanks. I think, for me, the issue seems settled. It may be closed.

[psschwei]

Hi @psschwei Thanks. I think, for me, the issue seems settled. It may be closed.

@omerbensaadon @csantanapr ^^^

[snneji]

No changes needed. Closing this issue.