Closed jar349 closed 1 year ago
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.
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.
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.
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:
Oh, I thought, I'll go over and reset the node from the master....
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 notrestart
. I made assumptions about what reset did without consulting the documentation first. And the documentation is very clear about whatreset
does.But:
microk8s.stop && microk8s.start
told me to run reset and it's 4am and I'm tired and just listened.microk8s.reset
command didn't cause it to failI very strongly suggest that:
microk8s help
just lists the commands and none of the subcommands have help)