Feature Request: Support for MLflow Resource Remapping

[mr-brobot]

Problem Statement

When exporting/importing MLflow models that declare resources, the resource references might become invalid in the destination workspace. Resources like DatabricksServingEndpoint and DatabricksVectorSearchIndex use named string identifiers, so a model logged in workspace A with references to prod.agents.my_index will fail when deployed in workspace B if that index exists by a different name.

Background

MLflow's resources parameter allows models to declare dependencies on external services:

mlflow.pyfunc.log_model(
    python_model="agent.py",
    artifact_path="agent",
    resources=[
        DatabricksServingEndpoint(endpoint_name="my-llm-endpoint"),
        DatabricksVectorSearchIndex(index_name="catalog.schema.my_index"),
    ]
)

These resources are serialized into the MLmodel file:

resources:
  api_version: "1"
  databricks:
    serving_endpoint:
      - name: "my-llm-endpoint"
    vector_search_index:
      - name: "catalog.schema.my_index"

Note: The resources feature is part of open-source MLflow (defined in mlflow/models/resources.py), not a Databricks proprietary extension. The architecture includes a generic Resource base class with target_uri field, though currently only Databricks resource types are implemented.

Current Behavior

When using mlflow-export-import to copy a model with resources:

1. Export: Resources are preserved in the exported MLmodel file
2. Import: Resources are copied as-is without validation or remapping
3. Deployment: Model serving fails because referenced resources don't exist in target workspace

Desired Behavior

Provide mechanisms to handle resource references during import:

1. Validation: Warn or fail if imported resources don't exist in target
2. Remapping: Allow users to specify source-to-destination resource name mappings
3. Documentation: Export a manifest of required resources for manual setup

Proposed Solutions

Resource Mapping

Accept a mapping file via CLI option that translates resource names:

import-model --resource-mapping resources_map.yaml ...

Example resource mapping file format:

# resources_map.yaml
databricks:
  serving_endpoint:
    "source-llm-endpoint": "dest-llm-endpoint"
  vector_search_index:
    "prod.agents.source_index": "prod.agents.dest_index"

Pros: Explicit, repeatable, scriptable
Cons: Requires user to prepare mapping file

Resource Validation

Add --validate-resources flag that checks if resources exist in target without failing:

import-model --validate-resources ...
# WARNING: Resource 'source-llm-endpoint' not found in destination workspace

Pros: Non-breaking, informative
Cons: Doesn't solve the problem, just surfaces it