Uninstall Policy

Remove Policy workloads while keeping recoverable data, or explicitly delete approved storage and the dedicated namespace.

Use this task as the platform operator to remove Policy. Choose Option A to keep data, or Option B to remove it. Helm removal does not withdraw policies from receiving products.

Before You Begin

Complete these prerequisites before uninstalling:

Complete or resolve pending publication and withdrawal with the policy owner. Follow publication and withdrawal recovery.
Verify a backup checkpoint when you need recovery. Preserve database credentials and required signing state separately.
Confirm the release, namespace, and removal window with the platform owner. These examples use release policy in namespace pty-policy.
Keep recoverable backups and credentials until you verify the chosen outcome.

Set the approved cluster context before running commands:

export CTX='your-approved-kubernetes-context'
kubectl --context "${CTX:?Set CTX to the approved context}" cluster-info
helm --kube-context "$CTX" --namespace pty-policy status policy

Confirm that the cluster and release match your removal request. Stop if either identity differs or remains uncertain. If Helm reports no release, confirm the prior uninstall in your change record. Then use Option B only after verifying ownership of the remaining resources.

Option A: Uninstall and Keep Data

To uninstall while retaining the data, follow these steps:

Record the release values and storage identities in your approved change record.
```
helm --kube-context "${CTX:?Set CTX}" --namespace pty-policy get values policy
kubectl --context "$CTX" --namespace pty-policy get pvc -o wide
```
Record each claim, backing volume, chart version, and running image identity. Retain the three database usernames, their credential references, and the recovery plan. Do not copy secret values into the change record.
Confirm that no publication or withdrawal still requires the Policy workers. Archive acceptance alone does not prove completed removal. If protection must remain, obtain the receiving product owner’s approval.
Remove the release.
```
helm --kube-context "${CTX:?Set CTX}" --namespace pty-policy uninstall policy --wait
```
Helm removes chart-owned workloads and routes. The database claims and retained backup claim remain unless another controller removes them. The chart-owned shared identity provider (IdP) Secret does not remain.
Inspect the remaining workloads and storage.
```
helm --kube-context "$CTX" --namespace pty-policy list --all
kubectl --context "$CTX" --namespace pty-policy get \
  deployments,statefulsets,pods,services,jobs,cronjobs,pvc
kubectl --context "$CTX" --namespace pty-policy get secrets
```
Expect no Policy serving workloads and no installed policy release. Compare retained claim and Secret names with your recovery record. Investigate unexpected leftovers by ownership. Do not delete them automatically.

Verify Retained Data

Confirm that retained claims still reference the recorded volumes. Check that required credentials and external backup copies remain recoverable. If expected storage or credentials are missing, stop and involve the storage or identity owner.

To reinstall using retained data, follow retained-storage recovery. An ordinary fresh installation is not a recovery procedure.

Option B: Uninstall and Remove Data

Confirm Cleanup Inputs

Complete Option A first. Have the storage owner review volume reclaim policies, snapshots, and remote copies. Select the exact live database and backup claim names from the recorded inventory. The default backup claim is policy-db-backup-pvc. Verify actual names.

Warning: Deleting claims can irreversibly destroy database and backup data. Deleting a namespace removes every resource in it, including Secrets. Continue only with explicit data-loss approval and verified exclusive Policy ownership of pty-policy. Neither operation guarantees erasure of snapshots or remote copies.

Remove Approved Resources

To remove the approved resources, follow these steps:

Inspect the remaining claims before selecting deletion targets.
```
kubectl --context "${CTX:?Set CTX}" --namespace pty-policy get pvc -o wide
```
Confirm each selected claim’s exact name and backing volume with the storage owner.

Delete one explicitly approved claim at a time. Replace the example with the exact claim name before running:

APPROVED_PVC='replace-with-one-approved-claim-name'
kubectl --context "${CTX:?Set CTX}" --namespace pty-policy \
  get pvc "${APPROVED_PVC:?Set APPROVED_PVC}"
read -r -p 'Type the claim name to approve its deletion: ' CONFIRMED_PVC
if [ "$CONFIRMED_PVC" = "$APPROVED_PVC" ]; then
  kubectl --context "$CTX" --namespace pty-policy delete pvc "$APPROVED_PVC"
else
  printf 'Claim confirmation did not match; nothing deleted.\n'
fi

Expect deletion only of the confirmed claim. Repeat for each approved live-data or backup claim. Do not use --all. If deletion stalls, ask the storage owner to investigate. Do not remove finalizers.

Complete external-resource cleanup. Revoke obsolete dedicated credentials through their owners. Do not revoke shared registry access or credentials needed for retained recovery.
Ask the platform owner to verify exclusive namespace ownership. Inspect all namespaced resource types, including custom resources:
```
set -o pipefail
kubectl --context "${CTX:?Set CTX}" api-resources \
  --verbs=list --namespaced -o name |
while IFS= read -r RESOURCE_TYPE; do
  kubectl --context "$CTX" --namespace pty-policy \
    get "$RESOURCE_TYPE" --ignore-not-found || exit 1
done
```
Stop if any query fails or shows shared, unknown, or required recovery resources. Resolve external-secret or other controllers that could recreate resources. Resource labels alone do not prove exclusive ownership.

Remove the dedicated namespace only after the platform owner confirms that review. Otherwise, keep the namespace and delete only individually approved resources.

read -r -p 'Type pty-policy after approval to delete the dedicated namespace: ' CONFIRMED_NAMESPACE
if [ "$CONFIRMED_NAMESPACE" = 'pty-policy' ]; then
  kubectl --context "${CTX:?Set CTX}" delete namespace pty-policy
else
  printf 'Namespace confirmation did not match; nothing deleted.\n'
fi

Expect namespace deletion after its resources finish terminating. A stuck namespace needs platform investigation, not forced finalizer removal.

Verify Cleanup

kubectl --context "${CTX:?Set CTX}" get namespace pty-policy --ignore-not-found

No output confirms namespace absence. If you deliberately retained the namespace, inspect it and confirm only approved resources remain. Ask the storage owner to confirm each volume’s intended deletion or retention. Verify external credential revocation and backup disposition through their owning systems.

For a clean reinstall, return to installation preparation. Proceed as fresh only after confirming that no old database will be reused.