- Package Name: azureml-mlflow
- Package Version: 1.62.0.post5
- Operating System: Linux (Kubernetes workload)
- Python Version: 3.11
Describe the bug
We use azureml-mlflow for remote MLflow tracking against an Azure Machine Learning Workspace from a Kubernetes workload.
The latest available version, azureml-mlflow 1.62.0.post5, currently introduces dependency constraints that prevent us from applying required security upgrades:
mlflow-skinny <= 3.13.0cryptography < 49.0.0
Our security scanning requires:
mlflow >= 3.15.0cryptography >= 50.0.0
Because azureml-mlflow is required for our azureml:// MLflow tracking URI, removing the package is not currently an option without changing the Azure ML tracking architecture.
To Reproduce
- Create a Python 3.11 environment.
- Install or declare
azureml-mlflow==1.62.0.post5.
- Attempt to resolve the environment with
mlflow>=3.15.0.
- Attempt to resolve the environment with
cryptography>=50.0.0.
- The dependency resolver cannot satisfy these requirements together with the constraints introduced by
azureml-mlflow.
Expected behavior
There should be a supported version of azureml-mlflow that is compatible with current secure versions of MLflow and its dependencies, or documented guidance for customers who need to remediate these dependency vulnerabilities while continuing to use an Azure Machine Learning Workspace as the remote MLflow tracking backend.
Screenshots
N/A
Additional context
Our application already uses Azure Machine Learning SDK v2 (azure-ai-ml / MLClient) to access the workspace.
MLflow is used for experiment tracking, metrics, parameters, artifacts, and model registry operations against the Azure ML Workspace.
According to the current Azure ML documentation, azureml-mlflow is still required when configuring remote MLflow tracking against an Azure Machine Learning Workspace from compute outside Azure ML.
Could you please confirm:
- Whether a new
azureml-mlflow release is planned that relaxes these dependency constraints.
- Whether there is a currently supported alternative that allows us to keep Azure ML Workspace as the MLflow tracking backend while upgrading MLflow.
- What the recommended remediation path is for customers blocked from security upgrades by these constraints.
Describe the bug
We use
azureml-mlflowfor remote MLflow tracking against an Azure Machine Learning Workspace from a Kubernetes workload.The latest available version,
azureml-mlflow 1.62.0.post5, currently introduces dependency constraints that prevent us from applying required security upgrades:mlflow-skinny <= 3.13.0cryptography < 49.0.0Our security scanning requires:
mlflow >= 3.15.0cryptography >= 50.0.0Because
azureml-mlflowis required for ourazureml://MLflow tracking URI, removing the package is not currently an option without changing the Azure ML tracking architecture.To Reproduce
azureml-mlflow==1.62.0.post5.mlflow>=3.15.0.cryptography>=50.0.0.azureml-mlflow.Expected behavior
There should be a supported version of
azureml-mlflowthat is compatible with current secure versions of MLflow and its dependencies, or documented guidance for customers who need to remediate these dependency vulnerabilities while continuing to use an Azure Machine Learning Workspace as the remote MLflow tracking backend.Screenshots
N/A
Additional context
Our application already uses Azure Machine Learning SDK v2 (
azure-ai-ml/MLClient) to access the workspace.MLflow is used for experiment tracking, metrics, parameters, artifacts, and model registry operations against the Azure ML Workspace.
According to the current Azure ML documentation,
azureml-mlflowis still required when configuring remote MLflow tracking against an Azure Machine Learning Workspace from compute outside Azure ML.Could you please confirm:
azureml-mlflowrelease is planned that relaxes these dependency constraints.