[sshiv012]

What changes were proposed in this PR?

Pin the LiteLLM image in the Helm chart to the version single-node already uses.

The chart used the moving tag litellm/litellm:main-stable, so any pod restart could pull a new LiteLLM build without a Texera change. That is how the compressed-reply bug in #9080 reached our k8s deployment.

File	Before	After
bin/k8s/values.yaml	litellm/litellm:main-stable	ghcr.io/berriai/litellm:v1.83.10-stable
bin/k8s/values-development.yaml	litellm/litellm:main-stable	ghcr.io/berriai/litellm:v1.83.10-stable

bin/single-node/docker-compose.yml already uses ghcr.io/berriai/litellm:v1.83.10-stable, so both deployments now run the same LiteLLM. Future upgrades become a deliberate bump in both places.

This does not replace the proxy fix for #9080; it only stops surprise upgrades.

Any related issues, documentation, discussions?

Closes #9081
Related: #9080

How was this PR tested?

Chart (from a copy with helm dependency build):

helm lint . -f values.yaml               # 1 chart(s) linted, 0 chart(s) failed
helm lint . -f values-development.yaml   # 1 chart(s) linted, 0 chart(s) failed
helm template t . -f <each values file>  # renders image: ghcr.io/berriai/litellm:v1.83.10-stable

Deployed on local minikube: the chart's LiteLLM deployment, service, config and secret, plus the chart's Postgres and init script.

Check	Result
Image pulls from GHCR	ok
Prisma migrations against texera_litellm	"Migration diff applied successfully"
GET /health/liveliness	"I'm alive!"
GET /models with the chart's master key	200, lists claude-haiku-4.5, gpt-5-mini

Not tested: a successful chat completion (no provider API key on the test cluster), and a full Texera install on k8s. Minikube used the standard storage class instead of local-path for the Postgres PVC (test-only).

Was this PR authored or co-authored using generative AI tooling?

Generated-by: Claude Code (Claude Opus 5.5)

🤖 Generated with Claude Code

[sshiv012]

/request-review @bobbai00 @mengw15 - this is a quick review

[github-actions]

Automated Reviewer Suggestions

Based on the git blame history of the changed files, we recommend the following reviewers:

• Contributors with relevant context: @Ma77Ball
  You can notify them by mentioning @Ma77Ball in a comment.

[github-actions]

Backport auto-label report

This fix: PR was checked against each actively-supported release branch. A release/* label nominates a backport target; the branch's release manager approving this PR is what sends the fix there. The required Backport Approvals check stays red until every label below is approved, so each manager either approves or removes their own label — which is why the labels left on a merged PR are exactly the branches it reached.

Release branch	Analysis
✅ release/v1.3	Change detected on this branch — label added; this fix is queued to backport here. @mengw15 decides: approving sends the fix here, removing this label declines it. The merge waits on one or the other. Review requested.
✅ release/v1.2	Change detected on this branch — label added; this fix is queued to backport here. @xuang7 decides: approving sends the fix here, removing this label declines it. The merge waits on one or the other. Review requested.

Auto-label run.

[sshiv012]

@mengw15 can you merge it ?

[mengw15]

@mengw15 can you merge it ?

if there’s multiple release labels. We need all release managers’ approval before merging. @xuang7

[bobbai00]

@mengw15 @xuang7 seems the backport CI failed. Can you take a look ?