[Proposal] Model Registry UI #108
Comments
|
For code location, I prefer option 1a. |
|
+1 for Code location being Option 1a. +1 for the architecture direction. @ederign I understand the Material UI dependency for look n' Feel of UI to match the Kubeflow dashboard is required. However with this architecture, once ODH Model Registry UI moved to Kubeflow, I would like to pull this into the Kubeflow dashboard for at least for testing purposes as per the attached screens this only renders the right side of the screen, and Kubeflow Dashboard can provide nav rendering. |
|
@rareddy yeah, if Dashboard people is ok with look and feel temporarily don't match, adding early to the dashboard makes total sense |
* WIP working manually * Increase REST wirings and cover with Robot * Align to a309537 Improve core layer testing kubeflow#85 * Implement opeanpi models converter * Treat coreApi as interface * Align to ModelArtifact comment, not resolved yet * Automate type_asserts generation with gen/openapi-server * Add Robot for Data Layer mapping implementing REST(Go)<->gRPC * Add check for artifactType * Wire REST FindXXX to core GetXXXByParams * Wire REST GetXXXYYY to core API methods * Wire REST UpdateXXX to core UpsertXXX methods * Use localhost for Robot file * Align to goverter changes * rebase goverter implementation * Update cmd/proxy.go Co-authored-by: Andrea Lamparelli <[email protected]> --------- Co-authored-by: Andrea Lamparelli <[email protected]>
|
I concur with all @rareddy points, +1 |
|
After discussion with @ederign the proposal is to use the following locations to group ui code under client parent directory: To lookup model registry k8s resources for UI, we can use the existing selector from model registry service. |
|
The midstream model registry operator in ODH uses a slightly different set of labels for model registry services. |
In this commit: basic Dockerfile basic Makefile Scaffold of App and first sample endpoint (http://localhost:4000/api/v1/healthcheck/) REST API basic infrastructure and error handling
In this commit: - basic Dockerfile - basic Makefile - Scaffold of App and first sample endpoint (http://localhost:4000/api/v1/healthcheck/) - REST API basic infrastructure and error handling
|
FUP -> #114 |
In this commit: - basic Dockerfile - basic Makefile - Scaffold of App and first sample endpoint (http://localhost:4000/api/v1/healthcheck/) - REST API basic infrastructure and error handling Signed-off-by: Eder Ignatowicz <[email protected]>
In this commit: - basic Dockerfile - basic Makefile - Scaffold of App and first sample endpoint (http://localhost:4000/api/v1/healthcheck/) - REST API basic infrastructure and error handling Signed-off-by: Eder Ignatowicz <[email protected]>
Over the past few weeks, the Model Registry UI team has made significant progress in Model Registry UIs[1] at ODH Dashboard. While this project is still under development, our aim is to push its development upstream under the Kubeflow organization as a companion to Model Registry. To initiate this transition, we need to discuss the following points:
1. Code Location
We want to keep the UI code as colocated as possible in the Model Registry repository. This will simplify our development workflow, enable us to run as a standalone project, streamline our testing, and foster better collaboration. I believe we have two options here:
Option 1a: Inside model-registry repository
Option 2a: Inside its repository, kubeflow/model-registry-ui
2. Architecture
We will split the UI into two layers:
In parallel, to enable future integration of Model Registry UIs with the Kubeflow Dashboard, we are working towards a Patternfly CSS Theme (issue link) that matches the Kubeflow UI design language (issue link).
I'm already working on the BFF in a temporary repository(code), and I'm happy to move this work upstream as soon as possible. Once we define the target code location, my team will extract the Model Registry Code from the ODH dashboard and push it to the Model Registry repository as a standalone app.
As soon as we have both pieces on a kubeflow repository, the Model Registry UI team can move most of its work upstream.
[1] screenshot 1, screenshot 2, screenshot_3, screenshot_4 (Figma)
The text was updated successfully, but these errors were encountered: