OK-5123 Add validate playbook and update readme

[GerryMandell]

Summary

Adds validate.yml, a new playbook that performs idempotent checks against target hosts to confirm the engine, Android SDK, SDK components, and OCI images are installed correctly.

Why

There hasn't been a built-in way to verify a host is correctly provisioned after running the install playbooks. Operators have had to either:

• Trust that "playbook exited 0" means the install actually worked
• SSH in and manually check paths / run CLI commands
• Roll their own shell-based validation in their own automation

validate.yml makes the verification explicit and reusable — a single playbook anyone (CLI users, CI workflows, customers integrating this orchestration into their own pipelines) can run to confirm a host is in the expected state.

Design

• Uses ansible.builtin.stat for path existence checks and ansible.builtin.command for the OCI image list query — no become or shell module calls. Safe to run alongside other workflows without side effects.
• Tag-aware so callers can run subsets matching each phase of the install sequence:

Command	What it checks
--skip-tags sdk-components,images	Engine binary + Android SDK base install
--tags sdk-components	Android platform and system images installed via sdkmanager_install.yml
--tags images	OCI image is present in the engine image list

• Parameterized with sensible defaults so it works out of the box but can be customized:
  • platform — Android platform to check for (default: android-36)
  • image_types — Comma-separated list of system image types (default: default,google_apis)
  • image_name — Substring (or name:tag) to look for in the engine's image list (default: sequoia)

Test plan

• On a clean host (no engine, no SDK), run validate.yml — confirm it fails on the first missing check
• Run install_engine.yml + install_android_sdk.yml, then run validate.yml --skip-tags sdk-components,images — confirm passes
• Run sdkmanager_install.yml, then run validate.yml --tags sdk-components — confirm passes
• Run pull_image.yml with a known image, then run validate.yml --tags images -e "image_name=<that-image>" — confirm passes
• Run validate.yml (full, no tags) on a fully-provisioned host — confirm all checks pass and the summary line is displayed

[spikeburton]

General question about this one - this specifically validates that both the primary tooling (Engine) is installed, as well as Android specific tooling (considered "additional").

As not everyone will install the Android tooling, does it make sense to separate this into different roles/playbooks?

Or - alternatively - add tags, so at least you can pass --skip-tags for the Android tooling validation?

[spikeburton]

Instead of having the tasks directly in the playbook - I would move them to a role. I would also add role defaults for the paths.

In fact, we have a role already that defines the default path here. See how this is included in another role (example here)

Similar comment for the other paths (Java, run-avd script etc.) - we have vars defined for these in the roles

[GerryMandell]

• Created roles/validate with tasks, defaults, and meta (depends on android_sdk_common, mirroring sdkmanager_install)
• Moved Java home to android_sdk_common as android_sdk_common_java_home, removed install_android_sdk_java_home from install_android_sdk
• Removed validate_java_path from validate defaults
• Engine / run-avd / socat paths kept as validate_* defaults

[spikeburton]

Do we need this comment?

Also - below we run orka-engine image list. Which communicates with the server over the socket. So this check is not necessary ... if image list fails, the server is not running

[GerryMandell]

Yeah this is not a good comment to leave in. Absolutely should take it out.

As for the engine binary existence and running orka-engine image list, these are used in 2 different places throughout the validation workflow I was working on in the monorepo. Checking for the binary after installation, and then checking orka-engine image list after pulling an image.

Here is the workflow in the monorepo for more context. https://github.com/macstadium/monorepo-dev/pull/23537/changes