Add kernel lookup to ATVM status template

- update the ATVM status template so the HOSTS: table includes a Kernel column after Host
- document that kernel values should be resolved by cross-referencing hostnames in atvm/inventory/vm-inventory.md
- document that unknown should be used when a kernel value cannot be verified from the VM inventory
- align the ATVM automation guide so local status output and Mattermost posts use the kernel-aware host table
This commit is contained in:
2026-03-24 22:32:58 -04:00
parent 0bf07f0e9c
commit fc0ad5f09e
2 changed files with 12 additions and 6 deletions

View File

@@ -210,8 +210,11 @@ Status-report expectations:
- Use the same display layout for every ATVM automation status response regardless of test type (`e2e`, `systemOS`, `reboot`, `migrateops`, and others).
- Use `/home/aw/code/cds/atvm/docs/automation/status-template.md` as the default template for both local status output and Mattermost status posts.
- The default ATVM status template uses flat bullet-list sections for `COVERAGE:` and `FUNCTIONALLY:`, 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 `FUNCTIONALLY:`, summarize what the run is intended to do at a high level, even when the run failed before reaching those steps.
- 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.
- Treat a status request as a request for live status by default.
- Unless the operator explicitly asks to send the status to Mattermost, print the status only in the local terminal response.

View File

@@ -33,12 +33,12 @@ Use this as the default ATVM automation run-status template for:
**HOSTS:**
| Host | Status | Detail |
|---|---|---|
| <host-name> | ✅ PASS | completed |
| <host-name> | ⚠️ FAIL | <useful failure description> |
| <host-name> | ⏳ RUN | in progress |
| <host-name> | ⏭️ SKIP | <skip reason> |
| 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:**
@@ -64,6 +64,7 @@ Use this as the default ATVM automation run-status template for:
- Use flat bullet lists for `COVERAGE:` and `FUNCTIONALLY:`.
- 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`
@@ -74,4 +75,6 @@ Use this as the default ATVM automation run-status template for:
- Put broader context under `NOTES:`, not in the host table.
- `COVERAGE:` should describe what the run was intended to cover without listing target hosts.
- `FUNCTIONALLY:` should describe the intended workflow steps at a high level, even if the run failed before completing them.
- 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.