Align systemOS watcher output with template behavior

This commit is contained in:
2026-03-27 21:30:36 -04:00
parent 6c7ba5212b
commit d383b57ccc
4 changed files with 85 additions and 16 deletions

View File

@@ -45,7 +45,7 @@ Use this as the default ATVM automation run-status template for:
- datastore/config family: `<config family>`
- config file: `<config-file-name>`
- migration style: `<high-level test style>`
- integration/plugin path: `<integration/plugin>`
- 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:**
@@ -79,7 +79,8 @@ Use this as the default ATVM automation run-status template for:
- 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, integration/plugin path, and important flags like `--ignore_force_shutdown`.
- `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.
@@ -107,6 +108,28 @@ Use this as the default ATVM automation run-status template for:
- `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`
- 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`.