cds-ai/atvm/docs/automation/status-template.md

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

## 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>`
- datastore/config family: `<config family>`
- config file: `<config-file-name>`
- migration style: `<high-level test style>`
- integration/plugin path: `<integration/plugin>`
- run options: `<operator-relevant options 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.
• 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 also include operator-relevant run options such as the config filename and important flags like --ignore_force_shutdown.
• 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
• 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.