[Proposal] Review and add UI manifests to the root level manifests directory

[Griffin-Sullivan]

The UI team has now completed our work on the manifests for deploying the Model Registry UI in the Kubeflow Central Dashboard as well as in a standalone cluster. To better align for releases, we should move our manifests to the root manifests directory. It will require moving some folders, but in the end we can move away from using clients/ui/manifests. Before we open the PR for moving these files, I would like to get some feedback from the community to review our manifests. See https://github.com/kubeflow/model-registry/tree/main/clients/ui/manifests if you'd like to review. Here's a quick overview of what it looks like:

We have our base manifest, plus three overlays. One for enabling the UI to run integrated, one for all of our istio config needed for a Kubeflow deployment, and one for deploying as a standalone UI in a cluster. At the moment, we would only ever use the istio or standalone overlays.

One final note for grouping our manifests: we will not want to combine manifests with the Model Registry base as that would deploy a new UI for each MR deployment. This would use unnecessary resources for people deploying multiple Model Registries. Ideally, users would run a separate kubectl apply for the UI and Model Registry.

Please share your thoughts and thanks for everyone's hard work on the Model Registry UI!

[ederign]

@tarilabs @dhirajsb @rareddy when you have a chance, can you please take a look on this^?

[rareddy]

Regarding the movement of the manifests to the root directory, I suggest we consult with the Manifest team as this pattern is acceptable to that group.

One final note for grouping our manifests: we will not want to combine manifests with the Model Registry base as that would deploy a new UI for each MR deployment. This would use unnecessary resources for people deploying multiple Model Registries. Ideally, users would run a separate kubectl apply for the UI and Model Registry.

IMO, it should be a single install, otherwise, it is a documentation issue, users are not going to look at these as two separate modules can cause confusion. In most scenarios, users are installing a single deployment of Model Registry. This will treat and keep MR backend and UI as single unit. I suggest that there is a way to detect if UI installed already from first deployment of MR and then skip the next one? also find if there is anyway to configure or control the install through command line options for Kustomize to choose to install the MR UI module or not.

[tarilabs]

One final note for grouping our manifests: we will not want to combine manifests with the Model Registry base as that would deploy a new UI for each MR deployment. This would use unnecessary resources for people deploying multiple Model Registries. Ideally, users would run a separate kubectl apply for the UI and Model Registry.

I would still move the UI manifest in the root,
and similarly to the instructions which was redacted following consensus: https://www.kubeflow.org/docs/components/model-registry/installation/#standalone-installation
I would add one paragraph that mentions UI install, in addition to currently existing Istio and CSI.

Then, call out in the README of the UI manifest that is supporting multiple instances already. This way, an advanced user will know to only make a new MR instance, without redeploying the CSI or UI.

Imho this would be the simplest, to address also @rareddy request.

[tarilabs]

as discussed in today's 2024-01-20 KF MR biweekly call

• ui manifest will be ported into the KF/model-registry root
• website tutorial will be added with section for UI, analogously to what exists for CSI for example
• tutorial will be updated to deploy in kubeflow-model-registries namespace (to be created) and pending ack from Platform/Manifest WG, so this can be an easy rolebinding (instead of granting access to kubeflow namespace for the user)