deploy: wait for network-agent readiness in one-click startup

[xiongxz]

Fix one-click startup racing network-agent readiness.

up.sh and up-compute.sh previously started network-agent and immediately continued with the rest of the stack. On slower hosts, Cubelet can start while network-agent is still coming up, which can leave Cubelet-dependent services unavailable during template artifact distribution. In that case template creation can fail with:

cubemastercli run fail: artifact distribution failed on all 1 nodes: rpc error: code = Unimplemented desc = unknown service cubelet.services.images.v1.Images

This waits for the network-agent /readyz endpoint before starting Cubelet-dependent services, and exposes NETWORK_AGENT_READY_TIMEOUT so one-click deployments can tune the wait budget. The default Cubelet config also extends the internal network-agent initialization timeout to match the one-click startup budget.

Validation

bash -n deploy/one-click/scripts/one-click/up.sh deploy/one-click/scripts/one-click/up-compute.sh

Assisted-by: Codex:GPT-5.5

[kinwin-ustc]

/cubebot review

[github-actions]

Claude finished @kinwin-ustc's task in 1m 9s —— View job

---

Review Checklist

• Review code changes
• Analyze for bugs, security issues, and edge cases
• Post review feedback

---

Code Review: PR #304

This PR fixes a race condition where network-agent hasn't finished initializing by the time Cubelet starts, causing template artifact distribution to fail with rpc error: code = Unimplemented. The fix adds a readiness check (/readyz) on the network-agent before proceeding.

What Was Changed

File	Change
deploy/one-click/scripts/one-click/up.sh	+4 lines: NETWORK_AGENT_READY_TIMEOUT variable and wait_for_http call after network-agent start
deploy/one-click/scripts/one-click/up-compute.sh	+4/-2: same readiness wait, plus the new timeout variable
deploy/one-click/env.example	+1: documentation for NETWORK_AGENT_READY_TIMEOUT=120
Cubelet/config/config.toml	+2: network_agent_init_timeout = "120s" in the network plugin config

Positive Aspects

1. Correct diagnosis — The race is real. Starting Cubelet before network-agent has registered its gRPC service causes the Unimplemented error on the Images service. Waiting on /readyz before proceeding is the right fix.

2. Consistent pattern — Both up.sh and up-compute.sh use the same approach: start network-agent normally, then call wait_for_http before launching dependent services. The scripts remain structurally parallel, which is good for maintainability.

3. Good reuse of existing utilities — wait_for_http from common.sh (line 219) already handles retry loops, configurable delays, and curl -f error semantics. No new polling machinery was introduced.

4. Configurable timeout — NETWORK_AGENT_READY_TIMEOUT defaults to 120s but can be overridden via env or .one-click.env. This is essential because the timeout that works on a fast dev machine may be too short on a slower host.

5. Matched timeouts — network_agent_init_timeout = "120s" in config.toml aligns Cubelet's internal patience with the one-click startup script's readiness budget. Without this, Cubelet could internally give up on network-agent before the startup script's wait_for_http even notices a problem.

6. Documented in env.example — The new variable is added to env.example at line 106, making it visible to deployers tuning their configuration.

Potential Concerns

No -L on curl, but that's correct
The wait_for_http call uses curl -fsS without -L (follow redirects). This is fine — a /readyz endpoint should return 200 directly, not redirect. If it ever redirected, we'd want to know rather than silently follow.

Deadly error message references LOG_DIR
If network-agent fails to become ready:

die "network-agent did not become ready, check logs under ${LOG_DIR}"

This references ${LOG_DIR}, which is correct — the network-agent's stdout/stderr is redirected to "${LOG_DIR}/network-agent.log" by start_with_pidfile. The error message is actionable.

Edge case: network-agent goes down after /readyz passes but before Cubelet connects
The network_agent_init_timeout = "120s" in Cubelet's config handles this independently — Cubelet will retry connections for up to 120s before giving up. This is a reasonable safety net and doesn't depend on the one-click startup script's checks.

Security

No security concerns. The readiness check is against 127.0.0.1:19090 (localhost-only), no credentials are transmitted, and no filesystem changes are made during the check.

Nit

The NETWORK_AGENT_READY_TIMEOUT default is 120, and wait_for_http uses a 1-second delay between retries, meaning up to 120 HTTP requests will be made to /readyz in the worst case. This is negligible load on localhost but might be worth a brief comment noting that the delay is intentionally short so the first successful readiness probe isn't unnecessarily late. Not blocking.

Summary

This is a clean, focused fix for a genuine race condition. The implementation is consistent across both script variants, uses existing infrastructure, and has appropriate configurability. The matched timeouts between the startup script and Cubelet's internal config are a thoughtful touch.

---

| Branch: codex/wait-network-agent-readiness