#1250
#519
#653

So essentially you'd expect that k0s reset would also remove the k0s binary too?

or k0s uninstall

The difference is that get.k0s.sh is not the actual installer, it's just a download script for the current arch+os binary that you might use as an installer or for runring k0s without installing. Maybe it shouldn't put it into /usr/local/bin in the first place.

I would actually prefer removing k0s install completely because it's weird. #770 (comment)

sounds like we dont get this done this time either. this is the third issue on the subject. it always sidetracks.

like this is obvious to the almighty k0s team that "its just a single binary"

but when a user runs a script snippet which does something it is not obvious what gets written and where.

providing k0s uninstall would be a statement from the almighty k0s team that "whatever we decide to write in your filesystem, running this will now AND in future remove"

please don't sidetrack this issue again in diskutering klubben, but actually implement this promise.

Maybe workaround is something like k0s reset && rm $(which k0s)...

Logically k0s uninstall should undo what k0s install did.

I made a PR for the get-script that creates an uninstaller that looks like:

#!/bin/sh
rm -f /usr/local/bin/k0s $0

The installer then says:

$ cat get.k0s.sh | sudo sh
Downloading k0s from URL: https://github.com/k0sproject/k0s/releases/download/v1.25.3+k0s.0/k0s-v1.25.3+k0s.0-amd64
k0s is now executable in /usr/local/bin
- to remove k0s, run /usr/local/bin/remove-k0s.sh

Feels a bit silly as it could just say to remove k0s run rm /usr/local/bin/k0s instead of creating that script. Of course it could do something more in a future scenario where get.k0s.sh does something else that needs undoing.

Maybe it should check if k0s is running and refuse to remove in that case. It's already starting to make sense! :)

This is a bit repetitive, but it still remains valid: The get.k0s.sh script is just a glorious curl wrapper for a single binary download. Everything else (installation / reset) is done by k0s itself. They are completely separated from each other. This is very different from get.k3s.io, which really does install stuff and is way more complex:

$ curl -sSLf https://get.k0s.sh | wc
     57     121    1140

$ curl -sSLf https://get.k3s.io | wc
    930    3269   27922

What would be the user expectation around a remove script? Probably "wipe k0s from the machine, no traces left behind". Well, that is not so easy, since this would require some sort of integration between k0s install and the remove script. The current proposal is simply undoing what get.k0s.sh did. But: If the user installed k0s via k0s install (something that get.k0s.sh doesn't do), the remove script will leave a broken installation behind, which is surely not a good thing. A more sophisticated remove script could try to detect if k0s has been installed and remove (a.k.a reset) it accordingly, but in order to do this, it needs to know the k0s data directory that has been used during k0s install. Just assuming the default would probably not be a good idea either.

I'm kinda opposed to add it in the currently proposed way. It will just add up to the whole confusion.

Moreover, I don't think this discussion sidetracked. Thing is that uninstallation just doesn't fit into the scope of get.k0s.sh, since it doesn't do the install in the first place. It just "get"s the binary. If folks are concerned about the things that get.k0s.sh does, I'd probably just give the advice to use curl directly, so they are in full control of what happens.

Recently I have been in touch with people from confidential containers and having k0s uninstall service would help them to support k0s out of the box during the installation process or at least way to find proper service to modify it manually.
And it kinda makes sense to me, we already have logic to find a service file and detect init system, why not to reuse it.

Moreover, I don't think this discussion sidetracked. Thing is that uninstallation just doesn't fit into the scope of get.k0s.sh, since it doesn't do the install in the first place.

Maybe it shouldn't install it into /usr/local/bin because that is kind of "installing".

It could output the payload to stdout for redirecting:

$ curl get.k0s.sh | sh 
Error: stdout is a terminal, you don't want to see all that garbage on screen. Use redirect / pipe.
$ curl get.k0s.sh | sh > k0s
Downloading from foofoo.....
$ chmod +x k0s
$ ./k0s version
v1234567.8.9+k0s.0

It could write it to a specified path:

$ curl get.k0s.sh | sh -- -o /tmp/k0s
Downloading from foofoo to /tmp/k0s .....
Checking /tmp/k0s ....
Success, k0s is now executable in /tmp/k0s

It could copy the bin to default location and run k0s install or maybe run a worker?:

$ curl get.k0s.sh | sh -- install controller --single --data-dir /tmp --enable-cloud-provider
Downloading from foofoo to /usr/local/bin/k0s .....
Checking /usr/local/bin/k0s ....
Success, k0s is now executable in /usr/local/bin/k0s
Running k0s install controller --single --data-dir /tmp --enable-cloud-provider ...

$ curl get.k0s.sh | sh -- worker # invent some clever way to pass token
...
Running k0s worker ...

k0s reset could by default rm self, you could use k0s reset --no-delete to keep the bin. Or there could be a separate k0s reset and k0s uninstall, the latter would be rm self with a check for need for reset.

I'd propose something like k0s reset --remove so when reset runs the last step would be rm self

if this will be implemented one day - please don´t forget /opt/cni/ if this was also installed by k0s

please don´t forget /opt/cni/ if this was also installed by k0s

Created separate issue for that, see #2852 .

any progress vor cleanup? BTW will the systemd unit removed as well?

And very often I get a message that k0s reset can not talk to the socket

BTW will the systemd unit removed as well?

k0s reset will remove that as well.

And very often I get a message that k0s reset can not talk to the socket

@hwinkel would you mind filing a separate issue for this?