Write uninstall script

[LindsayHill]

We should have a script that uninstalls ST2 (as much as possible).

It will undo the changes made by the install scripts.

It will not be able to fully cope with distributed installations, but should cope with a single-system install.

It should include removing all packages, repos, configs, DBs, and RabbitMQ.

Obviously script should prompt the user "are you really sure?" etc etc.

[arm4b]

I'm 👎 for any uninstallers since there is a big danger in removing packages or altering configurations user might need for other software in a system.

• Add here complexity when ideally we should store some state of installed software before/after installation, configuration state for every file we modify and the diff of it.
• Add here dependency resolution issues when uninstalling 1 package will also uninstall another that could be installed by user for some reason.
• Add here cases when nginx or any similar package might be configured to be used by something else in a system.
• Add here that we should also support/test that script in CI on every e2e test.
• And after all the complexity added to the installer, - this still would be very error-prone.

Overall I think that "uninstaller" would be a not that important feature to have and waste of resources considering it's flaky nature.

If someone doesn't need StackStorm after installing it, - just use a new clean VM or Docker approach with isolation so user can stop Docker containers and remove the images, having host system in initial state.

[Kami]

I agree with @armab - it's a hard to do it well and correctly and these days, imo, unnecessary (vms / cloud server / containers are cheap).

[LindsayHill]

If someone doesn't need StackStorm after installing it, - just use a new clean VM or Docker approach

and these days, imo, unnecessary (vms / cloud server / containers are cheap)

So...the future is here, it's just not evenly distributed. Internally, we're used to just spinning up new instances, that's the way we roll. But in the cold hard reality of modern Enterprise IT, it can take weeks or months to get a new VM. Network engineers are not able to provision their own VMs, they need to go through internal processes. Depending on political relationships, this can be very easy, or it can take a long time.

People continue to treat VMs as pets, installing some software on them, later removing it and installing different packages. This is because it is "easier" for them to keep using the VM they have, rather than get a new one.

There are two reasons people need to uninstall ST2:
1/ They tried to install ST2 and it failed for some reason. Install script doesn't allow re-run, and our advice has been 'get a new VM.' They can't get a new VM, so they are looking for a way to reset the system, so they can re-run the installer.
2/ They don't want to use ST2 anymore, and want to use that VM for something else 😿

The first use-case is the more common one. We can get away with not having an uninstall script if we can make the installation idempotent, and better able to handle re-run after failed install. Do that, and most of the need will go away.

For the uninstall use-case, at a minimum we should publish guidance on what is required to uninstall ST2. 'Modern' SREs don't need it, but there are a lot of people out there who operate their environments using more traditional practices, and they expect to see guidance on how to uninstall a system.

No, it won't be able to cope with all scenarios, dependencies, etc. But if someone knows that they have customized NGINX because they're also using it for something else, then they will cope with instructions that say "remove nginx". For people that have not done any additional customization, or are not highly experienced sysadmins, they will be able to follow those instructions to get their system back to a state where ST2 is no longer installed & running.

If the Customer Thinks It’s Broken, It’s Broken