Uninstall

Removing Olympusx AI happens in stages, each less reversible than the one before. Stopping after the first is the normal case: it takes the platform down and keeps everything it recorded.

Remove a Helm install

1. The workloads (reversible)

helm uninstall olympus -n olympus

This removes every workload the chart created, its Services, the Ingress or Routes, the NetworkPolicies and the ServiceAccounts. It does not remove the Secrets you created (the master key, the pull secret, the backup and relay credentials), the namespace, or the database.

Reinstalling with the same values and the same master key restores the platform as it was; the migration step finds the schema current and does nothing.

2. The namespace (reversible only if the master key is stored elsewhere)

kubectl delete namespace olympus

This deletes your in-cluster copy of the master key. If the database survives and no copy of the key exists elsewhere, the credentials sealed in it cannot be recovered by anyone.

3. The data (irreversible)

With the bundled database, Olympusx AI owns the data, and the two stages above behave differently:

helm uninstall leaves the database’s PersistentVolumeClaim behind, so a reinstall picks the data up again, provided you still hold the master key.
Deleting the namespace deletes the claim, and the database with it. Every tenant, key, usage record, statement and audit entry goes, with no copy anywhere.

Take a dump before you go near either:

kubectl -n olympus exec olympus-postgresql-0 -- \
  sh -c 'PGPASSWORD="$POSTGRESQL_PASSWORD" pg_dump -U olympus olympus' \
  > olympus-final.sql

With the managed database, the instances are olympus-db-1, olympus-db-2 and olympus-db-3, and the application credentials are in the Secret olympus-db-app. Your archive in the backup bucket outlives the namespace; delete it there when your retention allows.

With your own database and cache, nothing above touches them. To remove the data:

DROP DATABASE olympus;
DROP ROLE olympus;

The cache holds only cached authorization decisions, budget counters and leases; the durable record is in the database. Once the workloads are gone, so nothing is mid-write, flush the cache database the platform used: database 0, unless the cache URL in your Secret names another.

Then destroy your copies of the master key. Until you do, it can still open any backup taken while the platform ran.

Remove an operator install

Order matters: the platform first, while its operator still runs, then the operator. Reversed, the platform resource can never be deleted (the trap).

1. The platform

kubectl -n olympus delete olympuses.olympus.olympusx.ai olympus
kubectl get olympuses.olympus.olympusx.ai -A
# No resources found

Do not continue while it still lists: the operator’s finalizer is removing the platform’s cluster-wide roles. Every namespaced object is collected, and so is the cluster registration credential the platform made for itself.

With database.mode: managed, this deletes the database. With a backup destination you can recover from the archive into a new install (Backup and restore); without one, the data is gone.

The Secrets you created stay in the namespace. Delete the namespace when you no longer need them, after storing the master key elsewhere.

2. The subscription

kubectl -n operators delete subscription olympus-operator

On OpenShift the namespace is openshift-operators. This only stops OLM upgrading the operator; the operator keeps running.

3. The operator

kubectl -n operators delete csv olympus-operator.v<version>

This removes the operator’s Deployment, its ServiceAccount, and its roles and bindings. Two groups of cluster roles stay behind, with nothing owning them. Delete them if the operator is not coming back:

kubectl delete clusterrole,clusterrolebinding -l olm.owner=olympus-operator.v<version>

kubectl delete clusterrole --ignore-not-found \
  olympuses.olympus.olympusx.ai-v1-{admin,edit,view,crdview} \
  modeldeployments.olympus.olympusx.ai-v1-{admin,edit,view,crdview}

Your shell expands {admin,edit,view,crdview} into four names; bash and zsh both do. Check what is left:

kubectl get clusterrole,clusterrolebinding | grep -i olympus

4. The CRDs

kubectl delete crd olympuses.olympus.olympusx.ai modeldeployments.olympus.olympusx.ai

This deletes every resource of those kinds in every namespace, including the ModelDeployment resources in tenant namespaces and the model workloads they own. It cannot be undone.

5. The catalog

kubectl -n olm delete catalogsource olympus-operators

On OpenShift the namespace is openshift-marketplace. Leave it in place if the operator is coming back: it costs one polling pod and keeps the tile in the Software Catalog.

6. Tenant namespaces

The platform creates namespaces for tenants’ projects, models and vector databases. They are labelled with their tenant:

kubectl get namespaces -l olympus.olympusx.ai/tenant

Delete those, and olympus-serving, olympus-vectordb and olympus-model-import if they exist, unless something you keep runs in them.

The trap: removing the operator first

If you delete the operator’s ClusterServiceVersion while an Olympus resource still exists, the resource can never be deleted: the controller that runs its finalizer is gone. kubectl delete still reports success and exits 0. The object stays, marked for deletion, and the namespace will not delete either.

Put the operator back: apply the catalog and the Subscription again. The operator reinstalls, sees the resource marked for deletion, runs its cleanup, and the resource disappears.

Do not remove the finalizer by hand. That deletes the resource and orphans the platform’s cluster-wide roles and bindings, with nothing left to explain them.