# ATVM Status Template

Use this as the default ATVM automation run-status template for:
- local status responses in the terminal
- Mattermost status posts after a completed run

## Layout

```md
## ATVM Run Status
### <build_name>

**SUMMARY:**

| Metric | Value |
|---|---:|
| finished | <n> |
| passed | <n> |
| failed | <n> |
| skipped | <n> |

**HOSTS:**

| Host | Kernel | Status | Detail |
|---|---|---|---|
| <host-name> | <kernel-version or unknown> | ✅ PASS | completed |
| <host-name> | <kernel-version or unknown> | ⚠️ FAIL | <useful failure description> |
| <host-name> | <kernel-version or unknown> | ⏳ RUN | in progress |
| <host-name> | <kernel-version or unknown> | ⏭️ SKIP | <skip reason> |

**TIMING:**

| Metric | Value |
|---|---|
| start | <start time> |
| end | <end time or n/a> |
| total | <total or elapsed runtime> |
| quickest | <host> - <runtime> or n/a |
| longest | <host> - <runtime> or n/a |
| average | <runtime> or n/a |

**COVERAGE:**
- template: `<template-name>`
- categorize mode: `enabled` or `disabled`
- datastore/config family: `<config family>`
- config file: `<config-file-name>`
- migration style: `<high-level test style>`
- integration/plugin path: `<integration/plugin>` when the template command actually uses one
- run options: `<operator-relevant template flags such as --ignore_force_shutdown>`

**TEST FLOW:**
- <template-specific numbered steps>

**NOTES:**
- <note>
- <note>
```

## Rules
- Keep `SUMMARY:`, `HOSTS:`, `TIMING:`, `COVERAGE:`, `TEST FLOW:`, and `NOTES:` in that order.
- Use the title format:
  - `## ATVM Run Status`
  - `### <build_name>`
- Use flat bullet lists for `COVERAGE:` and `TEST FLOW:`.
- Use Markdown tables for `SUMMARY:`, `HOSTS:`, and `TIMING:`.
- Use one host per row in the `HOSTS:` section.
- Include a `Kernel` column immediately after `Host` in the `HOSTS:` table.
- For completed hosts, prefer:
  - `✅ PASS`
  - `⚠️ FAIL`
- For in-progress or skipped hosts, use:
  - `⏳ RUN`
  - `⏭️ SKIP`
- Keep `Detail` concise.
- Put broader context under `NOTES:`, not in the host table.
- When available, put the persistent Currents run URL in `NOTES:` so operators can open the exact recorded run directly.
- Include the exact `cmc-templates.py` command used to trigger the run in `NOTES:`, without the outer `sshpass`/`ssh` wrapper.
- Keep `NOTES:` limited to meaningful operator-facing items such as the Currents link, real anomalies, failure context, or important fallback behavior.
- Do not include generic watcher bookkeeping lines in `NOTES:` such as "run artifacts were detected" or "final reporting artifacts were detected."
- Do not include internal fallback notes in `NOTES:` such as "`check-xml-files.ts` validation passed" or "host details were derived from reporter artifacts."
- `COVERAGE:` should describe what the run was intended to cover without listing target hosts.
- `COVERAGE:` should mostly mirror the important `cmc-templates.py` command inputs such as template, categorize mode, config filename, any real integration/plugin path, and important flags like `--ignore_force_shutdown`.
- Do not render template-command fields in `COVERAGE:` when that template did not use them.
- If `categorize mode: enabled` is shown, do not also repeat `--categorize` under `run options`.
- When grouped categorized timing is reconstructed from host reporter artifacts, still populate `quickest`, `longest`, and `average` from inferred per-host durations when possible.
- `TEST FLOW:` should describe the template-specific numbered run flow once for the whole test, not per host.
- The watcher resolves `TEST FLOW:` from the run template name.
- `cmc-e2e` currently uses this flow:
  - `1. Verifying set up`
  - `2. Power on and obtain ip address and host name`
  - `3. Uninstall CMC if still exists`
  - `4. Setting up disk on the host`
  - `5. Copy CMC install command from GUI`
  - `6. Install CMC`
  - `7. Create migration session`
  - `8. Tracking Changes`
  - `9. Trigger cmotion and do I/O test before actual cutover`
  - `10. Verify data for cmotion`
  - `11. Trigger revert cmotion and do I/O test before and during cmotion`
  - `12. Verify data for revert cmotion`
  - `13. Trigger cmotion again`
  - `14. Finalize cutover`
  - `15. Create migration report`
  - `16. Delete migration session`
  - `17. Verify local destination disk`
  - `18. Remove enabled FC integration`
  - `19. Remove host and volumes`
  - `20. Uninstall CMC`
  - `21. Clean up iSCSI targets`
  - `22. Power off`
- `cmc-systemOS` currently uses this flow:
  - `1. Verifying set up`
  - `2. Power on and obtain ip address and host name`
  - `3. Uninstall CMC if still exists`
  - `4. Attach destination disk on the host`
  - `5. Copy CMC install command from GUI`
  - `6. Install CMC on the host`
  - `7. Create migration session (Simple Migration)`
  - `8. Tracking Changes (Simple Migration)`
  - `9. Finalize cutover (Simple Migration)`
  - `10. Create migration report (Simple Migration)`
  - `11. Delete migration session (Simple Migration)`
  - `12. Power off the host`
  - `13. Detach original source OS disk`
  - `14. Reassign destination OS disk`
  - `15. Power on to verify destination disk`
  - `16. Power off the host`
  - `17. Detach destination OS disk`
  - `18. Attach original source OS disk back`
  - `19. Power on and obtain ip address and host name`
  - `20. Uninstall CMC on the host`
  - `21. Power off the host`
- `cmc-reboot` currently uses this flow:
  - `1. Verifying set up`
  - `2. Power on and obtain ip address and host name`
  - `3. Uninstall CMC if still exists`
  - `4. Setting up disk on the host`
  - `5. Copy CMC install command from GUI`
  - `6. Install CMC on the host`
  - `7. Create migration session`
  - `8. Tracking Changes`
  - `9. Create reboot validation file on the source disk`
  - `10. Trigger cmotion`
  - `11. Reboot the host`
  - `12. Update disk info after power on`
  - `13. Mount source disk`
  - `14. Verify reboot validation file after reboot`
  - `15. Create second reboot validation file on the source disk`
  - `16. Revert cmotion`
  - `17. Reboot the host`
  - `18. Update disk info after power on`
  - `19. Mount source disk`
  - `20. Verify second reboot validation file after reboot`
  - `21. Trigger cmotion and do I/O test during cmotion`
  - `22. Revert cmotion`
  - `23. Verify data with md5 checksum for the I/O test`
  - `24. Trigger cmotion again`
  - `25. Finalize cutover`
  - `26. Create migration report`
  - `27. Delete migration session`
  - `28. Verify local destination disk`
  - `29. Remove host and disks`
  - `30. Remove enabled integration`
  - `31. Uninstall CMC on the host`
  - `32. Clean up iSCSI targets`
  - `33. Power off the host`
- See `/home/aw/code/cds/atvm/docs/automation/examples.md` for `cmc-e2e` examples.
- Resolve kernel values by cross-referencing hostnames against `/home/aw/code/cds/atvm/inventory/vm-inventory.md`.
- If no kernel value can be verified from `vm-inventory.md`, use `unknown`.
- Use the same template for Mattermost and local operator-visible status output.