docs(proposal): add dynamic environment variable injection design proposal#597
docs(proposal): add dynamic environment variable injection design proposal#597furykerry wants to merge 1 commit into
Conversation
…posal Introduce a design proposal for per-claim environment variable injection into pre-warmed sandboxes via run_with_envs.sh wrapper. Key design decisions: - EnvVarsInjectionPolicy field (None default, Auto opt-in) on SandboxClaim and Sandbox CR spec controls injection behavior - run_with_envs.sh wraps container command and exec probes; supports probe mode (--probe) returning success before env initialization - Env vars persisted to AnnotationInitRuntimeRequest annotation only (not container spec) to avoid triggering in-place upgrade - postStartHook and non-exec probes (httpGet/tcpSocket) are not wrapped (documented limitations) - Secrets excluded from envVars; use traffic-extension SecurityProfile - Environment restoration after resume/upgrade via Initialize() hook Signed-off-by: 守辰 <shouchen.zz@alibaba-inc.com>
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #597 +/- ##
==========================================
- Coverage 79.84% 79.70% -0.14%
==========================================
Files 202 205 +3
Lines 14795 15282 +487
==========================================
+ Hits 11813 12181 +368
- Misses 2552 2658 +106
- Partials 430 443 +13
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
| - Secret/ConfigMap-based env var sources (future enhancement). | ||
| - Env var injection without agent-runtime (envd-less path). | ||
| - In-place upgrade support for env var changes on the Sandbox CR. Currently, modifying the | ||
| container spec triggers in-place upgrade which does not support env var updates. |
There was a problem hiding this comment.
Add VM-based sandboxes (e.g. OSWorld) as a non-goal too. They have no container concept, so the run_with_envs.sh command-wrapping approach fundamentally does not apply.
3 participants
Ⅰ. Describe what this PR does
Add a design proposal for per-claim environment variable injection into pre-warmed sandbox pods.
The proposal introduces
run_with_envs.sh— a deferred execution wrapper that blocks the container's main command until the sandbox is claimed and env vars are written. Key design points:EnvVarsInjectionPolicyfield onSandboxClaimandSandboxSpec:None(default) orAuto(opt-in). No annotation-based toggle.Auto, the controller wraps the container command and exec probes (startupProbe,livenessProbe,readinessProbe) withrun_with_envs.sh. Probe mode (--probe) returns success immediately before env initialization, keeping pre-warmed pods healthy.AnnotationInitRuntimeRequestonly — not to the container spec — to avoid triggering the in-place upgrade path which does not support env var changes.Initialize()hook re-writes env vars to the filesystem after pod recreation.postStartHookand non-exec probes (httpGet,tcpSocket) are not wrapped. Secrets should usetraffic-extensionSecurityProfile instead ofenvVars.Ⅱ. Does this pull request fix one issue?
NONE
Ⅲ. Describe how to verify it
docs/proposals/20260701-dynamic-env-injection.mdⅣ. Special notes for reviews
EnvVarsInjectionPolicydefault isNoneto preserve backward compatibility —Autois opt-in.postStartHookand non-exec probe limitations are explicit user-facing constraints.