anthony.wen/cds-ai
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Reorganize ATVM workspace into scripts, docs, inventory, and archive

Browse Source 
Restructure the ATVM folder to separate executable scripts from workflow documentation and long-form environment reference material.

Move setup and automation scripts into scripts/, move setup and automation guides into docs/, add top-level README and workflow conventions, and organize durable environment details into inventory/ while preserving the original long-form ATVM notes under archive/imported-notes/.

Update internal documentation paths to match the new layout and remove the archived Zone.Identifier metadata file.
This commit is contained in:
anthony.wen
2026-03-21 20:39:23 -04:00
parent 08b2ab3104
commit 274b920b40
17 changed files with 332 additions and 191 deletions
Download Patch File Download Diff File Expand all files Collapse all files

235
atvm/AGENTS.md
View File

@@ -1,189 +1,70 @@
# ATVM AGENTS Guide
This file defines how to operate and maintain the ATVM folder workflows.
It is rebuilt from current files in `/home/aw/code/cds/atvm`.
This file defines how to operate and maintain the ATVM workspace in `/home/aw/code/cds/atvm`.
## Scope
Two operational tracks exist in this folder:
- Setup/bootstrap track:
- `atvm-setup-script.sh`
- `run-atvm-setup-and-collect-log.sh`
- `atvm-setup-script-guide.md`
- `atvm-setup-script-runs.md`
- Cypress automation track:
- `atvm-automation-guide.md`
- `atvm-automation-examples.md`
- `atvm-automation-runs.md`
## 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
Reference/inventory material:
- `cypress-automation-for-cmc.md`
- `cypress-automation-for-cmc.md:Zone.Identifier`
## 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`
## File Roles
- `*-guide.md` files:
- Guide-only procedures, rules, defaults, and checklists.
- No dated or one-off run examples.
- `*-runs.md` files:
- Run-specific learnings only when a run introduces new information.
- No routine/no-change run logs.
- `*-examples.md` files:
- Reusable command examples and commonly used option combinations.
- Keep generic; avoid dated one-off run outcomes.
- Keep command-focused; move workflow rules, defaults, blacklist policy, and reporting requirements into the corresponding `*-guide.md` or `*-runs.md` files.
## Setup Track: Required Behavior
Use `atvm-setup-script-guide.md` as the procedure source and keep behavior aligned with `atvm-setup-script.sh`.
### Safety-Critical Rules
1. Never run setup without operator-provided `--expected-ip` and `--expected-hostname`.
2. Never infer expected hostname from target host output.
3. Stop immediately on hostname mismatch or expected-IP-not-assigned.
4. Keep static IP configuration as a final step to avoid mid-run connection loss.
### Canonical Setup Order
1. Parse args.
2. Validate host identity.
3. Check sudo/privileges.
4. Fix repositories.
5. Configure Ubuntu root SSH/password workflow (Ubuntu only).
6. Install sudo if needed.
7. Configure Oracle default non-UEK kernel (Oracle Linux only).
8. Disable Ubuntu auto-upgrades (Ubuntu only).
9. Run package cleanup/install.
10. Disable SELinux (RHEL-family).
11. Configure static IP.
12. Print summary.
13. Reboot + post-reboot SELinux verifier when applicable.
14. Keep client on until controller log copy + SHA256 verification completes.
15. Power off only after verified success and no real error log lines.
### Setup Defaults
## 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`
- Ubuntu root SSH workflow credential in docs/script: `root / cdsi2012`
- Client log file: `atvm_setup_script.log` (typically `/root/atvm_setup_script.log` when run as root)
- When the operator refers to `192.168.3.191`, treat it as the ATVM target host by default.
- Default setup credential: `root / cdsi2012`
- Client log file: `atvm_setup_script.log`
- Treat `192.168.3.191` as 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 SSH to `192.168.3.191`, use default credentials `root / cdsi2012` unless the operator explicitly overrides them.
- For SSH to `192.168.3.191`, use default credentials `root / cdsi2012` unless explicitly overridden.
### Setup Controller Wrapper Rules
- Wrapper supports:
- run-and-collect (default)
- `--collect-after-complete`
- `run-and-collect` requires env vars:
- `EXPECTED_IP_ARG`
- `EXPECTED_HOSTNAME_ARG`
- Wrapper validates success marker and SHA256 before success.
- Wrapper powers off only when log has no lines matching `^\[ERROR\]`.
## Automation Track Defaults
- Controller host: `atvm-cypres-vm-1`
- Controller IP: `192.168.3.190`
- Controller credentials: `root / atvmcdsi2012`
- Default plugin: `--use_specified_plugin iscsi`
- Always include `--ignore_force_shutdown` unless explicitly told not to.
- Default config family: `gold`
## Cypress Automation Track: Required Behavior
Use `atvm-automation-guide.md` as the execution source.
Use `atvm-automation-examples.md` as the common options/command reference.
Treat `atvm-automation-examples.md` as reference-only.
Do not treat example options, excludes, plugins, or filters as default operator intent unless the operator explicitly asks for them.
## Required Operating Rules
- Never run setup without operator-provided `--expected-ip` and `--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.
- Treat `docs/automation/examples.md` as reference-only, not default operator intent.
- Put reusable workflow rules in `guide.md` files.
- Put dated lessons only in `run-learnings.md` files.
- Keep durable environment reference in `inventory/`.
- Preserve imported long-form notes in `archive/imported-notes/`; do not treat them as the primary runbook.
### Controller Client
- Hostname: `atvm-cypres-vm-1`
- IP: `192.168.3.190`
- Credentials: `root / atvmcdsi2012`
### Mandatory Run Control
1. Before planning a new run, check for active automation processes.
2. Report running/not-running status.
3. If running, ask before termination; terminate only with explicit approval.
4. Always show exact planned command(s) exactly as they will be executed before execution.
5. Never execute `cmc-templates.py`, `run-sorry-cypress.py`, or any other ATVM run command until the operator explicitly approves the displayed command(s).
6. Approval is required for template-generation commands as well as the runner command.
7. If the operator changes the requested scope, plugin, config, build name, or any other option after commands are shown, rebuild the commands, display them again, and wait for fresh approval.
8. If monitoring is not requested, report immediate command success/failure and any errors.
9. Monitor completion only when explicitly requested by the operator.
10. For monitored runs, allow long runtime windows (15-30+ minutes or longer) and continue until completion unless operator instructs otherwise.
11. Do not terminate monitored runs unless the operator explicitly instructs termination.
### Status Request Format
When the operator asks for run status, report in this order:
1. Heading/title using the run `build_name`.
2. Completed machines with machine name first and status second for each machine.
3. Notes.
4. Skipped machines with reason.
5. Remaining machines still to run.
6. Summary counts for finished, passed, failed, and skipped machines.
7. Timing details:
- start time
- end time if complete
- total run time if complete, or elapsed run time if still running
- quickest completed test runtime
- longest completed test runtime
- average completed test runtime
8. Estimated completion time.
Status details:
- Use the same status display format for every ATVM automation status response regardless of template type (`e2e`, `systemOS`, `reboot`, `migrateops`, and others).
- Treat references to the "ATVM automation run" or "automation run" as referring to the local ATVM automation workflow in `/home/aw/code/cds/atvm` and the automation VM at `192.168.3.190`, not to Cirrus project operations with similar names.
- Treat a status request as a request for live status by default.
- Use the live run log on the automation VM when available.
- If no automation is currently running, fall back to the most recent historical run artifacts and logs.
- Use the run `build_name` as the heading/title when available.
- Format every machine entry as `machine-name - STATUS`.
- Put each machine on its own line; do not combine multiple machine statuses on one line.
- Put failure reasons, oddities, and operator-facing context in a dedicated `Notes` section.
- Show blacklisted machines under skipped machines when they are part of the requested scope.
- Show in-progress machines under remaining machines as `RUNNING`.
- Show not-yet-started machines as `NOT STARTED`.
- Use completed spec results already recorded in the log to determine machine pass/fail state.
- For failed machines, mark the machine `FAIL` in the completed list and append a longer failure description on the same machine line when the reason materially helps the operator understand the failure.
- Keep `Notes` for broader context, anomalies, or follow-up details that are not part of the machine-specific failure description.
- Include start time in status output when it can be derived from the log.
- Include end time and total runtime for completed runs, or elapsed runtime for active runs.
- Include quickest completed test runtime, longest completed test runtime, and average completed test runtime under timing details when they can be derived from the log.
- Make the estimated completion time refer to the entire remaining run, not only the current machine/spec.
- For categorized runs, reconstruct the status of the entire run across all category batches whether the run is still active or only historical artifacts remain.
### Automation Blacklist
Always exclude these machines with `--exclude_partial_match` when building ATVM automation commands.
CMC install blacklist (`BLACKLISTED: CMC INSTALL - CAN'T COMPILE`):
- `atvm6-centos6.0`
- `atvm41-redhat6.0`
- `atvm73-oracle6.0`
Crash blacklist (`BLACKLISTED: CRASHES WHEN CREATING MIGRATION SESSION - BUG`):
- `atvm144-suse15.0`
Support-request blacklist (`BLACKLISTED: SUPPORT REQUEST - WAITING`):
- `atvm113-debian9.0.0`
- `atvm115-debian9.1.0`
- `atvm116-debian9.2.0`
Re-create-might-be-needed blacklist (`BLACKLISTED: RE-CREATE MIGHT BE NEEDED`):
- `atvm156-debian9.3.0`
### Operator Preferences
- Do not include Gold Disk IDs in `--build_name`.
- `--build_name` must not contain spaces; use `-` between words.
- Prefer distro-scoped filtering (for example `--containsVm redhat9`) when possible.
- Always include `--ignore_force_shutdown` on `cmc-templates.py` commands unless the operator explicitly asks not to.
- Default to `--use_specified_plugin iscsi` unless the operator explicitly requests a different plugin.
- Do not reference `cypress.atvm-config.ts` by default.
- Unless the operator explicitly asks for another config, use ATVM config files with `gold` in the filename (for example `cypress.atvm-config-gold.ts`).
- If the operator-specified ATVM config file is missing, fail fast and report the missing filename.
- Do not search for alternate config files or silently substitute another config unless the operator explicitly asks for that.
## Update Policy (Both Tracks)
After each run:
- Update corresponding `*-guide.md` only if workflow/rules/default behavior changed.
- Update corresponding `*-examples.md` when common command patterns/options change.
- Update corresponding `*-runs.md` only if the run produced new learning.
## Path and Naming Consistency Note
Current repo filenames use hyphen style, but some script text/defaults still show underscore-style paths (for example `atvm_setup_script.sh`, `run_atvm_setup_and_collect_log.sh`, `/home/aw/code/atvm`).
When operating:
1. Use actual filesystem paths in this repo first (`/home/aw/code/cds/atvm/...`).
2. If script defaults are used, verify they match existing files before execution.
3. If changing path conventions, update scripts and guides in the same change.
## Non-Goals
- Do not treat `cypress-automation-for-cmc.md` as executable runbook logic.
- Do not record secrets/tokens into new guide or runs entries.
## 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.

34
atvm/README.md Normal file
View File

@@ -0,0 +1,34 @@
# ATVM Workspace
This folder contains the ATVM setup workflow, ATVM Cypress automation workflow, and the lab inventory/reference material used to operate them.
## Start Here
- Setup/bootstrap workflow:
- `docs/setup/guide.md`
- ATVM Cypress automation workflow:
- `docs/automation/guide.md`
- Shared maintenance conventions:
- `docs/workflow/conventions.md`
- Environment inventory and credentials:
- `inventory/overview.md`
## Layout
- `scripts/`
- executable scripts used by setup/bootstrap
- `docs/setup/`
- setup procedure and setup run learnings
- `docs/automation/`
- automation procedure, reusable examples, and automation run learnings
- `docs/workflow/`
- conventions for how this workspace is structured and maintained
- `inventory/`
- environment inventory, credentials, reserved IPs, and reference maps
- `archive/imported-notes/`
- preserved original long-form notes that were reorganized into the current structure
## Practical Guidance
- Use `guide.md` files for authoritative workflow behavior.
- Use `examples.md` for reusable command patterns only.
- Use `run-learnings.md` only when a run produced a new lasting lesson.
- Use `inventory/` for persistent environment information such as hosts, credentials, and IP assignments.
- Use `archive/imported-notes/` when you need the original full historical notes in their original layout.

0
atvm/cypress-automation-for-cmc.md → atvm/archive/imported-notes/cypress-automation-for-cmc.md
View File

BIN
atvm/cypress-automation-for-cmc.md:Zone.Identifier
View File

Binary file not shown.

0
atvm/atvm-automation-examples.md → atvm/docs/automation/examples.md
View File

12
atvm/atvm-automation-guide.md → atvm/docs/automation/guide.md
View File

@@ -2,8 +2,8 @@
This file is guide-only documentation for operating ATVM CMC automation.
Do not put specific run examples here.
For reusable command examples and common option combinations, use `atvm-automation-examples.md`.
Treat `atvm-automation-examples.md` as reference-only.
For reusable command examples and common option combinations, use `examples.md`.
Treat `examples.md` as reference-only.
Do not assume the operator wants the extra options shown in examples unless they explicitly request them.
## Purpose
@@ -83,10 +83,10 @@ python3 ./run-sorry-cypress.py --config_file <config-file> --build_name <hyphena
```
## Examples Reference
- Commonly used command examples: `atvm-automation-examples.md`
- Commonly used command examples: `examples.md`
- Keep this guide focused on run-control rules and workflow constraints.
- Use examples as reference material only, not as default intent for new operator requests.
- Keep `atvm-automation-examples.md` limited to reusable example commands; keep workflow rules, defaults, blacklist policy, and reporting rules in this guide or `atvm-automation-runs.md`.
- Keep `examples.md` limited to reusable example commands; keep workflow rules, defaults, blacklist policy, and reporting rules in this guide or `run-learnings.md`.
## Example Option Patterns (Guide-Only)
- Distro-scoped VM selection:
@@ -153,8 +153,8 @@ When asked for one VM or a VM set:
## Update Rule
- After each run, update this guide only for workflow/rule/default changes.
- Update `atvm-automation-examples.md` for reusable command/option examples.
- Add run-specific learnings only to `atvm-automation-runs.md` when the run produced new information.
- Update `examples.md` for reusable command/option examples.
- Add run-specific learnings only to `run-learnings.md` when the run produced new information.
## Monitoring Policy
- Monitor only when the operator explicitly asks to monitor.

4
atvm/atvm-automation-runs.md → atvm/docs/automation/run-learnings.md
View File

@@ -7,7 +7,7 @@ This file stores run-specific examples only when a run produced a new learning r
- Do not add routine runs with no new learning.
## Current State
- No run-learning entries recorded yet from `atvm-automation-guide.md` source material.
- No run-learning entries recorded yet from `guide.md` source material.
## Run Learning: 2026-03-08 (E2E redhat9.7, pure/fc)
- Request:
@@ -104,7 +104,7 @@ This file stores run-specific examples only when a run produced a new learning r
- Reusable examples may contain extra excludes or options that the operator did not ask for.
- Carrying those example details into a new run without confirmation can change the requested scope.
- Action for future runs:
- Treat `atvm-automation-examples.md` as reference-only.
- Treat `examples.md` as reference-only.
- Use only the options the operator explicitly requested, plus maintained mandatory blacklist handling.
- Do not assume extra example exclusions such as distro filters are desired unless the operator asks for them.

12
atvm/atvm-setup-script-guide.md → atvm/docs/setup/guide.md
View File

@@ -4,9 +4,9 @@ This file is guide-only documentation for running and maintaining the ATVM setup
Do not put dated run examples here.
## Scope
- Client setup script: `/home/aw/code/cds/atvm/atvm-setup-script.sh`
- Controller wrapper: `/home/aw/code/cds/atvm/run-atvm-setup-and-collect-log.sh`
- Run-learnings log: `/home/aw/code/cds/atvm/atvm-setup-script-runs.md`
- Client setup script: `/home/aw/code/cds/atvm/scripts/atvm-setup-script.sh`
- Controller wrapper: `/home/aw/code/cds/atvm/scripts/run-atvm-setup-and-collect-log.sh`
- Run-learnings log: `/home/aw/code/cds/atvm/docs/setup/run-learnings.md`
## Purpose
The setup flow performs a controlled bootstrap across supported Linux distributions:
@@ -143,12 +143,12 @@ sudo bash /home/cirrususer/atvm-setup-script.sh \
Controller run + collect:
```bash
EXPECTED_IP_ARG=<current-client-ip> EXPECTED_HOSTNAME_ARG=<exact-hostname> \
/home/aw/code/cds/atvm/run-atvm-setup-and-collect-log.sh
/home/aw/code/cds/atvm/scripts/run-atvm-setup-and-collect-log.sh
```
Controller collect-only after client run:
```bash
/home/aw/code/cds/atvm/run-atvm-setup-and-collect-log.sh --collect-after-complete
/home/aw/code/cds/atvm/scripts/run-atvm-setup-and-collect-log.sh --collect-after-complete
```
## Troubleshooting
@@ -165,4 +165,4 @@ Controller collect-only after client run:
## Update Rule
- After each run, update this file only for guide/rule/checklist/default behavior changes.
- Put run-specific outcomes in `atvm-setup-script-runs.md` only when the run produced a new learning.
- Put run-specific outcomes in `run-learnings.md` only when the run produced a new learning.

0
atvm/atvm-setup-script-runs.md → atvm/docs/setup/run-learnings.md
View File

30
atvm/docs/workflow/conventions.md Normal file
View File

@@ -0,0 +1,30 @@
# ATVM Workspace Conventions
## File Roles
- `guide.md`
- authoritative workflow rules, defaults, and checklists
- `examples.md`
- reusable command examples only
- `run-learnings.md`
- dated lessons captured only when a run produced a new lasting insight
- `inventory/*.md`
- durable environment reference and listings
- `archive/imported-notes/*.md`
- preserved source material kept for completeness and traceability
## Update Policy
- Update `docs/setup/guide.md` when setup/bootstrap workflow behavior changes.
- Update `docs/automation/guide.md` when automation workflow behavior changes.
- Update `docs/automation/examples.md` when a reusable example pattern changes.
- Update `run-learnings.md` files only when a run created a new lesson worth preserving.
- Keep inventory details in `inventory/` rather than mixing them into workflow guides.
## Path Conventions
- Prefer actual repo paths under `/home/aw/code/cds/atvm/...` in documentation.
- Keep top-level navigation in `README.md` and `AGENTS.md`.
- Keep executable assets under `scripts/`.
## Archive Policy
- Preserve imported long-form notes under `archive/imported-notes/`.
- Do not rely on archived notes as the primary operational runbook when a current guide exists.
- Keep detailed listings available; reorganization should improve navigation, not remove information.

63
atvm/inventory/accounts-and-credentials.md Normal file
View File

@@ -0,0 +1,63 @@
# ATVM Accounts And Credentials
This file organizes the ATVM lab account and credential information that was preserved from the original long-form notes.
## CMC GCStage
- URL:
- `https://ui.gcstage.cloud.nonprod.cirrusdata.com/`
## CMC ATVM Test Account
- User:
- `qatest.atvm@cirrusdata.com`
- Password:
- `fEMQ9N4KEfYyFnS`
- 2FA registration code:
- `C7FIIZV6SGZ67XGATFN7YQHEJI6BHGPL`
- CMC API token:
- `lNSrdRkqJWJlxierQTcoIiZppmORigyZiXQsHhGiJtmnGKCGAJTwMpRsqKSLgKdSHTXDpYPtPyszDZTvOvGEoXuBZFdkTkxyvNTlSxYKLsBcEpTbRkRQkQppdwBhaUyauPZxolHmOTeZOVIAZCnyGBTQjVxsSaaJXwaguIgeFbYctONcCBhayNTruJOtYJGYbLBESrRkDMuHZBCpZoMeKgeNjifqdROMYhKCyUFhVhaOvFSWizFNlQZYRInscFw`
- Xray location for failed tests:
- `../cdc-e2e/cypress/cmcXray`
## CMC User-Administration Test Account
- User:
- `qatestuser.atvm@cirrusdata.com`
- Password:
- `fEMQ9N4KEfYyFnS#1`
- 2FA registration code:
- `WQ6F6NIDSIY57BLHMTTVBMIXZI44G5F7`
- CMC API token:
- `DQYjVaDFbsFDcfVEoIZNbiiWLkoMOMSzoFyVKkFxwvribCrLiUqEwVVVZDurapQTiJEuGYcJVOvFnXSmcIpwXIJDzPGiidaQwMfbPGirmpKsVZrPQeHAgbABpyNjiDxSOzmGWvDpBEHdrnYceSxtkvYkhSGPOolWOUYdblCuzfnFCuwLtOklRZGsZRAEbBfeJPyrfnZCSMcGBRoVkMRXttYcJKEwOqzlKKKXWtyKKirfyOpSpTlnREUQlgwjGSB`
## Red Hat Free Subscription Account
- User:
- `qatest.atvm@cirrusdata.com`
- Password:
- `rh@CDSi101cdsi2012`
- Registration command:
- `subscription-manager register --username qatest.atvm@cirrusdata.com --password rh@CDSi101cdsi2012`
- Re-register sequence:
```none
# subscription-manager remove --all
# subscription-manager unregister
# subscription-manager clean
# subscription-manager register --username qatest.atvm@cirrusdata.com --password rh@CDSi101cdsi2012
```
- Renewal link:
- `https://developers.redhat.com/products/rhel/download#publicandprivatecloudreadyrhelimages`
## Related Host Credentials
- ATVM controller host:
- `root / atvmcdsi2012`
- `cypressuser / atvmcypress`
- Linux repository VM:
- `root / cdsi2012`
- vCenter `192.168.0.201`:
- `administrator@qalab.cdsi.local / CDSi101!`
- ESXi `192.168.1.165`:
- `root / CDSi101!`
- ESXi `192.168.1.166`:
- `root / CDSi101!`
## Preserved Source
- Full original notes remain in:
- `archive/imported-notes/cypress-automation-for-cmc.md`

60
atvm/inventory/infrastructure.md Normal file
View File

@@ -0,0 +1,60 @@
# ATVM Infrastructure
This file organizes the main infrastructure reference that was previously embedded in the long-form ATVM notes.
## Storage / Appliance
- Primary DGS Phoenix Server: `192.168.1.172`
- Replica DGS Phoenix Server: `192.168.1.89`
- Primary DGS web login:
- `admin / cdsi2012DGS172`
- The preserved detailed storage and appliance notes remain in:
- `archive/imported-notes/cypress-automation-for-cmc.md`
## VMware
- Active vCenter Server Appliance: `192.168.0.201`
- vCenter login:
- `administrator@qalab.cdsi.local / CDSi101!`
- Primary ESXi hosts:
- `192.168.1.165`
- `192.168.1.166`
- ESXi `192.168.1.165`:
- SSH: `root / CDSi101!`
- IPMI: `admin / cdsi2012`
- ESXi `192.168.1.166`:
- SSH: `root / CDSi101!`
- IPMI: `admin / cdsi2012`
- Legacy VMware environment details are preserved in the archived notes.
## ATVM Controller Host
- Controller host reference:
- `atvm-cypress-vm`
- `atvm-cypress-vm-1`
- Controller IP:
- `192.168.3.190`
- Controller credentials:
- `root / atvmcdsi2012`
- `cypressuser / atvmcypress`
- Current noted controller variants:
- `atvm-cypress-vm`
- `atvm-cypress-vm-1`
## Offline Repository Host
- Repository host:
- `linux-repo-vm`
- Repository IP:
- `192.168.3.199`
- Repository credentials:
- `root / cdsi2012`
- Repository content families include:
- RedHat
- Debian
- Suse
## Detailed Source Sections
- Storage Array / Appliance
- VMware Hosts
- ATVM Cypress Host
- Offline DVD Linux Repository
These sections are preserved in full at:
- `archive/imported-notes/cypress-automation-for-cmc.md`

19
atvm/inventory/overview.md Normal file
View File

@@ -0,0 +1,19 @@
# ATVM Inventory Overview
This directory contains the durable environment reference for the ATVM workspace.
## Inventory Files
- `infrastructure.md`
- environment overview, storage, VMware, ATVM controller host, and offline repo summary
- `accounts-and-credentials.md`
- test accounts, credentials, tokens, and subscription details used in this environment
- `reserved-ips.md`
- reserved IP ranges and per-IP role assignments
- `specialized-reference.md`
- map of the preserved detailed sections for zoning, ISO inventory, guest image inventory, guest configuration, gold images, and temporary clients
## Preserved Source
- Full original notes are preserved at:
- `archive/imported-notes/cypress-automation-for-cmc.md`
Use the inventory files first for organized access, then use the archived source when you need the original full narrative and detailed listings in their original order.

30
atvm/inventory/reserved-ips.md Normal file
View File

@@ -0,0 +1,30 @@
# ATVM Reserved IPs
This file indexes the reserved IP ranges and role assignments used in the ATVM environment.
## Key Reserved Range
- `192.168.3.190 - 199`
- ATVM infrastructure
- `192.168.3.180 - 189`
- unit testing ATVM clones
## High-Use Addresses
- `192.168.3.190`
- ATVM Cypress controller host
- `192.168.3.191`
- ATVM source machine static IP target
- `192.168.3.192`
- H2H destination hosts
- `192.168.3.193`
- second source-machine static IP target set
- `192.168.3.194`
- second H2H destination host set
- `192.168.3.199`
- Linux repository VM
## Primary Source
The full reserved IP listing and per-IP notes are preserved in:
- `archive/imported-notes/cypress-automation-for-cmc.md`
## Relevant Archived Section
- `## __Reserved IP Address__`

24
atvm/inventory/specialized-reference.md Normal file
View File

@@ -0,0 +1,24 @@
# ATVM Specialized Reference Map
The archived ATVM source file still contains several specialized detailed sections that were preserved intact.
## Archived Source
- `archive/imported-notes/cypress-automation-for-cmc.md`
## Section Map
- `## __Zoning__`
- zoning details and SAN-related reference material
- `## VM Guest OS ISO Inventory`
- ISO inventory and media reference
- `## List of Available VM Guest OS Images:`
- guest image listing
- `## VM Guest OS Configuration - Linux`
- Linux guest setup and configuration reference
- `## Switch from SEL=disabled to SEL=enforcing`
- SELinux mode transition notes
- `## __VM Guest OS Gold Images__`
- gold image listings and notes
- `## Temporary Unit Test Clients`
- temporary client inventory
Use this file as a map when you need those detailed sections in the preserved archived notes.

0
atvm/atvm-setup-script.sh → atvm/scripts/atvm-setup-script.sh
View File

0
atvm/run-atvm-setup-and-collect-log.sh → atvm/scripts/run-atvm-setup-and-collect-log.sh
View File