- add explicit Windows ATVM guest credential references alongside the existing Linux target defaults - update the ATVM automation guide and AGENTS rules so Linux SSH uses ATVM_TARGET_* while Windows guest access uses ATVM_WINDOWS_TARGET_* - update the CDS MCP CMC install and VMware workflow docs to distinguish Linux and Windows credential usage for the shared ATVM target IP - update the VM lookup reference so common VM credentials list both Linux and Windows target variables
4.2 KiB
4.2 KiB
ATVM AGENTS Guide
This file defines how to operate and maintain the ATVM workspace in /home/aw/code/cds/atvm.
Workspace Layout
README.md- human entry point for the folder
scripts/- executable workflow assets
docs/setup/- setup/bootstrap procedure and run learnings
docs/automation/- ATVM Cypress automation procedure, examples, and run learnings
docs/workflow/- shared conventions for how the docs are maintained
inventory/- environment reference, credentials, IP allocations, and inventory indexes
archive/imported-notes/- preserved original long-form source material
Authoritative Sources
- Setup/bootstrap procedure:
docs/setup/guide.md
- Setup/bootstrap learnings:
docs/setup/run-learnings.md
- Automation execution procedure:
docs/automation/guide.md
- Automation command examples:
docs/automation/examples.md
- Automation run learnings:
docs/automation/run-learnings.md
- Workspace conventions:
docs/workflow/conventions.md
Setup Track Defaults
- ATVM static IP target:
192.168.3.191/22 - Gateway:
192.168.0.1 - DNS:
8.8.8.8,8.8.4.4 - Default Linux setup credential source:
/home/aw/code/cds/.env.credentials.localviaATVM_TARGET_USERandATVM_TARGET_PASSWORD - Client log file:
atvm_setup_script.log - Treat
192.168.3.191as the default ATVM target host reference. - For SSH to
192.168.3.191, ignore host key mismatch by default with-o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null. - For Linux SSH to
192.168.3.191, source/home/aw/code/cds/.env.credentials.localand useATVM_TARGET_USERplusATVM_TARGET_PASSWORDunless explicitly overridden. - Use
ATVM_WINDOWS_TARGET_USERplusATVM_WINDOWS_TARGET_PASSWORDfor Windows guest access to the same ATVM target IP unless explicitly overridden.
Automation Track Defaults
- Controller host:
atvm-cypres-vm-1 - Controller IP:
192.168.3.190 - Controller credential source:
/home/aw/code/cds/.env.credentials.localviaATVM_CONTROLLER_USERandATVM_CONTROLLER_PASSWORD - Detailed test artifact root on controller:
/root/cdc-e2e-cyp-12.17.4/cypress/cmcReporter - Default Mattermost status destination config:
/home/aw/code/cds/.env.credentials.local - Default plugin:
--use_specified_plugin iscsi - Always include
--ignore_force_shutdownunless explicitly told not to. - Default config family:
gold
Required Operating Rules
- Never run setup without operator-provided
--expected-ipand--expected-hostname. - Keep static IP configuration as the final setup step.
- Before any automation run, always check whether automation is already running.
- Always show exact planned ATVM commands before execution.
- Never execute setup or automation commands that require approval until the operator explicitly approves them.
- For ATVM run approvals, treat
approveas run-without-watcher andapprove with watcheras run-with-watcher. - For host-level test detail and failed-test investigation, use
/root/cdc-e2e-cyp-12.17.4/cypress/cmcReporter, especiallylogs/,xml/, andmochawesome/. - If the operator asks for ATVM run status without mentioning Mattermost, respond locally only and do not post externally.
- If the operator asks to send ATVM run status to Mattermost, use
MATTERMOST_ATVM_WEBHOOKandMATTERMOST_ATVM_CHANNELfrom/home/aw/code/cds/.env.credentials.localby default and send the final status only after the run has fully completed, whether the run passed or failed. - Treat
docs/automation/examples.mdas reference-only, not default operator intent. - Put reusable workflow rules in
guide.mdfiles. - Put dated lessons only in
run-learnings.mdfiles. - Keep durable environment reference in
inventory/. - Preserve imported long-form notes in
archive/imported-notes/; do not treat them as the primary runbook.
Maintenance Rules
- When changing workflow behavior, update the corresponding
guide.md. - When adding a reusable command pattern, update
docs/automation/examples.md. - When a run produces a new lesson, update the appropriate
run-learnings.md. - Keep filesystem paths in docs aligned with the actual repo layout.
- Do not remove detailed inventory or credential information from this workspace unless explicitly instructed.