Show full template test flow in ATVM status

This commit is contained in:
2026-03-27 10:19:02 -04:00
parent 2699651f8f
commit 53f9e68fcd
4 changed files with 84 additions and 32 deletions

View File

@@ -214,7 +214,7 @@ When asked for one VM or a VM set:
When the operator asks for the status of an ATVM automation run, report in this order:
1. Heading/title using the run `build_name`.
2. `COVERAGE:` section describing what the run was intended to cover, excluding the target-host list.
3. `TEST FLOW:` section describing the generic numbered run flow for the test.
3. `TEST FLOW:` section describing the template-specific numbered run flow for the test.
4. Completed machines with machine name first and status second for each machine.
5. Notes.
6. Skipped machines with reason.
@@ -235,7 +235,9 @@ Status-report expectations:
- The default ATVM status template uses flat bullet-list sections for `COVERAGE:` and `TEST FLOW:`, Markdown tables for `SUMMARY:`, `HOSTS:`, and `TIMING:`, and uses `NOTES:` for flat operator-facing notes.
- The `HOSTS:` table includes `Host`, `Kernel`, `Status`, and `Detail` columns in that order.
- In `COVERAGE:`, describe the template, datastore/config family, migration style, and plugin/integration path, but do not list target hosts there.
- In `TEST FLOW:`, show the generic numbered run flow once for the whole test, not per host.
- In `TEST FLOW:`, show the template-specific numbered run flow once for the whole test, not per host.
- Resolve the flow from the run template name.
- `cmc-e2e` currently uses the 18-step migration flow documented in `/home/aw/code/cds/atvm/docs/automation/status-template.md`.
- For the `Kernel` column, cross-reference the host name against `/home/aw/code/cds/atvm/inventory/vm-inventory.md`.
- If the hostname is not present in `vm-inventory.md`, report the kernel value as `unknown`.
- Treat references to the "ATVM automation run" or "automation run" as referring to this ATVM folder workflow and the automation VM at `192.168.3.190`, not to Cirrus project operations such as the `atvm - cypress` project.

View File

@@ -195,22 +195,31 @@ This file stores run-specific examples only when a run produced a new learning r
## Run Learning: 2026-03-27 (Replace FUNCTIONALLY with TEST FLOW in status output)
- Observed requirement:
- The operator wants the status format to show the generic numbered ATVM test flow rather than a vague high-level `FUNCTIONALLY:` summary.
- The operator wants the status format to show the full numbered ATVM test flow for the active template rather than a vague high-level `FUNCTIONALLY:` summary.
- Each ATVM template can have its own test-flow step list.
- The step list should appear once for the whole run, not repeated per host.
- Action for future runs:
- Replace the `FUNCTIONALLY:` section with `TEST FLOW:` in ATVM status output.
- Use the generic numbered run flow:
- Resolve `TEST FLOW:` from the ATVM template name instead of hardcoding one shared list for every template.
- For `cmc-e2e`, use this numbered run flow:
- `1. Verifying set up`
- `2. Power on and obtain ip address and host name`
- `3. Uninstall cmc if still exist`
- `3. Uninstall CMC if still exists`
- `4. Setting up disk`
- `5. Copy cmc install command from GUI`
- `6. Install cmc`
- `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`
- `...`
- `22. Power off`
- `10. Verify migration remains healthy during I/O activity`
- `11. Prepare for cutover`
- `12. Stop application / stop test I/O`
- `13. Run final sync`
- `14. Confirm destination is fully up to date`
- `15. Perform cutover`
- `16. Validate destination host / disk state`
- `17. Run post-cutover checks`
- `18. Power off`
## Run Learning: 2026-03-27 (Start watcher before runner when watcher is requested)
- Observed failure mode:

View File

@@ -18,17 +18,7 @@ Use this as the default ATVM automation run-status template for:
- scope of this run: `<batch or run scope>`
**TEST FLOW:**
- 1. Verifying set up
- 2. Power on and obtain ip address and host name
- 3. Uninstall cmc if still exist
- 4. Setting up disk
- 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
- ...
- 22. Power off
- <template-specific numbered steps>
**SUMMARY:**
@@ -82,7 +72,28 @@ Use this as the default ATVM automation run-status template for:
- Keep `Detail` concise.
- Put broader context under `NOTES:`, not in the host table.
- `COVERAGE:` should describe what the run was intended to cover without listing target hosts.
- `TEST FLOW:` should describe the generic numbered run flow once for the whole test, not per host.
- `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`
- `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 migration remains healthy during I/O activity`
- `11. Prepare for cutover`
- `12. Stop application / stop test I/O`
- `13. Run final sync`
- `14. Confirm destination is fully up to date`
- `15. Perform cutover`
- `16. Validate destination host / disk state`
- `17. Run post-cutover checks`
- `18. 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.