Skip to content

feat(container): update image ghcr.io/berriai/litellm-database (v1.103.2 → v1.104.0) #1629

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
gtw2 merged 1 commit into from
Oct 4, 2026
Merged

feat(container): update image ghcr.io/berriai/litellm-database (v1.103.2 → v1.104.0) #1629

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion kubernetes/apps/llm/litellm/app/litellmproxy.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -8,7 +8,7 @@ spec:
# database, so the LiteLLMModel CRs stay the source of truth and a database
# restore cannot resurrect a model that was deleted from git.
applyMode: file
image: ghcr.io/berriai/litellm-database:v1.103.2@sha256:bf6d8e366f41dfe44bffad59d996f4753710e0529e5ff648c2305829835c2ab7
image: ghcr.io/berriai/litellm-database:v1.104.0@sha256:fbe28229d2d02181c0a7d9df9599de614b491f3d897d2d7da18404f088310218

@banjo-bot banjo-bot Bot Oct 4, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

v1.104.0 (backported to v1.103.3 too) flips ENFORCE_PRISMA_MIGRATION_CHECK to default true: a failed Prisma migration at boot now exits 1 instead of letting the pod start in a degraded state (BerriAI/litellm#44205, #44206). This deployment runs replicas: 2 against a shared postgres17 DB with no ENFORCE_PRISMA_MIGRATION_CHECK or USE_V2_MIGRATION_RESOLVER override here, so it's relying entirely on upstream defaults for safe concurrent migration on rollout. The v2 resolver is also now default (#42105) with its own replica-coordination fix (#40932), which is what makes concurrent migration from 2 replicas safe in the first place — but crossing this enforcement default-flip for the first time is exactly where a pre-existing partially-applied migration (e.g. the two SpendLogs index migrations rewritten in #44205) would now block startup instead of being tolerated. Worth watching the rollout for CrashLoopBackOff; if it happens, the fix is upstream's SpendLogs index runbook + prisma migrate resolve --applied <name>, not a config change here.

replicas: 2
service:
port: 4000
Expand Down
Loading