fix(cli): stop managed EC2 demo starting zero containers (#298)

[kylehounslow]

What

Fixes #298. A managed-mode npx @opensearch-project/observability-stack deploy provisioned AWS resources fine but started zero containers. docker compose up aborted at project validation with service "example-agent-eval-canary" depends on undefined service "opensearch": invalid compose project, so no telemetry ever reached OpenSearch.

Root cause

Two independent design choices combined into a version-skew bug.

1. Managed mode defines no local backend. The generated docker-compose.managed.yml includes docker-compose.examples.yml plus docker-compose.otel-demo.yml but defines only otel-collector. Telemetry ships to the remote OSIS pipeline via SigV4, so there is no local opensearch/prometheus.
2. The EC2 user-data cloned the stack at main HEAD with no pinned ref. A "pinned" CLI release still deployed whatever main looked like the day the instance booted.

Two services in the included files (example-agent-eval-canary, otel-demo-alerting-rules-monitors-init) depends_on a local backend. They were added to main after the CLI was tagged (cli-installer-v0.1.1, 2026-04-09), so the same CLI binary that worked in April started failing once those services landed. When a depends_on target isn't defined, Compose rejects the whole project.

Both services hardcode a local backend with no managed path (https://opensearch:9200 basic-auth; http://prometheus:9090 Cortex), so they don't belong in managed mode regardless.

Fix

• Gate both services behind a local-backends compose profile. Compose prunes a profiled-out service and its depends_on edges, so managed mode validates clean while the local path is unchanged.
• Default COMPOSE_PROFILES=local-backends in committed .env so a raw docker compose up keeps these services on. Managed user-data exports an empty COMPOSE_PROFILES to prune them.
• Pin the EC2 stack clone to cli-installer-v<version> (override via OBS_STACK_REF), falling back to the default branch if the ref is absent.
• Bump the CLI to 0.1.2 so the pin resolves to a tag that contains the gate (see release dependency below).

Release dependency (important)

The profile gate is the actual fix; the clone pin is hardening. But the two interact through the CLI version, and the ordering matters:

• The published CLI pins the clone to cli-installer-v${package.json version}.
• At 0.1.1, that tag predates both the offending services and this gate. So a 0.1.1 deploy avoids the crash only by cloning an April-vintage stack, the gate never runs, and users silently get a months-old stack.
• The gate only executes once the CLI clones a tag built from main with this PR.

This PR bumps package.json to 0.1.2 so the path is: merge, then a maintainer pushes the cli-installer-v0.1.2 tag (gated behind the release-approval environment), which publishes to npm. A 0.1.2 deploy then clones cli-installer-v0.1.2, which has the gate. Until that tag is cut, the fix is not live for npx users.

Tradeoff worth noting

Pinning the clone means stack fixes won't reach already-pinned CLI deploys until a new CLI tag ships. That's correctness over freshness, the right call for a reproducible demo installer, but worth stating.

Validation

• Managed mode (COMPOSE_PROFILES= empty): docker compose -f docker-compose.managed.yml config resolves 30 services, exit 0, both offenders pruned.
• Local mode via root docker-compose.yml with profile active: 40 services, both offenders and both backends present.
• Local mode with profile unset: offenders pruned (confirms the gate).
• Reproduced the original failure and the fix on a real docker compose run: un-gated → invalid compose project (zero containers); gated with empty profiles → otel-collector starts (Everything is ready, GRPC 4317 / HTTP 4318).
• CLI unit tests: 29/29 pass, including a new managed-mode test that runs docker compose config on the generated docker-compose.managed.yml and asserts the offenders are pruned.

Why CI didn't catch the original bug

Both e2e jobs exercise the local path only. e2e-compose runs root-compose where opensearch/prometheus exist, so the depends_on edges resolve. e2e-install runs install.sh with the local target and declines examples/otel-demo, so the offending files aren't even included, and the managed branch (ec2-demo.mjs) is never entered. Nothing validated the generated managed compose project. The new CLI test closes that gap at the config level.

A full managed npx deploy against live AWS/OSIS has not been run for this branch.

Follow-up (separate PR, not blocking this one)

OSIS data-plane warm-up: control-plane Status=ACTIVE does not mean the ingest endpoint accepts traffic. For several minutes after, the collector logs a wall of failed to make an HTTP request: ...: EOF on every export and OpenSearch stays empty, so a fresh deploy reads as broken even though it self-heals. Proposed fix: after ACTIVE, poll the ingest endpoint until it returns any HTTP response (401 to an unsigned probe means the data plane is up), time-boxed, warn and continue. Tracked separately.

TODO before marking ready for review

• After merge, cut the cli-installer-v0.1.2 tag so the published CLI clones a stack containing the gate. Without it, the fix is committed but not live for npx users.

[joshuali925]

thanks