Fix downloading MLmodel files from alias-based models:/ URIs#8764
Fix downloading MLmodel files from alias-based models:/ URIs#8764smurching merged 3 commits intomlflow:masterfrom
Conversation
Signed-off-by: Sid Murching <[email protected]>
| ) | ||
| ml_model_file = _download_artifact_from_uri( | ||
| artifact_uri=append_to_uri_path(model_uri, MLMODEL_FILE_NAME) | ||
| ml_model_file = get_artifact_repository(artifact_uri=model_uri).download_artifacts( |
There was a problem hiding this comment.
Instead of assuming that we can append /MLmodel to an artifact URI to get a valid artifact URI (which is not generally true), we instead construct an ArtifactRepository against the original artifact URI (e.g. models:/mymodels@alias) and then call download_artifacts with the actual file path (MLModel). We should make similar fixes elsewhere, I'll do that in a follow-up PR
There was a problem hiding this comment.
Actually - another alternative to this could be trying to support URIs like models:/mymodel@alias/path/to/file. Technically this is possible since aliases can only contain alphanumeric characters, would reduce the set of changes needed in the immediate-term, and would allow for things like mlflow.artifacts.download_artifacts(artifact_uri="models:/mymodel@alias/path/to/file"). @harupy I saw you made a similar fix in #5921
The main downside I think is that there may be artifact store types for which appending a /path/to/file at the end of the URI isn't valid (e.g. any artifact store where there are query parameters in the URI). But we could deal with that if/when we need to
There was a problem hiding this comment.
Hm, not sure my suggestion will work. The problem is that we don't restrict the set of allowed characters in registered model names in OSS. That means that a URI like models:/mymodel@myalias/1/to/file could ambiguously be interpreted as (1) targeting the file at path 1/to/file under the version of mymodel associated with the alias myalias or (2) targeting the model named mymodel@alias, version 1, file path /to/file. So unfortunately I think we can't support this style of URI for aliases and should adopt the fix in this PR to download specific files from model versions referenced by alias
There was a problem hiding this comment.
It seems the safer option. Just checked cloud provider docs for object store and they really don't have many restrictions on key contents anyway.
| def _improper_model_uri_msg(uri): | ||
| return ( | ||
| "Not a proper models:/ URI: %s. " % uri | ||
| + "Models URIs must be of the form 'models:/<model_name>/<suffix>' " |
There was a problem hiding this comment.
This error message doesn't render well in notebooks, since <model_name> is rendered/escaped as an HTML tag; fix it by removing the angle brackets
There was a problem hiding this comment.
I didn't know that, makes sense!
There was a problem hiding this comment.
We should probably look for other cases of this.... I had no idea that it would parse as a tag
Signed-off-by: Sid Murching <[email protected]>
|
Documentation preview for 4bbdd07 will be available here when this CircleCI job completes successfully. More info
|
Signed-off-by: Sid Murching <[email protected]>
…8764) * Fix downloading MLmodel files from alias URIs Signed-off-by: Sid Murching <[email protected]> * Fix test Signed-off-by: Sid Murching <[email protected]> * use variable Signed-off-by: Sid Murching <[email protected]> --------- Signed-off-by: Sid Murching <[email protected]>
…8764) * Fix downloading MLmodel files from alias URIs Signed-off-by: Sid Murching <[email protected]> * Fix test Signed-off-by: Sid Murching <[email protected]> * use variable Signed-off-by: Sid Murching <[email protected]> --------- Signed-off-by: Sid Murching <[email protected]>
* Fix downloading MLmodel files from alias URIs Signed-off-by: Sid Murching <[email protected]> * Fix test Signed-off-by: Sid Murching <[email protected]> * use variable Signed-off-by: Sid Murching <[email protected]> --------- Signed-off-by: Sid Murching <[email protected]>


Related Issues/PRs
#xxxWhat changes are proposed in this pull request?
Follow-up to #8728, this PR fixes downloading MLmodel files when loading models with URIs like
models:/mymodel@alias. The current logic for this attempts to append the MLmodel file path to the URI and then download from an artifact URI likemodels:/mymodel@alias/MLmodel, which is not a valid URI and cannot be parsed.How is this patch tested?
Updated unit tests. Also manually verified the PR fixes a bug in a DAIS demo 😅
Does this PR change the documentation?
Release Notes
Is this a user-facing change?
(Details in 1-2 sentences. You can just refer to another PR with a description if this PR is part of a larger change.)
What component(s), interfaces, languages, and integrations does this PR affect?
Components
area/artifacts: Artifact stores and artifact loggingarea/build: Build and test infrastructure for MLflowarea/docs: MLflow documentation pagesarea/examples: Example codearea/model-registry: Model Registry service, APIs, and the fluent client calls for Model Registryarea/models: MLmodel format, model serialization/deserialization, flavorsarea/recipes: Recipes, Recipe APIs, Recipe configs, Recipe Templatesarea/projects: MLproject format, project running backendsarea/scoring: MLflow Model server, model deployment tools, Spark UDFsarea/server-infra: MLflow Tracking server backendarea/tracking: Tracking Service, tracking client APIs, autologgingInterface
area/uiux: Front-end, user experience, plotting, JavaScript, JavaScript dev serverarea/docker: Docker use across MLflow's components, such as MLflow Projects and MLflow Modelsarea/sqlalchemy: Use of SQLAlchemy in the Tracking Service or Model Registryarea/windows: Windows supportLanguage
language/r: R APIs and clientslanguage/java: Java APIs and clientslanguage/new: Proposals for new client languagesIntegrations
integrations/azure: Azure and Azure ML integrationsintegrations/sagemaker: SageMaker integrationsintegrations/databricks: Databricks integrationsHow should the PR be classified in the release notes? Choose one:
rn/breaking-change- The PR will be mentioned in the "Breaking Changes" sectionrn/none- No description will be included. The PR will be mentioned only by the PR number in the "Small Bugfixes and Documentation Updates" sectionrn/feature- A new user-facing feature worth mentioning in the release notesrn/bug-fix- A user-facing bug fix worth mentioning in the release notesrn/documentation- A user-facing documentation change worth mentioning in the release notes