Documentation preview for 146bd37 is available at:

• https://pr-19009--mlflow-docs-preview.netlify.app/docs/latest/

@BenWilson2 I thought we would just rely on LiteLLM because we don't want to manage the custom mapping. Did we change the decision? At least we should not have both? If we need to maintain the static mapping anyway, we don't need to litellm-based backend handler and just share the config file between UI and backend.

@B-Step62 litellm responds with a list of all optional valid fields, but doesn't organize them into "these are the ones that are used together", hence the need to have the static mapping. It's not ideal, but it's better than having hard-mappings of all providers AND allows us to validate that the backend can support or not support a given provider (which is why for this version I surmised that allowing an editable connection configuration might be a bad idea for a random provider - a user wouldn't know until after having spent time configuring an endpoint that it's valid or not).

For the static mapping, I figured that it would be less confusing to users if we provided the auth groupings that are required for these providers instead of a full list of "choose the ones you know you need" to reduce the cognitive load when creating an endpoint with a given selectable configuration.

Open to hear some thoughts on alternatives here!

Btw, for provider specific configuration, can we reuse our configurations for existing gateway? These classes already specifies the necessary information to make a LLM call for a specific provider. We still need to rely on LiteLLM for models though.

@TomeHirata the config that we have in Gateway doesn't have the other fields that we want to use for UI to display for helper text / easily legible naming or information. They do contain the field mappings for validation, but I felt that it might be better to contain the full config for these special case providers in a single location (also didn't want to make a future deprecated portion of the code base linked to a new feature that would complicate cleanup in the future).

the config that we have in Gateway doesn't have the other fields that we want to use for UI to display for helper text / easily legible naming or information. They do contain the field mappings for validation, but I felt that it might be better to contain the full config for these special case providers in a single location

Understood. To share the context behind my question, we'll have two type of providers in our gateway: first tier support that MLflow owns schema unification, and second tier support that we'll use LiteLLM. For the first tier providers (openai, anthropic,...) we'll still reuse the existing gateway provider implementation and the per provider configuration should be consistent between the here and gateway provider implementation. Not a blocker, we can add more auth ways to the gateway implementation later.

@B-Step62 litellm responds with a list of all optional valid fields, but doesn't organize them into "these are the ones that are used together", hence the need to have the static mapping. It's not ideal, but it's better than having hard-mappings of all providers AND allows us to validate that the backend can support or not support a given provider (which is why for this version I surmised that allowing an editable connection configuration might be a bad idea for a random provider - a user wouldn't know until after having spent time configuring an endpoint that it's valid or not).

@BenWilson2 Hmm I'm still not following what is the intention of the current implementation.... according to the description you tried to add missing information (combination of optional fields), but if I read the logic of _get_credential_fields, we never use the hard-coded mapping in conjunction with the LiteLLM response.

If I read the code correctly, what current implementation does is

1. Get field configuration from LiteLLM via get_provider_fields.
2. If it returns some configuration, return it as is.
3. Otherwise, fallback to the static config.

Am I missing something? I don't see _PROVIDER_CREDENTIAL_MAPPING used anywhere else.

    get_provider_fields = _get_provider_fields()Add a comment on  lines R610 to R616Add diff commentMarkdown input:  edit mode selected.WritePreviewAdd a suggestionHeadingBoldItalicQuoteCodeLinkUnordered listNumbered listTask listMentionReferenceSaved repliesAdd FilesPaste, drop, or click to add filesCancelCommentStart a reviewReturn to code
    provider_fields = get_provider_fields(provider)

    if provider_fields and len(provider_fields) > 0:
        return [
            {
                "name": field["field_name"],
                "type": field.get("field_type", "string"),
                "description": field.get("field_description", ""),
                "required": True,
            }
            for field in provider_fields
        ]
    elif provider in _PROVIDER_CREDENTIAL_MAPPING:
        return _PROVIDER_CREDENTIAL_MAPPING[provider]

    return []

P.S. Re-read your comment above, it seems we are talking about different mapping. What I referred to is _PROVIDER_CREDENTIAL_MAPPING. It seems you are talking about _PROVIDER_AUTH_MODES, and I understand we need the latter as discussed offline.

@B-Step62 litellm responds with a list of all optional valid fields, but doesn't organize them into "these are the ones that are used together", hence the need to have the static mapping. It's not ideal, but it's better than having hard-mappings of all providers AND allows us to validate that the backend can support or not support a given provider (which is why for this version I surmised that allowing an editable connection configuration might be a bad idea for a random provider - a user wouldn't know until after having spent time configuring an endpoint that it's valid or not).

@BenWilson2 Hmm I'm still not following what is the intention of the current implementation.... according to the description you tried to add missing information (combination of optional fields), but if I read the logic of _get_credential_fields, we never use the hard-coded mapping in conjunction with the LiteLLM response.

If I read the code correctly, what current implementation does is

1. Get field configuration from LiteLLM via get_provider_fields.
2. If it returns some configuration, return it as is.
3. Otherwise, fallback to the static config.

Am I missing something? I don't see _PROVIDER_CREDENTIAL_MAPPING used anywhere else.

    get_provider_fields = _get_provider_fields()Add a comment on  lines R610 to R616Add diff commentMarkdown input:  edit mode selected.WritePreviewAdd a suggestionHeadingBoldItalicQuoteCodeLinkUnordered listNumbered listTask listMentionReferenceSaved repliesAdd FilesPaste, drop, or click to add filesCancelCommentStart a reviewReturn to code
    provider_fields = get_provider_fields(provider)

    if provider_fields and len(provider_fields) > 0:
        return [
            {
                "name": field["field_name"],
                "type": field.get("field_type", "string"),
                "description": field.get("field_description", ""),
                "required": True,
            }
            for field in provider_fields
        ]
    elif provider in _PROVIDER_CREDENTIAL_MAPPING:
        return _PROVIDER_CREDENTIAL_MAPPING[provider]

    return []

P.S. Re-read your comment above, it seems we are talking about different mapping. What I referred to is _PROVIDER_CREDENTIAL_MAPPING. It seems you are talking about _PROVIDER_AUTH_MODES, and I understand we need the latter as discussed offline.

WOW, yeah, I was 100% referring to the auth modes mapping. Sorry about that!
We're:

1. Requiring litellm to be installed
2. Needing the config to be compatible with the library interface

Having a 'safe fallback' is pointless and just is another vector for us to keep updated as new providers are added (or dropped).

@B-Step62 thanks for refocusing my attention on this. I'm going to remove the typed dict entry and the fallback mapping as it provides zero value and actually actively makes maintenance harder.

Thank you!