anthony.wen/cds-ai
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
72ef15f308bde63c9011faadb503be6f0cb7ffb2
cds-ai/atvm/docs/automation/status-template.md

7.4 KiB
Raw Blame History

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 (For failures, see Failure Notes section below for more details) |
|---|---|---|---|
| <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>

**FAILURE NOTES:**
- <detailed per-host failure excerpt when a host fails>

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

Rules

  • Keep SUMMARY:, HOSTS:, TIMING:, COVERAGE:, TEST FLOW:, FAILURE NOTES:, 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 richer per-host failure excerpts under FAILURE NOTES:, not in the host table.
  • Put broader non-failure context under NOTES:.
  • 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.
  • Include the exact run-sorry-cypress.py command used to launch the run in NOTES:, without the outer sshpass/ssh wrapper.
  • Keep FAILURE NOTES: limited to detailed per-host error excerpts.
  • Keep NOTES: limited to meaningful non-failure operator-facing items such as the Currents link, real anomalies, 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 should prefer the generated spec for the actual run when it exists, and only include the plugin-gated branch that actually ran.
  • 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.
Reference in New Issue View Git Blame Copy Permalink