Uninstalling from Canonical OpenStack Sunbeam

This page covers removing T4O 6.2.1 from a Canonical OpenStack Sunbeam cloud (trilio-wlm-k8s, trilio-dm-api-k8s, trilio-data-mover-sunbeam) — see Trilio Installation on Canonical OpenStack (Sunbeam) for the matching install procedure.

Remove components in the order given below, verifying each step before continuing to the next.

Backup data already written to your NFS or S3 backup target is never affected by any step in this procedure — T4O does not delete backup-target content when its charms are removed. The workload and backup-target metadata held in T4O's own databases is a separate matter, addressed in the optional Step 6 below.

Do not use --force on any removal. A forced removal skips the charms' own teardown hooks. On the control plane it can leave the trilio-wlm-k8s StatefulSet behind, which blocks a later reinstall until it is deleted by hand, and it can leave unrelated Sunbeam applications in an error state on their own relation-departed hooks. Let each removal complete on its own before starting the next.

A unit stuck in an error state blocks removal. Juju will not retire an application while one of its units has a failed hook. Clear it with juju resolved --no-retry <unit> before retrying the removal. The --no-retry flag matters: plain juju resolved re-runs the failed hook, and if that hook fails again the removal stays blocked indefinitely.

juju remove-application always prompts for confirmation before doing anything. When running it over SSH or from a script — anywhere without an interactive terminal to answer that prompt — include --no-prompt, or the command aborts immediately with ERROR application removal: aborted and nothing is removed. Every command below already includes it.

Prerequisites

• Juju CLI access to the Sunbeam controller, with both the openstack (Kubernetes) and machine models reachable. Confirm the machine model's exact name with juju models before starting — some Sunbeam environments require the owner-qualified form (e.g. admin/openstack-machines) rather than a bare openstack-machines.

• kubectl access to the openstack namespace (on Canonical Kubernetes, this is typically sudo k8s kubectl, not a bare kubectl).

• For Step 6 only: MySQL root credentials (via the mysql charm's get-password action), RabbitMQ access via rabbitmqctl inside the rabbitmq unit, and OpenStack admin credentials (via the keystone charm's get-admin-account action).

Steps to uninstall the Trilio charms

1. Remove the control plane

Removes trilio-wlm-k8s and trilio-dm-api-k8s from the openstack model.

juju switch openstack
juju remove-application trilio-wlm-k8s trilio-dm-api-k8s --destroy-storage --no-prompt

--destroy-storage removes Juju storage volumes owned directly by these two applications. trilio-wlm-k8s and trilio-dm-api-k8s declare no storage of their own, though — they are stateless, and all workload/backup-target metadata lives in the separate mysql application's own storage. This flag therefore does not delete the WLM or DataMover-API databases; see Step 6 if you want those removed as well.

If you intend to redeploy later and keep existing backups usable, back up the workloadmgr database first (Step 6 shows how to reach it) — it is left untouched by this step regardless.

Verify:

juju status trilio-wlm-k8s trilio-dm-api-k8s
# Both applications should report as not found. This can take a minute
# or two to fully clear; if it still shows Scale 3/0 with units
# "Terminating", that is normal in-progress teardown -- wait and re-check.

kubectl get pods -n openstack | grep trilio
# No output -- all pods terminated.

2. Remove the data plane

Removes trilio-data-mover (the subordinate DataMover/DMS application) from the machine model.

juju switch openstack-machines
juju remove-application trilio-data-mover --destroy-storage --no-prompt

Verify:

juju status trilio-data-mover
# Application should report as not found.

Confirming the compute-node services are actually gone requires the manual cleanup in Step 3 below — removing the Juju application does not stop or uninstall anything on the compute node's underlying OS.

3. Clean up compute-node services and packages

Required on every compute node. Removing trilio-data-mover leaves its systemd services and apt packages installed and running; once the relation is torn down, their RabbitMQ/Keystone credentials are deleted, so both services enter a continuous failure loop until stopped. Run the following via Juju for every openstack-hypervisor/<N> unit (check juju status openstack-hypervisor for the full list):

juju ssh openstack-hypervisor/<N> -- sudo systemctl stop triliovault-datamover triliovault-dms
juju ssh openstack-hypervisor/<N> -- sudo systemctl disable triliovault-datamover triliovault-dms
juju ssh openstack-hypervisor/<N> -- sudo apt-get purge -y python3-tvault-contego python3-trilio-dms python3-s3-fuse-plugin
juju ssh openstack-hypervisor/<N> -- sudo systemctl daemon-reload

apt-get purge does not remove the log directory these services wrote to either. Clean it up separately:

juju ssh openstack-hypervisor/<N> -- sudo rm -rf /var/log/triliovault

This is distinct from /var/log/juju/unit-trilio-data-mover-<N>.log, which Juju itself always preserves for a removed unit on its machine, for any application — not Trilio-specific, and not something this procedure removes.

Optional: remove the Trilio apt repository source file added during install. Confirm its exact filename first rather than assuming one:

juju ssh openstack-hypervisor/<N> -- ls /etc/apt/sources.list.d/ | grep -i trilio
juju ssh openstack-hypervisor/<N> -- sudo rm -f /etc/apt/sources.list.d/<confirmed-filename>
juju ssh openstack-hypervisor/<N> -- sudo apt-get update -qq

Verify:

juju ssh openstack-hypervisor/<N> -- systemctl is-active triliovault-datamover triliovault-dms
# Should print "inactive" for both, on every compute node.

juju ssh openstack-hypervisor/<N> -- test -d /var/log/triliovault && echo "still present" || echo "removed"
# Should print "removed", on every compute node.

4. Remove the Horizon plugin

Reverts Horizon to its pre-Trilio image, removing the Trilio dashboard plugin. Two ways to determine which image to restore, in order of preference.

Option A — Restore the saved pre-Trilio baseline (preferred, if captured)

If horizon-baseline.yaml was captured at install time, use its saved image directly instead of a live Charmhub lookup — this guarantees an exact revert to the image Horizon had before Trilio touched it, regardless of how much time has passed or whether Canonical has since published newer horizon-k8s resource revisions on the channel.

# 1. Read the saved baseline to fetch pre_trilio_image-from-baseline
cat triliovault-cfg-scripts/sunbeam-canonical/horizon-baseline.yaml

# 2. Check Horizon's currently-running image
kubectl get pod -n openstack horizon-0 -o jsonpath='{.spec.containers[?(@.name=="horizon")].image}'
echo

# 3. Re-attach the saved pre-Trilio image
juju attach-resource horizon horizon-image=<pre_trilio_image-from-baseline>

Option B — No saved baseline exists (fallback)

If no baseline file was captured at install time (e.g. an install performed before this practice was adopted), fall back to Charmhub's current published default for the channel:

# 1. Find the currently-deployed charm revision
juju status horizon -m openstack
# note the Rev column

# 2. Look up that revision's default horizon-image resource on Charmhub
curl -s 'https://api.charmhub.io/v2/charms/info/horizon-k8s?channel=2024.1/stable&fields=default-release.resources,default-release.revision' \
  | python3 -m json.tool
# find the "horizon-image" resource entry's "upstream-source" field
# (nested inside the "metadata-yaml" text, not a top-level field of the
# resource entry itself)

# 3. Re-attach that stock image
juju attach-resource horizon horizon-image=<upstream-source-from-step-2>

For example, for horizon-k8s revision 289 on the 2024.1/stable channel, the resolved image was ghcr.io/canonical/horizon:2024.1-24.04_edge, giving:

juju attach-resource horizon horizon-image=ghcr.io/canonical/horizon:2024.1-24.04_edge

Option B always restores whichever image is Charmhub's current default for horizon-k8s's channel at the time cleanup runs — not necessarily the exact image Horizon had before Trilio was installed, since Canonical publishes horizon-k8s resource updates on its own schedule, independent of Trilio. Prefer Option A whenever a baseline is available.

Verify on every unit, since each rolls over to the new image at a different time:

for p in horizon-0 horizon-1 horizon-2; do
  kubectl exec -n openstack $p -c horizon -- \
    python3 -c 'import trilio_dashboard; print(trilio_dashboard.__file__)'
done
# Each should fail with: ModuleNotFoundError: No module named 'trilio_dashboard'

juju status horizon -m openstack
# All units active/idle.

5. Remove cross-model offers (optional)

If the rabbitmq or keystone-credentials offers were created specifically for T4O, and nothing else consumes them, they may be removed:

juju switch openstack
juju remove-offer rabbitmq:amqp
juju remove-offer keystone-credentials:identity-credentials

Leave the offers in place if you are unsure. An unused offer is harmless, but removing one that another application still consumes will break that application. Before removing anything, confirm what else is connected:

juju status -m openstack-machines --relations

Check the "Integration provider" section for any rabbitmq:amqp, keystone-credentials:identity-credentials, or cert-distributor:send-ca-cert relation pointing at an application other than Trilio's — these offers are frequently shared with Sunbeam's own core services (e.g. openstack-hypervisor for Nova, cinder-volume for Cinder). If any such relation exists, do not remove that offer.

6. Remove residual database, message queue, and identity resources

Optional. Because --destroy-storage in Step 1 does not reach the mysql application's own storage, the WLM and DataMover-API databases, their MySQL users, associated RabbitMQ vhosts, and the Keystone service catalog entries, endpoints, and cloud-admin trust are all left behind by Steps 1–5. This step removes them. Skip it entirely if leaving these inert resources behind is acceptable.

Dropping the databases below is destructive and irreversible — it permanently deletes all workload and backup-target metadata (which backups exist, their schedules, etc). It does not affect backup data on your NFS or S3 target. If you may reinstall and want existing backups to remain usable, skip the MySQL portion below (back up the workloadmgr database first if you want a safety copy).

MySQL — leftover databases and users:

juju switch openstack
juju run mysql/leader get-password

kubectl exec -n openstack mysql-0 -c mysql -- mysql -uroot -p'<password>' -e \
  "DROP DATABASE IF EXISTS workloadmgr; DROP DATABASE IF EXISTS dmapi; \
   DROP USER IF EXISTS 'charmed_dba_workloadmgr_00'@'%'; \
   DROP USER IF EXISTS 'charmed_dba_dmapi_00'@'%';"

RabbitMQ — leftover vhosts (their users are cleaned up automatically, but the vhosts themselves are not):

kubectl exec -n openstack rabbitmq-0 -c rabbitmq -- rabbitmqctl delete_vhost workloadmgr
kubectl exec -n openstack rabbitmq-0 -c rabbitmq -- rabbitmqctl delete_vhost dmapi

Keystone — leftover service catalog entries, endpoints, and the cloud-admin trust created during install:

juju run keystone/leader get-admin-account
# use the resulting openrc / OS_* values below, with --insecure for a
# self-signed certificate

openstack --insecure trust list
openstack --insecure trust delete <trust-id>   # confirm the ID before deleting

openstack --insecure service delete dmapi
openstack --insecure service delete TrilioVaultWLM
# deleting a service also removes its associated endpoints

Keystone — leftover identity (service) users. openstack user list on its own only shows users in the domain your current auth is scoped to (here, admin_domain, which holds only admin) — it does not list all users across all domains. Trilio's own service accounts live in a separate service_domain, so they stay invisible unless that domain is named explicitly:

openstack --insecure user list --domain service_domain

This surfaces (alongside the other OpenStack services' own accounts, svc_nova-*, svc_cinder-*, etc., which are not Trilio's and must not be touched):

svc_trilio_wlm_k8s-<suffix>       # trilio-wlm-k8s's own service account
svc_trilio_dm_api_k8s-<suffix>    # trilio-dm-api-k8s's own service account
datamover                         # trilio-data-mover's own service account

svc_trilio_wlm_k8s is the trustee on the cloud-admin trust created during install (trustor: admin) — confirm this by checking the trust's Trustee User ID matches this user's ID before deleting either. Delete both together, or neither; deleting the trust independently of the user (or vice versa) can leave a dangling reference:

openstack --insecure trust show <trust-id>   # confirm Trustee User ID
openstack --insecure user delete svc_trilio_wlm_k8s-<suffix>
# (the trust itself is deleted separately, above, via `trust delete`)

svc_trilio_dm_api_k8s and datamover have no such dependency and can be removed independently:

openstack --insecure user delete svc_trilio_dm_api_k8s-<suffix>
openstack --insecure user delete datamover

Verify:

kubectl exec -n openstack mysql-0 -c mysql -- mysql -uroot -p'<password>' -e "SHOW DATABASES;"
kubectl exec -n openstack rabbitmq-0 -c rabbitmq -- rabbitmqctl list_vhosts
openstack --insecure service list
openstack --insecure trust list
openstack --insecure user list --domain service_domain
# should show only the other OpenStack services' own accounts (svc_nova-*,
# svc_cinder-*, svc_glance-*, svc_neutron-*, svc_placement-*, horizon,
# cinder-volume, openstack-hypervisor) -- no svc_trilio_* or datamover entries

Verification Summary

After Steps 1–4 (the mandatory path):

• juju status in both models shows no trilio-wlm-k8s, trilio-dm-api-k8s, or trilio-data-mover applications

• kubectl get pods -n openstack | grep trilio returns nothing

• triliovault-datamover and triliovault-dms are inactive on every compute node

• python3-tvault-contego, python3-trilio-dms, and python3-s3-fuse-plugin are not installed on any compute node

• /var/log/triliovault does not exist on any compute node

• trilio_dashboard fails to import on every Horizon unit

After Step 6 (optional, destructive):

• no workloadmgr/dmapi databases or users remain in MySQL

• no workloadmgr/dmapi vhosts remain in RabbitMQ

• no dmapi/TrilioVaultWLM services, endpoints, or admin trust remain in Keystone

• no svc_trilio_wlm_k8s, svc_trilio_dm_api_k8s, or datamover users remain in Keystone's service_domain