track enablement by default in KF/manifests

[tarilabs]

see WG raised issue:

• Enable model-registry with UI by default community-distribution#3047

[mahdikhashan]

I would like to help with it, the requirements are:

1. modify the model-registry in the main manifest repo to enable UI by default

are there anything else which should be handled @tarilabs @lucferbux ?

[rareddy]

@mahdikhashan thank you for your interest in this. There are two separate issues I am proposing overall with this work

1. Update the current manifest, where we can define a separate profile for MR called kf-model-registry and enable UI for MR in this profile. This is not much different from what we have instructions other than we leave the name of the profile and creation of the profile to the end user; what I am suggesting is to tie it to a specific profile and make it in one script which would be the default. (above ask)

The further ask here is, how user granted access to this model-registry instance in this profile as we would need to discourage using this profile for end-user application workloads. for example; end user create my-example-com profile can access kf-model-registry? it probably is nothing more than creating the permission in kf-model-registry for the my-example-com profile user.

2. As next step; MR should be moved to be installed in a kf-model-registry namespace by default(not profile); however the user in my-example-com profile is granted permission to access a particular instance in kf-model-registry. I believe the MR permission model allows for it; we need to investigate and see if that works; if not why and what solutions are available there to fix the issue?

work with @pboyd as he also mentioned interest in working towards it. He certainly can help guide you

[mahdikhashan]

Thank you very much for trusting in me for this issue @rareddy, I'll follow you guidelines and check/share every steps and approach with @pboyd.

[mahdikhashan]

/assign

[lucferbux]

Thanks @mahdikhashan to take a look into this, let me expand the current conversation with findings in previous researches.

Update the current manifest, where we can define a separate profile for MR called kf-model-registry and enable UI for MR in this profile. This is not much different from what we have instructions other than we leave the name of the profile and creation of the profile to the end user; what I am suggesting is to tie it to a specific profile and make it in one script which would be the default. (above ask)

Profiles are abstractions of namespaces + permissions. You can check the profiles resources in the link attached. The main issue on creating Profiles and deployment time is that you need to have a subject. You cannot do something like system:authenticated (see this for more info) so creating a default Profile might be challenging, you could bring this into the community in case there's a solution for this issue but bear in mind int might be a blocker.
Also, Model Registry UI should be installed in the default namespace (in this case kubeflow) alongside all the rest of the components, that way we follow the same structure as any other component. To enable MR UI, you should edit the default KCD configmap with the Model Registry section (is already detailed in our installation steps).

it probably is nothing more than creating the permission in kf-model-registry for the my-example-com profile user.

https://www.kubeflow.org/docs/components/central-dash/profiles/#manage-contributors-manually

As next step; MR should be moved to be installed in a kf-model-registry namespace by default(not profile); however the user in my-example-com profile is granted permission to access a particular instance in kf-model-registry.

As I said before, we can follow this strategy, the main issue is that we'll need to cover in our docs that each an every user that wanna have access to MR should create the right permissions to be able to access it. Doing that, they would be able to access any particular instance in kf-model-registry as the default is that a user might be either viewer or editor.

The other issue, which is still on our side is that we don't support kubeflow roles still, we need to add that in our roadmpa to have a similar experience as other components.

[mahdikhashan]

/unassign

[tarilabs]

@lucferbux I'm not an SME on that area, but I wonder whether we could propose (to KF Platform) something like the following:

• in the example KF installation, we add one new Profile, to be created specifically for the "common" Model Registry (instead of using kubeflow which I understand is used for control-plane)
• this one Profile, be annotated so to identify it
• (let's assume this Profile be called shared-model-registry for this example)
• one controller (in kubeflow ns) that observes:
  • the RoleBinding to ClusterRole/kubeflow-{ROLE} to a new Profile/NS, and reconcile an analogous a RoleBinding for ClusterRole/kubeflow-view in shared-model-registry
  • the AuthorizationPolicy to a new Profile/NS, and reconcile an analogous AuthorizationPolicy for view for shared-model-registry
  • the idea being for any new user/sa, we give the necessary read access, so to be able to invoke the endpoints

very likely there are more details to be added, or for some reasons I don't know about yet this is not pursuable.
but I thought noting this down, if it's of any help

[pboyd]

@tarilabs, I'm not sure that I follow you. Are you saying that every new user or service account should have access to the model registry in the shared-model-registry namespace?

Would it be sufficient to assign the default user (user@example.com) as the owner in the default manifests?