Provision of OpenSearch Model Registry

[xyinshen]

Background

As the machine learning capabilities in OpenSearch continue to expand, it has become increasingly common for users to leverage their own models to fulfill custom requirements. While ml-commons provides a rich set of APIs for model uploading, usage, and management, using these APIs can be daunting for many users. Currently, ml-commons-dashboards only provides an admin UI that allows users to view deployed models. By enhancing the functionality of the model registry, users will be able to upload models through the ml-commons-dashboards plugin, eliminating the need for complex API calls. Totally, a model registry helps teams discover, manage, and track machine learning models across their organization.
Specifically, assistance for machine learning capabilities is listed below:

1. Provide a simple and convenient model uploading feature that allows users to upload models from model repositories, remote sources, and local files to OpenSearch.
2. Enable quick model discovery through tags, allowing for sorting of models with the same tags across different model versions and facilitating comparison of metrics between different versions.
3. Enable rapid deployment of desired models.
   The primary objective of this RFC is to illustrate the function as well as delevopment plan of Model Registry and solicit feedback for the ongoing development, and to set the stage for some of the technology modernization efforts. Input received will help with prioritization of work streams, and make sure the right things are being built that will deliver value both short-and long-term.

Goals

I start this RFC with some goals and principles. As long as we have alignment on these, they should guide us in making “directionally correct” decisions, and help us make incremental progress. In no particular order, these are:
1. Feedback - Improve our ability to proactively identify the needs of our users, and guide our development plan.
2. Usability - Allow users to upload model simply and conveniently, as well as sort model across model versions and rapidly deploy desired models.

Focus Areas:

Model Browsing

Entering model registry, users firstly see the model list. It is also the entry point of registering model. In the model list, users could see the details and information of model, including model name, model version information, model source, model description, model owner, use state as well as last updated date. Users could also register new version for a model or delete it. Of course, a search bar could support model sorting across model name, model description as well as model owner. With the model tag, users could filter model list.

Creating a new model

Model registry supports diversified model uploading methods. Specifically, users could upload model locally and externally. For local uploading, users could upload model from model repository, url as well as local files. We have prepared the corresponding interface completely. Users could select most convenient ways combining the situation of different model. As shown in follow picture, when users click ‘Register model’ button, a model allow for choosing uploading methods will show to users. When ‘OpenSearch model repository is chosen, users could register pre-trained model from the model repository. When ’Add your own model’ selected, users could upload model across local file or URL. Users need to supply details ,including name and description, and tags as well as file and version information. In the end, user could also choose start deployment automatically or not after model uploaded. If ‘External source’ selected, users could register external model. Users need to complete model details including name and description, tags for model versions comparison as well as model connector and version information. In the end, a boolean for activate on registration or not is shown to users.

Registering for a new model version

A model support multi-version. Model registry allow users to register new version for a specific model. There are three entrance to register new version for a model, including model list page, model detail page and version detail page. If model version source is local source, users need to upload model file from computer or from URL. Then users need to complete configuration and Tags, which aim to discover and compare models. If model version source is external source, users need to select model connector to upload model. Then users need to complete tags and version information. In the end, user could also select activate on registration or not.
Model registry also support model version management. Every model has version list. In version list, users could see state, connector, version notes, last updated date, and tag information of different version of every model. Users could search model version by version number, ID, or keyword. There are also button to delete specific version of a model. For local model, users could deploy a specific version of model across just one click. And for external model, users could activate it.
Users could also manage specific version detail of every model. Model version details page allow for checking version information and model connector information and support editing.

Local model vs. External model

In model list, user could easily distinguish model source. And for registering model, There are some difference in local source and external source. Firstly, selecting model connector is requested when uploading external model. Secondly, users could call activate api while registering external model as contrasted with deploy api while registering local model.

As for registering version, there are some difference between two model source. While registering model of local source, users need to select source from local file or URL. And completing model file format is requested. While registering model of external source, users are requested to select model connector and model-level overrides. As like registering model, registering version of local source model could call deployment api and registering version of external source model could call activate api.