Katello ships a katello-remove script, but I’d argue that with the current tools we have make it so easy to create a new machine that it’s easier to create a new one than it is to clean up an old one. From a development point of view it saves us from keeping it up to date, especially when we’re refactoring deployments.
My proposal is to deprecate it with Foreman 1.23 / Katello 3.13.
From a dev standpoint, it is a bit of a PITA to maintain but it definitely has value for our users.
Sadly not all environments are easy to re-provision a host to start over and can often take days waiting to get a fresh host available to re-install. I’d vote we keep it, even if it does take periodic updates to ensure the removal actually gets rid of everything.
What is the value for the users? Do they want to reuse the server for another application or want to start with a fresh Katello installation? If it’s the latter then I’d argue that foreman-installer --scenario [katello|foreman-proxy-content] --reset is the one we should be investing in.
Imho it is the problem of the users’ environments if it takes so long to deploy a new host.
So my vote is “drop it”
they want to re-install Katello and Foreman from scratch with either the same or a different version when unable to re-provision the target host. The installer --reset flag resets data but has no effect on the set of installed RPMs or starts from a completely clean slate.
For installed RPMs I’d say it’s easier to remove the yum repositories and go over yum list extras. Then remove any .rpmsave files. If you want a fresh install, use --reset on the next installer run.
So I think the problem is twofold:
The script currently lives inside of packaging, and by that quite disconnected from the places where the real changes happen – the RPMs can be removed quite easily even without the script, just yum history undo, the installer bits/configs/data is the interesting part.
On the other hand problems are only really detected after release, which requires a z-stream to get the fixes to the user.
I think I’d be much happier if we would move the script to some other git repository, not ship it in the RPMs and tell the users to fetch the latest copy from git if they really need that functionality.