From 63dd40faabc0abc5b02ef1853b20c2d73cf845d0 Mon Sep 17 00:00:00 2001
From: "anthony.wen" <awen01@gmail.com>
Date: Mon, 30 Mar 2026 11:22:15 -0400
Subject: [PATCH] Add detailed ATVM reboot test flow

---
 atvm/docs/automation/run-learnings.md    |  8 ++++++
 atvm/docs/automation/status-template.md  | 34 +++++++++++++++++++++++
 atvm/watcher-service/atvm_run_watcher.py | 35 ++++++++++++++++++++++++
 3 files changed, 77 insertions(+)

diff --git a/atvm/docs/automation/run-learnings.md b/atvm/docs/automation/run-learnings.md
index 076b540..79f7817 100644
--- a/atvm/docs/automation/run-learnings.md
+++ b/atvm/docs/automation/run-learnings.md
@@ -271,6 +271,14 @@ This file stores run-specific examples only when a run produced a new learning r
 - Action for future runs:
   - Render ATVM status output in that section order for both local output and Mattermost posts.
 
+## Run Learning: 2026-03-30 (Give `cmc-reboot` a full template-specific test flow)
+- Observed failure mode:
+  - `cmc-reboot` status output fell back to the generic 5-step placeholder flow.
+  - The actual reboot workflow is substantially longer and includes reboot-specific validation around cmotion, revert cmotion, and post-reboot disk verification.
+- Action for future runs:
+  - Define a dedicated `cmc-reboot` `TEST FLOW:` in the watcher and status template.
+  - Keep the reboot flow aligned with the generated reboot Cypress spec rather than the generic fallback list.
+
 ## Run Learning: 2026-03-27 (Persist the Currents run URL outside the transient runner log)
 - Observed failure mode:
   - The watcher can include the Currents run URL in `NOTES:`, but only if it can still read the URL from live runner output or a consolidated run log.
diff --git a/atvm/docs/automation/status-template.md b/atvm/docs/automation/status-template.md
index cbca28c..c351918 100644
--- a/atvm/docs/automation/status-template.md
+++ b/atvm/docs/automation/status-template.md
@@ -130,6 +130,40 @@ Use this as the default ATVM automation run-status template for:
   - `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`.
diff --git a/atvm/watcher-service/atvm_run_watcher.py b/atvm/watcher-service/atvm_run_watcher.py
index ee6eb5d..25929bf 100644
--- a/atvm/watcher-service/atvm_run_watcher.py
+++ b/atvm/watcher-service/atvm_run_watcher.py
@@ -87,6 +87,41 @@ TEMPLATE_TEST_FLOWS = {
         "20. Uninstall CMC on the host",
         "21. Power off the host",
     ],
+    "cmc-reboot": [
+        "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",
+    ],
 }