feat(openobserve-standalone): add values.schema.json

[arunesh-j]

Summary

• Adds values.schema.json for the openobserve-standalone chart so the ZopDay helm-import settings form can render for it (it was previously blank — "No configurable settings for this release").
• Exposes CPU/memory requests+limits and persistence size under compute, following the category conventions used by other charts (e.g. redis, cockroachdb).
• Image tag is kept fixed (non-mutable) under runtime — matching the runtime category precedent from redis/cockroachdb's version field and litellm's image field (not outline/wordpress, which place image under compute instead).
• Root auth credentials (ZO_ROOT_USER_EMAIL/ZO_ROOT_USER_PASSWORD) are intentionally left out of the schema — rendering them as editable plaintext fields would surface the release's live secret in the form.

Test plan

• Verified locally: ran helm-manager pointed at this branch, confirmed /helm/openobserve-standalone returns only the compute group (resources + persistence) — image has no mutable fields so it's correctly dropped from the rendered form entirely, not just hidden
• Confirmed in the ZopDay UI (local frontend, local helm-manager) that the Settings tab for an imported openobserve-standalone release renders the Compute fields correctly, with no other tabs

[jatintalgotra-zd]

The schema is valid JSON and the resources / persistence fields map correctly to how the statefulset consumes values (.Values.resources, .Values.persistence.size). The auth-exclusion reasoning is sound. Two things need attention before merge.

1. (Blocker) The config / advanced block looks like a stray test artifact

"config": {
  "category": "advanced",
  "properties": {
    "ZO_LOCAL_MODE_STORAGE": { "enum": ["disk"] },
    "ZO_S3_BUCKET_NAME":     { "enum": ["o2-dev-bucket"] }
  }
}

• Not in the PR description. The summary carefully enumerates image / resources / persistence / auth. config is never mentioned — it reads as leftover from local testing.
• Pins a dev-specific value on main. ZO_S3_BUCKET_NAME is enum-locked to "o2-dev-bucket". A chart-root values.schema.json is enforced by Helm itself on install/upgrade/template — so any deploy that overrides the bucket to a real one fails validation, not just the UI. Hardcoding a dev bucket as the only allowed value doesn't belong in a shared chart.
• It's a no-op in this chart's mode. Defaults are ZO_LOCAL_MODE: "true" + ZO_LOCAL_MODE_STORAGE: "disk", so S3 isn't used at all. Exposing (and locking) the bucket name is meaningless here.

Recommend deleting the entire config block.

2. (Clarify) Test plan contradicts the schema

The test plan says the form shows "Compute: resources + persistence, no Runtime/Environment tabs." But the schema declares image under category: "runtime" and config under category: "advanced". If the form renders a tab per category, a Runtime tab (image) and an Advanced tab (config) will appear. Either the test claim is stale or these categories shouldn't be present. Removing config (#1) resolves half of it; please confirm whether the image/runtime tab is intended.

3. (Minor) Categorization wording

The PR says image is kept fixed "matching outline/wordpress." Those charts place image under compute; this puts it under runtime. runtime is fine (it matches redis/cockroachdb version and litellm image) — just the "matching outline/wordpress" justification is imprecise.

4. (Optional) No required or pattern validation

redis constrains cpu/memory with regex patterns (^[0-9]+m$) and required arrays. This PR omits both. cockroachdb also omits them, so it's acceptable — but adding patterns would catch bad UI input earlier.

Nothing to raise on the mutability of resources / persistence.size or the secret-exclusion decision — those are correct and consistent with redis / cockroachdb.

[arunesh-j]

Thanks for the thorough review — addressed:

1. (Blocker) `config`/`advanced` block removed entirely in 166fbe6. Agreed — it was leftover from local testing and would've enum-locked `ZO_S3_BUCKET_NAME` for every real deployment via Helm's own `values.schema.json` enforcement on install/upgrade/template.

2. Tab-rendering concern — verified empirically rather than guessing: I ran the local helm-manager against this branch and curled `/helm/openobserve-standalone` directly. With `image.tag` non-mutable and `config` now removed, the returned `form` array contains only the `compute` group (resources + persistence) — no `runtime` or `advanced` entries appear at all. `populateFormFieldsFromSchema` drops a top-level object entirely when none of its descendants carry `mutable: true`, so a category with zero mutable fields doesn't produce an empty tab — it produces no tab. Confirmed the same in the ZopDay UI locally: only the Compute tab shows.

3. Wording fixed in the PR description — the "matching outline/wordpress" line was imprecise (those charts place `image` under `compute`); updated to reference `redis`/`cockroachdb`'s `version` and `litellm`'s `image` as the actual `runtime`-category precedent.

4. Pattern/required validation — leaving as-is per your note that `cockroachdb` omitting it is acceptable precedent. Happy to add if you'd still like it.

[jatintalgotra-zd]

Re-reviewed after 166fbe6d. The blocker is resolved.

• (1) config / advanced block — removed. The schema now exposes only image (runtime), resources (compute), persistence (compute). No dev-specific values pinned, nothing enforced by Helm that would break a real deploy. ✅
• (3) categorization / (4) validation — acceptable as-is.

JSON is valid; resources and persistence.size map correctly to the statefulset. LGTM.

One small non-blocking note: image is still category: "runtime" with all fields non-mutable, so if the form renders a tab per category the release will show a read-only Runtime tab — slightly at odds with the test plan's "no Runtime tab". Not worth holding the PR; just confirm that read-only Runtime tab is acceptable in the UI.

[arunesh-j]

Added `values.schema.json` for `scylladb` too (also had none — same "no configurable settings" gap). Mirrors `redis`'s structure: `image` under `runtime`, `resources`/`diskSize` under `compute`, `editDisabled` on diskSize. Left `scylladbRootPassword` and `config.cluster_name` out of the schema for the same reason as openobserve's auth exclusion — no live secrets as editable plaintext.

Verified locally against this branch: `/helm/scylladb` renders Runtime (image) + Compute (resources + diskSize), no auth fields.

[jatintalgotra-zd]

Re-reviewed after the scylladb chart was added (84ee4b6e, 8bfd1b58). The openobserve-standalone schema is unchanged and still good. Notes below are all on the new scylladb/values.schema.json.

Correct: helm lint passes; image, resources.requests/limits.{cpu,memory}, and diskSize all map to what statefulset.yaml actually reads. Defaults match values.yaml, and it includes pattern + required validation. scylladbRootPassword is excluded, consistent with the auth-secret exclusion in openobserve. 👍

Main point — services was dropped, which diverges from the sibling charts.
Commit 8bfd1b58 removed services to fix helm lint, but the real cause of that failure is the dangling services: (a null value) at the end of values.yaml — null fails type: array. The sibling charts keep services in the schema:

• redis and cockroachdb both expose services (category runtime, optional) and just don't set a null default.
• scylladb's own templates are built around it — database-pod.yaml, database-secret.yaml, configmap.yaml, and init-script-config-map.yaml all range over .Values.services to provision per-database resources.

So dropping services means the deploy form won't expose the config that actually creates scylla databases/users — inconsistent with redis/cockroachdb. Cleaner fix: keep services in the schema and default it to [] in values.yaml (or remove the dangling services: line); lint then passes without hiding the field.

If scylladb is intentionally standalone-only with no logical DBs, then dropping it is fine — please just confirm the intent.

Minor: image defaults to scylladb/scylla:latest as a free mutable string, whereas openobserve in this same PR pins an explicit version via enum. :latest gives non-reproducible deploys — consider pinning a concrete tag.

Not blocking — it lints and deploys. Just confirm the services intent before merge.