Reset command needs a confirmation

[jar349]

Until a few minutes ago, I had a sizable cluster deployment running a few dozen things here at home. I was investigating why kubelet wasn't garbage collecting snapshots and following this issue which contained advice for reconfiguring kubelet and then stopping and starting microk8s.

After configuring kubelet, I ran:

$ microk8s.stop && microk8s.start
This MicroK8s deployment is acting as a node in a cluster. Please use the microk8s stop on the master.
This MicroK8s deployment is acting as a node in a cluster. Please use the microk8s reset on the master.

Oh, I thought, I'll go over and reset the node from the master....

$ microk8s.reset kube-node-2
Disabling all addons.
Disabling addon : ambassador
Disabling addon : cilium
Disabling addon : dashboard
Disabling addon : dns
... snipped

And just like that, a cluster I had been managing for over a year went up in smoke. My kid's minecraft server with months of progress. My LDAP server. My mySQL database. All the persistent storage... gone.

It's my own fault. reset is clearly not restart. I made assumptions about what reset did without consulting the documentation first. And the documentation is very clear about what reset does.

But:

• the output of microk8s.stop && microk8s.start told me to run reset and it's 4am and I'm tired and just listened.
• the fact that I passed a node name to the microk8s.reset command didn't cause it to fail
• the command to completely wipe everything out never bothered to ask if I was certain I wanted to torch everything

I very strongly suggest that:

• confirmation be added to the reset command.
• the microk8s command have vastly improved help (microk8s help just lists the commands and none of the subcommands have help)

[ktsakalozos]

I understand your frustration and appreciate your calmness.

In https://github.com/ubuntu/microk8s/pull/1750 we try a few fixes based on your feedback. Your exact suggestions will need a bit more time to implement.

Apologies for the inconvenience we caused.

[nullptr0000]

Is there any progress on adding an actual confirmation step or switch to the reset command?

It seems to be an incredibly bad piece of design and implementation - student project level - to have a command that will completely destroy a deployment including any persistent parts labelled as something innocuous as 'reset' and to then not back it up with at least a minimum of at least one 'are you sure you really want to do this?' step.

You can't leave a nuke lying around and not at least put a cover (and a proper label) on the big red button.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.