-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFC: deprecating model registry stages #10336
Comments
37 tasks
@mlflow/mlflow-team Please assign a maintainer and start triaging this issue. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Deprecating model registry stages
Starting in MLflow 2.9, we plan to mark model registry stages as deprecated in favor of new tools we’ve introduced for managing and deploying models in the MLflow Model Registry. We plan to remove stage related features in a future major release. This RFC provides motivation for this change and guidance for migrating your ML workflows to the new model registry paradigm.
Background
The purpose of stages
Since the introduction of MLflow Model Registry, stages have been a tool to express the lifecycle of MLflow Models as they are productionized and deployed. Users can transition model versions through four fixed stages (from none, to staging, to production, and then to archived) as they propose, validate, deploy, and deprecate models for their ML use-cases. In doing so, model registry stages provide labeling and aliasing functionality for the model versions, by denoting the status of a model version in the UI and providing named references to model versions in the code (e.g.
/Staging
in the model URI). Model registry stages have also been used to denote the environment that the model is in.Over the years, we’ve received extensive feedback on the inflexibility of model registry stages. We took this feedback to introduce new tools to the MLflow Model Registry so that users can express MLOps workflows that meet their needs.
New model deployment tools
As of MLflow 2.8, we elevated model version tags, introduced model version aliases, and enhanced the model registry UI to provide flexible and powerful ways to label and deploy MLflow models in the MLflow Model Registry. Learn more below.
Model version tags
Now prominently displayed in the new model registry UI, model version tags can be used to annotate model versions with their status. For example, you could apply a tag of key
validation_status
and valuepending
to a model version while it is being validated and then update the tag value topassed
when it has passed smoke tests and performance tests.Model version aliases
Model version aliases provide a flexible way to set named aliases on model versions. For example, setting a champion alias on a model version enables you to fetch this model version by that alias via client API get_model_version_by_alias() or the model URI
models:/<registered model name>@champion
. Aliases can be easily reassigned to new model versions via the UI and client API alike, thereby decoupling model deployment from the production system code. Unlike model registry stages, more than one alias can be applied to any given model version, creating powerful possibilities for model deployment.[New] Environmental separation
In mature DevOps and MLOps workflows, organizations may set up environments to promote code and models across. With proper separation and access controls, these environments enable continuous integration and deployment for code and models. Organizations usually have a dev, a staging, and a prod environment. Thanks to the introduction of MLflow Authentication, you can use registered models to express access-controlled environments for your MLflow models. One registered model can correspond to each environment and you can use the new
copy_model_version()
client API to promote your models across them.Deprecating stages
Timeline
With the introduction of these new tools, we plan to mark model registry stages as deprecated starting in MLflow 2.9 and fully remove stages in a future major release. Please let us know if you have any questions or concerns with deprecating model registry stages! We want to make sure that post-stages MLflow is an amazing tool for your MLOps needs and use-cases before we remove model registry stages.
Migrating models away from stages
In the new model registry paradigm, we provide different tools for each legacy stages use-case. See the information below to learn how to use the new model registry for each use-case.
Model environments: To set up separate environments and ACLs for your model versions, create separate registered models:
revenue_forecasting
, set up various registered models corresponding to your environments with different prefixes.dev.ml_team.revenue_forecasting
,staging.ml_team.revenue_forecasting
, andprod.ml_team.revenue_forecasting
registered models.Transition models across environments: once you have registered models set up for each environment, you can build your MLOps workflows on top of them.
copy_model_version()
API.Model aliasing: To specify (via named references) which model version to deploy to serve traffic within an environment (e.g. production), use model aliases:
models:/regression_model/Production
will be replaced by the model URImodels:/prod.ml_team.regression_model@champion
in the production code.Model status: To represent and communicate the status of your model versions, use model version tags:
validation_status
and valuepending
orpassed
.Plugin authors: supporting new model registry APIs
Authors of MLflow model registry plugins should make the following changes to support the new model registry tools.
Implement model registry aliases
Work to be done
To get support with these implementations, please file a GitHub issue!
Support the
copy_model_version()
client APIStarting in MLflow 2.9, we plan to make this store implementation the default for the
copy_model_version()
client API. Our implementation invokes thecreate_model_version()
store method with the model URI of the source model version as thesource
param. Please make sure that yourcreate_model_version()
method supports such model version URI sources. Furthermore, as we plan to link the model version copy to its source model version in UI via thesource
param being the source model version URI, you should make sure that when a model version copy is fetched, it returns model version URI as itssource
.To consult us on supporting
copy_model_version()
, please file a GitHub issue!Conclusion
Thanks so much for your attention and consideration! We’re excited to continue to work with the open source community to make MLflow an amazing tool for managing the machine learning lifecycle.
The text was updated successfully, but these errors were encountered: