mirror of
https://github.com/bytedance/deer-flow.git
synced 2026-10-26 21:26:39 +00:00
c5c0dfa54e
* fix(helm): wire PROVISIONER_API_KEY through the chart's app Secret The chart enables the sandbox provisioner by default and points config.sandbox.provisioner_url at it, but nothing rendered PROVISIONER_API_KEY. Since the provisioner started requiring the key (#4116) its verify_api_key middleware answers 401 to every /api/* request while the key is empty or mismatched, so a default install could not create a single sandbox. docker-compose was unaffected: it reads the key from .env. - secret-app.yaml generates the key on first install and preserves it across upgrades via lookup, like the other app secrets. - The provisioner and gateway Pods read it from that one Secret. The gateway env is required while provisioner.enabled (the default config references $PROVISIONER_API_KEY and the harness fails on an unset variable) and optional otherwise; existingAppSecret must carry it while the provisioner is enabled. - values.yaml sets sandbox.provisioner_api_key: $PROVISIONER_API_KEY; the README config example, the existingAppSecret key list, the _helpers.tpl comment and NOTES.txt document the key. - backend/tests/test_helm_provisioner_api_key.py pins the values, template source and docs directly and, with helm, the rendered env on both Deployments and the Secret key. * docs(changelog): link the Helm provisioner API key entry to #6365 * fix(helm): render the gateway's PROVISIONER_API_KEY only for the bundled provisioner An explicit env entry wins over envFrom, so emitting the chart-managed gateway env with provisioner.enabled=false overrode the PROVISIONER_API_KEY an operator supplies through `secrets` for an external provisioner with the generated, unrelated value, turning every sandbox request into a 401 on upgrade. The env is now rendered only while the bundled provisioner is enabled (no `optional` flag), leaving the external credential source untouched. Addresses the review on #6365. * fix(helm): keep the default config loadable with the bundled provisioner disabled The default config references $PROVISIONER_API_KEY unconditionally and the harness refuses to start on an unset variable, so with provisioner.enabled=false and no external key the gateway failed at startup instead of booting and only failing sandbox calls at use time, as the chart did before the key existed. The harness resolves an empty variable to "", so the gateway Deployment now injects an empty PROVISIONER_API_KEY in that mode. The entry stays omitted when an external key arrives through `secrets` or `existingSecret`, since an explicit env entry would override the envFrom value. Tests cover the disabled/no-key, disabled/`secrets` and disabled/`existingSecret` renders plus the resolver contract. Addresses the review on #6365. * fix(helm): default PROVISIONER_API_KEY in the gateway start command when the bundled provisioner is off Treating the presence of `existingSecret` as proof that it carries PROVISIONER_API_KEY left the common case of a user-managed provider Secret holding only model keys with an unset variable, so the default config's $PROVISIONER_API_KEY reference still stopped the gateway at startup. The chart cannot see inside that Secret and an explicit env entry would override an envFrom value, so the explicit empty env is replaced by a shell default in the gateway start command, rendered only with provisioner.enabled=false: `export PROVISIONER_API_KEY="${PROVISIONER_API_KEY:-}"` leaves a supplied key untouched and turns an unset variable into "", which the harness resolves to an empty string. Tests run the extracted prefix through sh for both cases and cover the no-key, `secrets` and `existingSecret` renders. Addresses the review on #6365. --------- Co-authored-by: Willem Jiang <willem.jiang@gmail.com>