Skip to content

docs(k8s-install): OHE-3033 fix the bundled object store values - #691

Open
aivong-openhands wants to merge 1 commit into
mainfrom
aivong/fix-bundled-store-values
Open

docs(k8s-install): OHE-3033 fix the bundled object store values#691
aivong-openhands wants to merge 1 commit into
mainfrom
aivong/fix-bundled-store-values

Conversation

@aivong-openhands

@aivong-openhands aivong-openhands commented Aug 5, 2026

Copy link
Copy Markdown
Contributor

Why

The Step 3 values tell operators to configure the bundled object store with filestore.ephemeral: true, and the chart has no such key. It was removed on 2026-08-04 by OpenHands/OpenHands-Cloud#1015, a breaking chart change that replaced it with minio.enabled and a flat filestore config; the docs update did not travel with it, so the published page has been wrong since. Following the page as written leaves an install with no object store at all: ephemeral is silently ignored because unknown values are accepted without warning, minio.persistence.enabled configures a subchart that minio.enabled never deploys since it defaults to false, and filestore.type falls back to its gcs default. Nothing errors, and the app comes up with an empty FILE_STORE. The bundled store needs minio.enabled: true together with filestore.type: s3, which is what the chart's own values comment says, so this sets both and explains why enabled is the load-bearing one.

The external-S3 example on the EKS page sets the same non-existent key to false. Harmless there, since the rest of that block is correct and an ignored key changes nothing, but it implies the key exists and is worth removing while it is in hand.

Validation

  • Rendered the published values against the shipped chart, and they produce no object store — zero MinIO resources, no AWS_S3_ENDPOINT, and FILE_STORE resolving to google_cloud. So an operator following the page today is silently configured for GCS on a cluster with no GCS credentials, which is worse than an obvious failure.
  • Rendered the corrected values, which produce the store the page describes — a MinIO Deployment, its bucket Job, a bound-on-install PersistentVolumeClaim, two Services, and the app receiving FILE_STORE=s3 with AWS_S3_ENDPOINT=http://<release>-minio:9000.
  • Confirmed on a running install, not only by rendering — a Kubernetes cluster running exactly these three values has MinIO 1/1 with its claim bound, the app pointed at it, and several thousand conversation objects written and read back through it.
  • Swept the rest of the enterprise docs — the only remaining ephemeral mentions are sandbox ephemeral-storage sizing, which is a different and correct setting.

This PR was drafted by an AI agent on behalf of the user.

@mintlify

mintlify Bot commented Aug 5, 2026

Copy link
Copy Markdown

Preview deployment for your docs. Learn more about Mintlify Previews.

Project Status Preview Updated (UTC)
all-hands-ai 🟢 Ready View Preview Aug 5, 2026, 3:46 PM

💡 Tip: Enable Workflows to automatically generate PRs for you.

@aivong-openhands aivong-openhands changed the title docs(k8s-install): PLTF-1250 fix the bundled object store values docs(k8s-install): OHE-3033 fix the bundled object store values Aug 5, 2026
Step 3 told operators to set filestore.ephemeral: true, a key the chart no longer
has. It was replaced with minio.enabled and a flat filestore config by #1015 on
2026-08-04, and the docs update did not travel with that change.

Following the page left an install with no object store: the unknown key was
silently accepted, minio.persistence configured a subchart that minio.enabled
never deployed because it defaults to false, and filestore.type fell back to gcs.
Nothing errored and the app came up with an empty FILE_STORE.

Sets minio.enabled: true and filestore.type: s3, the pair the chart's own values
comment names, and says which one does the deploying. Also drops the same
non-existent key from the EKS page's external-S3 example, where it was harmless
but implied the key exists.
@aivong-openhands
aivong-openhands force-pushed the aivong/fix-bundled-store-values branch from 886db3f to 333ff50 Compare August 5, 2026 15:52
@aivong-openhands
aivong-openhands marked this pull request as ready for review August 5, 2026 16:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant