Repository navigation
Implement option to uninstall Stacks and Demos #187
Description
Comment with more information on the deletion status/process: #187 (comment)
Update after a discussion on 2025-11-26:
In case, a user wants to try out a demo and uninstall it afterwards, it should be documented, how to do this. stackablectl should provide an option for it.
- All resources with a Stackable label should be removed, including the data (PersistentVolumes). That means that all top-level resources, which are not (indirectly) owned by a Stackable labeled resource, must be labeled accordingly, e.g. the namespace a demo is installed in.
- Demos and stacks should be installed in the non-default namespace.
- External tools like PostgreSQL in the demo/stacks namespace will therefore also be removed.
- The first version of this removal "tool" shows a warning and provides no option to be less destructive and keep resources.
Initial description:
As a user
I want to be able to uninstall a stack or demo by itself, after I'm done looking at it
to have a clean cluster again and not have to remove things manually, which is error prone.
- What should be uninstalled, should operators be left behind?
- What about multiple stacks in the same namespace? What about shared things like a ZooKeeper in two stacks. we could try and have only one ZK and label it as being part of two stacks, in a sort of dependency tree.
- Should a demo be always in a dedicated namespace? Deleting a namespace will not delete cluster-scoped resources
- What about removing Redis/Postgres etc. that is part of a demo?
- What about data? I.e. PVCs? maybe there could be
uninstallvspurgeandpurgealso removes data. - What about cluster scoped resources? How do we make sure they do not comflict with each other?
Removing
- some Manifests need to be deleted
- Helm stuff needs to be uninstalled (i.e. Postgres)
Related ADR: https://docs.stackable.tech/home/stable/contributor/adr/adr031-resource-labels
Random unrelated code dump, do not execute :P
#!/usr/bin/env bash
set -euo pipefail
CONTEXT=$(kubectl config current-context)
CLUSTER=$(kubectl config view -o jsonpath="{.contexts[?(@.name==\"$CONTEXT\")].context.cluster}")
echo "You are about to run a destructive operation"
echo "Current kube context : $CONTEXT"
echo "Current cluster : $CLUSTER"
echo
read -r -p "Do you want to continue? (y/N): " CONFIRM
if [[ "$CONFIRM" != "y" && "$CONFIRM" != "Y" ]]; then
echo "Aborted."
exit 1
fi
echo "Continuing..."
kubectl delete ns stackable-operators || true
kubectl get crd -o name | grep stackable | xargs kubectl delete || true
kubectl delete --all pvc || true
Activity
[-]Research option to uninstall Stack[/-][+]Research option to uninstall Stacks and Demos[/+]sbernauer commentedon Aug 12, 2022
Just dropping a comment i send in slack for reference
adwk67 commentedon Aug 12, 2022
Here's a note from the same slack chat:
fhennig commentedon Apr 20, 2023
I had some thoughts on this:
Closing my other ticket in favor of this one #186
Maleware commentedon Apr 20, 2023
I went through some stacks and demos and figured out some issues:
I just realised that if we have a demo in a namespace and then throwing it away with k delete namespace there are some leftovers on the cluster in:
This stuff is preventing to throw away a namespace, create a new one and install another demo on it.
As a solution (having open shift in mind):
This will give the user the freedom to install a demo or stack in certain ns, throw it away and install the next demo. Additionally this gives us the capability to install various demos in different namespaces on one cluster.
I'm aware this feels like a
stackablectl demo uninstalllight, but by doing this we can avoid cleaning up each and every resource and just reuse them. Another thing solved by this, is that you currently can't kill a stack or demo by just simply delete the namespace it's in. As long as pvc's are attached to a pod, the secret operator is mandatory to kill those pods.Maleware commentedon Apr 20, 2023
On another note:
Since I'm testing the capabilities of stackablectl and the usage of stacks atm, I realised that we have monitoring and logging as stacks available. However, if you install any stack before you are not able to install any other stack besides that. I think since we have now meta features like logging and monitoring we should be able to install them via sctl easy and fast.
As far as I can see, another advantage of installing operators in their own ns is that we have this enabled out of the box too.
soenkeliebau commentedon Apr 20, 2023
Is it new that we cannot install another stack beside an existing one?
I regularly installed the datalake demo and then afterwards did
sctl s in loggingandsctl s in monitoringto get those features as well.Maleware commentedon Apr 20, 2023
That's a good comment! Haven't found this in the documentation yet! But it looks like... it works :)
I think it is not working if you try installing it in another namespace as far as I can see
soenkeliebau commentedon Apr 20, 2023
That might create issues, yes... the vector aggregator service for example would not resolve for the pods in a different namespace I think ..
Maleware commentedon Apr 20, 2023
Yes, this in addition. However, you can not install another stack in a seperate namespace since sctl gives you an error like this:
soenkeliebau commentedon Apr 20, 2023
Ah, so the issue there is that it tries installing the release again .. might be useful to have a switch "--skip-release" to install just the stack and demo portions, for clusters that were pre-installed with a release.
Maleware commentedon Apr 21, 2023
Ah! That's a way easier solution then I had in mind.
Techassi commentedon Aug 4, 2023
This will be possible when #79 is merged.
12 remaining items
[-]Research option to uninstall Stacks and Demos[/-][+]Implement option to uninstall Stacks and Demos[/+]lfrancke commentedon Feb 16, 2026
@xeniape and I had a followup meeting and decided:
xeniape commentedon Mar 11, 2026
As mentioned in stackabletech/hdfs-operator#761 (comment) added the requirement of non-default namespaces for demo/stack installation back in.
-> Related PR: stackabletech/demos#374
xeniape commentedon Apr 16, 2026
Release Note
stackablectl demo uninstall/stackablectl stack uninstall. Caution: This deletes the demo / stack namespace, uninstalls the Stackable operators and CRDs and deletes the Stackable operator namespace. If only the demo / stack should be removed, but not the Stackable operators / CRDs, use the--skip-operators-and-crdsflag in the uninstall command.--assume-yes/--yes/-yflag can be used.