Issue Station
Sign In
Tools hereToolbox

litellm - ✅(Solved) Fix [Feature]: Support .spec.strategy in deployment.yaml in litellm helm chart [1 pull requests, 1 comments, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
BerriAI/litellm#23161•Fetched 2026-04-08 00:38:13
View on GitHub
Comments
1
Participants
1
Timeline
5
Reactions
0
Author
rjduffnerrjduffner
Participants
rjduffnerrjduffner
Timeline (top)
cross-referenced ×2closed ×1commented ×1labeled ×1

Fix Action

Fixed

PR fix notes

PR #23168: Add Abilty To Set strategy From values Files

Description (problem / solution / changelog)

Relevant issues

Fixes #23161

Pre-Submission checklist

Please complete all items before asking a LiteLLM maintainer to review your PR

  • I have Added testing in the tests/test_litellm/ directory, Adding at least 1 test is a hard requirement - see details
  • My PR passes all unit tests on make test-unit
  • My PR's scope is as isolated as possible, it only solves 1 specific problem
  • I have requested a Greptile review by commenting @greptileai and received a Confidence Score of at least 4/5 before requesting a maintainer review

CI (LiteLLM team)

CI status guideline:

  • 50-55 passing tests: main is stable with minor issues.
  • 45-49 passing tests: acceptable but needs attention
  • <= 40 passing tests: unstable; be careful with your merges and assess the risk.

  • Branch creation CI run
    Link:

  • CI run for the last commit
    Link:

  • Merge / cherry-pick CI run
    Links:

Type

🆕 New Feature

Changes

Allows spec.strategy to be set from the values files so we don't need kustomize to override.

Changed files

  • deploy/charts/litellm-helm/templates/deployment.yaml (modified, +4/-0)
  • deploy/charts/litellm-helm/tests/deployment_tests.yaml (modified, +25/-0)
  • deploy/charts/litellm-helm/values.yaml (modified, +8/-0)
RAW_BUFFERClick to expand / collapse

Check for existing issues

  • I have searched the existing issues and checked that my issue is not a duplicate.

The Feature

Kubernetes Deployment manifests allow users to specify how pods are replaced via the .spec.strategy fields. These are currently unavailable to modify in the deployment.yaml file in the helm chart. This feature would add this section to make it available for override.

Motivation, pitch

We would like to be able to deploy changes to LiteLLM pods without losing any availability. This means that we need to set our maxUnavailable to 0 and our maxSurge to something > 0

With both of these unsettable we are currently using kustomize to override this.

I may try to work on this here right away but will still setup an issue just to make sure it gets tracked should we lose it.

What part of LiteLLM is this about?

Other

LiteLLM is hiring a founding backend engineer, are you interested in joining us and shipping to all our users?

No

Twitter / LinkedIn details

No response

extent analysis

Fix Plan

To add the .spec.strategy fields to the deployment.yaml file in the helm chart, follow these steps:

  • Update the deployment.yaml file to include the .spec.strategy fields
  • Use Helm's built-in support for templating to make these fields overrideable

Example code:

spec:
  strategy:
    type: {{ .Values.deploymentStrategy.type | default "RollingUpdate" }}
    rollingUpdate:
      maxUnavailable: {{ .Values.deploymentStrategy.maxUnavailable | default 1 }}
      maxSurge: {{ .Values.deploymentStrategy.maxSurge | default 1 }}

In the values.yaml file, add the following:

deploymentStrategy:
  type: RollingUpdate
  maxUnavailable: 1
  maxSurge: 1

This allows users to override these values when installing the chart.

Verification

To verify that the fix worked, update the values.yaml file with the desired values for maxUnavailable and maxSurge, then reinstall the chart. The resulting deployment.yaml file should reflect the updated values.

Extra Tips

  • Make sure to update the chart's documentation to reflect the new overrideable values.
  • Consider adding validation to ensure that maxUnavailable and maxSurge are valid values.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#ssr#installation#tensor shape#autograd error#retriever error#indexing error#inference speed#output truncation#response parsing

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING