.. _auto_cloud_destroy_customer: *DESTROY A CUSTOMER CLUSTER (TERRAFORM DESTROY + OPTIONAL SP DELETE)* ===================================================================== Tears down a provisioned d3VIEW customer cluster cleanly. Runs `make clean` in the customer dir on the cloud-ops host (terraform destroy of every module owned by the customer RG) and, optionally, deletes the per-customer Service Principal via `az ad sp delete` (closes the SP-orphan gap Dennis's bare `clean` target leaves behind). Optionally also removes the d3VIEW Hpcserver row tied to this customer. Admin-only; requires CLOUD_PROVISIONING_ENABLED=yes. HARD safety: the `confirm` input must equal the `cid` (type-to-confirm) so an accidental execute can't nuke a live customer. When to use ----------- Tagged: ``azure``, ``cloud``, ``customer``, ``destroy``, ``teardown``, ``sp``, ``terraform``. Inputs ------ .. list-table:: :header-rows: 1 :widths: 20 20 20 20 20 20 * - Label - ID - Type - Default - Required - Description * - Customer ID (CID) - cid - text - — - ✓ - The 12-character hex CID of the customer to destroy. Find this in the cloud_create_customer output, in the customer dir name on the cloud-ops host, or in the d3VIEW Hpcserver row's options.cloud_provisioning_meta.cid. * - Customer Directory - customer_dir - text - — - ✓ - Absolute path to the customer dir on the cloud-ops host (e.g. /opt/cloud/customer-data/regions/eastus/d3v-pool-eastus-0/f0ab12345678). This is where the Terraform state lives - `make clean` runs from this directory. * - Delete per-customer Service Principal? - delete_sp - select - yes - - Default yes. The per-customer SP was created by `make principal.o` during provisioning; Dennis's bare `make clean` target does NOT delete it, leaving an orphan SP in Azure AD. Setting this to yes closes that gap. * - Delete d3VIEW Hpcserver row? - delete_hpcserver_row - select - yes - - Default yes. The d3VIEW Hpcserver row tied to this customer is identified by options.cloud_provisioning_meta.cid == cid. Setting this to no leaves the row pointing at a dead IP - downstream jobs will fail. * - Type the CID to confirm destruction - confirm - text - — - ✓ - SAFETY CHECK: type the customer's exact CID into this field. The worker refuses to run unless `confirm` equals `cid`. This prevents an accidental execute from nuking a live customer. There is no undo. Outputs ------- .. list-table:: :header-rows: 1 :widths: 20 20 20 20 * - Label - ID - Type - Description * - Clean Status - clean_status - text - One of: success / complete / partial / failed. `partial` means a teardown step was not verified-complete: the resource group was still present after delete (cost leak), the SP was not confirmed deleted, or the Hpcserver row cleanup did not run. * - Resource Group Deleted (verified) - rg_deleted - text - yes / no. Verified via `az group exists` AFTER `az group delete -n d3v--rg --yes`. This is the authoritative cost-leak signal: `make clean` (base terraform destroy) does NOT remove the RG shell or the out-of-band SLURM cloud-burst VMSS, so an RG-level delete is required to guarantee no orphaned, still-billing resources. `no` => investigate immediately. * - SP Deleted (verified) - sp_deleted - text - yes / no / skip. Verified via `az ad sp show` (not-found => deleted). `skip` when delete_sp=no. * - Hpcserver Row Deleted - hpcserver_row_deleted - text - yes / no / skip. `skip` when delete_hpcserver_row=no. `no` when delete_hpcserver_row=yes but no matching row was found. * - Clean Log Tail - clean_log_tail - textarea - Last lines of `make clean` output captured by Azure->triggerMakeClean (terraform destroy stdout / stderr). First place to look on any failure. * - Execution Log - execution_log - textarea - Structured per-step trace of the worker's run with durations + outcomes. Disciplines ----------- - platform.cloud - platform.hpc .. raw:: html

Auto-generated from platform schema. Worker id: cloud_destroy_customer. Schema hash: 39865cf39365. Hand-curated docs in workerexamples/ override this page when present.