ncecere/terraform-provider-litellm v2.2.1

on GitHub

Upgrade Notes

• Patch release; no configuration changes are required. The tested backend moves from LiteLLM 1.104.0 to exactly LiteLLM 1.106.4. The published provider source remains registry.terraform.io/ncecere/litellm; Terraform >= 1.1.0, OpenTofu >= 1.6.0, and Go >= 1.24.0 for provider development are unchanged, and only optional write-only attributes require Terraform or OpenTofu >= 1.11.0. Published examples continue to constrain the provider to >= 2.0.1, < 3.0.0. No schema changes; existing HCL, state, IDs, and imports remain valid.
• litellm_model: when LiteLLM no longer returns a configured additional_litellm_params_json key, refresh now reports drift instead of failing, and restoring the key replaces the model (see Fixed). Set context-window limits such as max_input_tokens with additional_model_info or additional_model_info_json.
• litellm_credential: on a multi-replica proxy, a create can now take up to about 45 seconds while LiteLLM workers reload the new credential.
• litellm_key import of service-account keys: import now restores service_account_id. Because that attribute forces replacement, configure the matching service_account_id before importing a service-account key; a configuration that omits it now plans a replacement (and a new key secret) after import, where 2.2.0 planned none. Keys already in state are unaffected: ordinary refresh never backfills the value.

Security

• No security-sensitive behavior changes. New and changed diagnostics name only resource identities and fixed reasons; response bodies and values are never echoed.

Changed

• Development and release API contract: Re-pin the reproducible LiteLLM API contract and the disposable acceptance stack from v1.104.0 to v1.106.4 (ea7ca16dbc3904d9e59a9505f379a2ca3091821f). The exporter verifies v1.106.4's 37 lazy feature routers (new: model_insights and decisions). LiteLLM 1.106.4 adds 97 operations and removes none; all 97 are classified into existing reviewed categories (none are provider-managed), and every operation the provider calls is unchanged.

Fixed

• litellm_user SSO users (issue #311): Refreshing a user created through LiteLLM SSO login failed with "Unable to read user" since 2.1.0, because LiteLLM stores metadata such as {"auth_provider": null} and the strict map(string) projection rejected the null member. Explicit null members of user metadata are now treated as absent keys in the litellm_user resource and data source; every other non-string member still fails closed. Thanks to @ZubikIT for the patch.
• litellm_team boolean and number metadata (issue #299): When a tracked legacy metadata key held a JSON boolean or number, which the LiteLLM admin UI writes (for example disable_global_guardrails), refresh failed with "Team Read Failed" whenever metadata_json was configured, and every team update failed at its confirming read. The litellm_team data source failed the same way with "Invalid Team Response". Booleans and numbers are now read as their JSON text ("true"), so the change shows as normal drift. The legacy map still writes strings; manage such a key with metadata_json to send a real boolean.
• litellm_model refresh with a missing additional_litellm_params_json key (issue #297): When LiteLLM stopped returning a Terraform-owned top-level key in litellm_params (reported on LiteLLM 1.99 for max_input_tokens/max_output_tokens, and reproducible on any version by a full /model/update), every refresh failed with "Unable to read model: semantic LiteLLM parameters projection failed" and the model could only be recovered with terraform state rm. Ordinary refresh now reports the missing key as drift and the next apply restores it; as for any change to this attribute, that replaces the model. Create and update confirmations still require every configured key. The model documentation now notes that LiteLLM reads max_input_tokens and max_output_tokens from model_info, so those belong in additional_model_info or additional_model_info_json.
• litellm_key import of service-account keys (issue #313): Import left service_account_id null even though LiteLLM stores it in the key's metadata.service_account_id, so configuring the matching value planned a replacement, which issues a new key secret. Raw-token and hash imports now restore a non-empty string identity from the exact key's metadata; ordinary refresh never backfills an unconfigured value, and a malformed or contradictory identity fails with a content-free diagnostic while retaining state. Thanks to @suhaskaranth3 for the fix (#312).
• litellm_credential create on multi-replica LiteLLM (issue #298): LiteLLM keeps a new credential only in the process-local cache of the worker that created it until the other workers reload (30 seconds by default). The create confirmation sampled four fresh-connection reads back to back, so on several replicas it often saw only 404s, failed with "Credential Create Postflight Failed", and left "Uncertain Credential Ownership" state that blocked every later plan. While no sampled worker has returned the credential yet, the confirmation now keeps sampling with backoff for up to 45 seconds. A returned credential that does not match the request, a malformed response, or an identity mismatch still fails closed immediately.
• litellm_mcp_server on LiteLLM 1.106 (mcp_info_json): LiteLLM 1.106 adds computed is_public and is_public_explicit flags to every MCP server response's mcp_info, derived from the public-server allowlist rather than stored. Create and refresh of a server with mcp_info_json failed with "Inconsistent MCP Info Readback" or an inconsistent-result error. The derived flags are now removed before comparison, and LiteLLM 1.106's restricted virtual-key view (only those two flags) is treated as masked, like the 1.98 singleton. On LiteLLM 1.104 and earlier, a stored is_public is still read as before.
• litellm_team with a credential that cannot read the team (issue #310): With a provider credential that may create teams but not read them, such as a LiteLLM service-account key allowed to call /team/new, the create's read-back returns HTTP 403. The create then failed with "Team Creation Not Confirmed" and every later plan with "Team Read Failed", neither of which named the team or the cause. Both now report Team Not Readable With Provider Credential, naming the team ID and alias and explaining how to recover (switch to a credential that can read the team, terraform untaint, plan again). The other team create and read diagnostics also name the team. Accepted-create recovery state is still retained, so the team is never created twice.