Repository navigation
Give the chart image.digest, extra volumes and a Composio key - #781
Merged
Merged
Conversation
Three things a Kubernetes deployment did through extraEnv or a custom image now have values: - image.digest renders the image as repository:tag@digest, the form docs/releasing.md recommends, and refuses anything that is not sha256: and 64 hex characters. - config.extraVolumes and config.extraVolumeMounts reach the server and the routines and computer-culler CronJobs: the pods that include commonEnv and so load the configuration, tenant package included. Empty includes print nothing, so default renders are byte-identical to before on all five ci targets. - secrets.composioApiKey is written to the chart's Secret, and the server alone gets COMPOSIO_API_KEY from there, from a store that names composio-api-key, or optionally from an existingSecret. openbot.secretKeySource decides which, for any optional credential.
guidovizoso
requested review from
MikeRyanDev,
davidmckayv,
mxmzb and
tylerslaton
as code owners
October 13, 2026 12:31
guidovizoso
added a commit
that referenced
this pull request
Oct 13, 2026
#781 added openbot.secretKeySource for optional credentials, the same decision openbot.licenseTokenSource made for the licence alone: the chart's literal, a store that names the key, or an existingSecret referenced as optional. The licence now goes through it, and the licence-only helper is gone. Rendered output is unchanged in all five licence cases and on every ci target.
guidovizoso
added a commit
that referenced
this pull request
Oct 13, 2026
…lligence will refuse memory (#771) * Pass a licence token from a store to the server The chart emitted COPILOTKIT_LICENSE_TOKEN only when secrets.licenseToken was a literal. A token synced through externalSecrets, which ci/eks-values itself does, reached the Secret and never the pod, so a self-hosted deployment ran unlicensed with nothing saying why. openbot.licenseTokenSource now answers where the token comes from: the chart's own Secret, a store whose data names license-token, or an existingSecret the chart cannot read, where the reference is optional so a Secret without the key still starts. No source, no variable, as before for managed Intelligence. check-rendered-chart compared what containers demand with what the chart's own Secrets write, and not with what an ExternalSecret syncs. It now fails a render in which a store syncs a key nothing reads; with the old condition restored it fails eks and eks-sandbox on license-token. * Say at boot when Intelligence will refuse memory A self-hosted Intelligence without its own licence answers every runtime entitlement read with RUNTIME_ENTITLEMENTS_SELF_HOSTED_MISCONFIGURED and refuses memory, while conversations carry on and OpenBot's log is silent. The licence belonging on Intelligence's deployment as well as OpenBot's is the part that is easy to miss. The server now reads the runtime entitlement once at start-up, without waiting on it, and logs intelligence-entitlement-not-ready with the code and the fix for misconfigured, expired and unavailable answers, or intelligence-entitlement-unreadable when Intelligence cannot be asked. The self-host banner reads the same answer but only while it is enabled, so it could not be the thing that reports this. * Use openbot.secretKeySource for the licence token #781 added openbot.secretKeySource for optional credentials, the same decision openbot.licenseTokenSource made for the licence alone: the chart's literal, a store that names the key, or an existingSecret referenced as optional. The licence now goes through it, and the licence-only helper is gone. Rendered output is unchanged in all five licence cases and on every ci target.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Three things we had to work around deploying OpenBot on EKS, now as chart values. With none set, all five
ci/targets render byte-identical tomain(checksum annotations aside).image.digestSet it to the digest from a release's
container-images.jsonand the image becomesrepository:tag@digest, which is the formdocs/releasing.mdrecommends. The tag stays readable and the digest decides the pull. It refuses anything that isn'tsha256:plus 64 hex characters. All four images in a sandbox render (server, computer, culler, migrations) carry it.config.extraVolumes/config.extraVolumeMountsThese mount volumes on the server and the routines and computer-culler CronJobs: the pods that include
commonEnv, and so load the configuration and the tenant package. The main use is a tenant package from a ConfigMap withtenantPackageDirpointed at it, no custom image needed. They're appended after the existingsandbox-templatevolume where there is one. The migrations and attachments-culler jobs read only the database, so they don't get them.secrets.composioApiKeyWritten to the chart's Secret as
composio-api-key. Only the server receivesCOMPOSIO_API_KEY; the CronJobs don't, since only the API calls Composio. That follows the Learning token's "the server's alone" precedent. A new helper,openbot.secretKeySource, decides where the key comes from:secrets.composioApiKeyexternalSecrets.datanamescomposio-api-keysecrets.existingSecretoptional: trueref#771 adds a license-specific version of the same logic. Whichever merges second can move the license onto
openbot.secretKeySource.Checks
check-rendered-chart.tspass.releasing.md, and the changelog.