Return Model from log_model#5230
Conversation
Signed-off-by: Liang Zhang <liang.zhang@databricks.com>
Signed-off-by: Liang Zhang <liang.zhang@databricks.com>
Signed-off-by: Liang Zhang <liang.zhang@databricks.com>
dbczumar
left a comment
There was a problem hiding this comment.
LGTM once all model flavors are updated!
Signed-off-by: Liang Zhang <liang.zhang@databricks.com>
Signed-off-by: Liang Zhang <liang.zhang@databricks.com>
Signed-off-by: Liang Zhang <liang.zhang@databricks.com>
Signed-off-by: Liang Zhang <liang.zhang@databricks.com>
harupy
left a comment
There was a problem hiding this comment.
LGTM once #5230 (comment) is addressed.
…Info Signed-off-by: Liang Zhang <liang.zhang@databricks.com>
|
|
||
| def get_model_info(self): | ||
| """ | ||
| Create a :py:class:`ModelInfo <mlflow.models.model.ModelInfo>` instance that contains the |
There was a problem hiding this comment.
@harupy Also,
:py:class:`ModelInfo <mlflow.models.model.ModelInfo>`
works while the following does not:
:py:class:`ModelInfo`
Thanks for helping!
| flavors: Dict[str, Any] | ||
| model_uuid: str | ||
| saved_input_example_info: Dict[str, Any] | ||
| signature: ModelSignature |
There was a problem hiding this comment.
| signature: ModelSignature | |
| signature: Optional[ModelSignature] |
Can we use Optional for properties that can be None?
There was a problem hiding this comment.
I changed it to a native python dictionary that is ModelSignature.to_dict() to avoid importing pandas in mlflow skinny. Another reason is that for the user's information, there is no need to return the ModelSignature object. A dictionary should be sufficient for the purpose of information reading.
Signed-off-by: Liang Zhang <liang.zhang@databricks.com>
|
|
||
| #: The UTC time that the logged model is created, e.g., ``'2022-01-12 05:17:31.634689'``. | ||
| utc_time_created: str | ||
|
|
There was a problem hiding this comment.
I added example values for some attributes.
Signed-off-by: Liang Zhang <liang.zhang@databricks.com>
Signed-off-by: Liang Zhang <liang.zhang@databricks.com>
| """ | ||
| A dictionary that contains the metadata of the saved input example, e.g., | ||
| ``{"artifact_path": "input_example.json", "type": "dataframe", "pandas_orient": "split"}``. | ||
| """ |
There was a problem hiding this comment.
Improve the Model class property docstring.
What changes are proposed in this pull request?
Provide a return value from
mlflow.*.log_model()that contains model metadata such asmodel_uri,run_id,...This metadata makes it easier for the user to do follow-up model loading.
How is this patch tested?
Existing tests + tests/models/test_model.py test_model_info()
Does this PR change the documentation?
ci/circleci: build_doccheck. If it's successful, proceed to thenext step, otherwise fix it.
Detailson the right to open the job page of CircleCI.Artifactstab.docs/build/html/index.html.Release Notes
Is this a user-facing change?
mlflow.*.log_model()returns a ModelInfo instance that contains the metadata of the logged model.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/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