[BUG] Changing the Tracking's URI doesn't change the Artifact's URI

Willingness to contribute

• Yes. I can contribute a fix for this bug independently.
• Yes. I would be willing to contribute a fix for this bug with guidance from the MLflow community.
• No. I cannot contribute a bug fix at this time.

System information

• Have I written custom code (as opposed to using a stock example script provided in MLflow):
• OS Platform and Distribution (e.g., Linux Ubuntu 16.04): docker continuumio/miniconda3 on Azure’s Compute Instance
• MLflow installed from (source or binary): R’s install_mlflow()
• MLflow version (run mlflow --version): 1.22.0
• Python version: 3.9

Describe the problem

I am trying to use MLFlow on Azure’s ML Compute Instances to track my experiments in R. The tracking URI set by the compute instance has the scheme azureml://... which is not supported by MLFlow. Azure has a package to enable support on Python, but as my code is in R, I found that I need to manually change the URI to https://... to make logging work.

Changing the Tracking URI works correctly (i.e. I can log params and metrics) when setting the MLFLOW_ARTIFACT_URI environment variable or when calling mlflow_set_tracking_uri(), but it doesn’t seem to have any effect on the artifact URI (related to #3469) as it is still using the old scheme (the one starting with azureml://), so I am not able to log artifacts.

I see no method on MLFlow’s R API to change the artifact’s URI scheme (and #2577 seems to be related, but I created a different issue as I don’t want to re-define the whole URI, but just the scheme) and workarounds are possible at least while Microsoft implements an R API (I hope it happens someday), but I was wondering if MLFlow has any suggestion on this or if a new feature that could help this use-case is in the plan.

What component(s), interfaces, languages, and integrations does this bug affect?

Components

• area/artifacts: Artifact stores and artifact logging
• area/build: Build and test infrastructure for MLflow
• area/docs: MLflow documentation pages
• area/examples: Example code
• area/model-registry: Model Registry service, APIs, and the fluent client calls for Model Registry
• area/models: MLmodel format, model serialization/deserialization, flavors
• area/projects: MLproject format, project running backends
• area/scoring: MLflow Model server, model deployment tools, Spark UDFs
• area/server-infra: MLflow Tracking server backend
• area/tracking: Tracking Service, tracking client APIs, autologging

Language

• language/r: R APIs and clients
• language/java: Java APIs and clients
• language/new: Proposals for new client languages

Integrations

• integrations/azure: Azure and Azure ML integrations
• integrations/sagemaker: SageMaker integrations
• integrations/databricks: Databricks integrations

[peguerosdc]

Hi! Thanks for sharing! After discussing the topic on a Microsoft forum, I was pointed to an updated R example that implements a new MLFlow client (see /accidents/src/azureml_utils.R) which sort of solves my issue.

I don’t consider it ready for production as sometimes the code halts unexpectedly without much explanation (and the example didn’t run “as is”; that’s why I said “sort of”), but I think working on top of it would be a more direct approach for this use case. I am not planning to do it as I am ok with my workarounds at the moment, but I leave it here in case someone finds it useful or if you find you can borrow some of it for your package.

(Still this issue should remain open as it is not fixed nor an explanation is given)

[dbczumar]

We do not currently have plans to support modifying the artifact URI of an existing run or experiment, though it is possible to do so by modifying the underlying storage representation (e.g. SQL database record or file). Thank you for using MLflow!