Create data science project in existing namespace

[yuanchi2807]

Solution

We'll be supporting OpenShift Console Projects in the Dashboard.

Mocks: https://www.figma.com/proto/9CkrqD7byqvTBUzRok2ihE/RHODS?page-id=287%3A13618&type=design&node-id=287-14414&viewport=273%2C151%2C0.06&t=qM4W6hZAcZiZPXig-1&scaling=scale-down&starting-point-node-id=287%3A14414&mode=design

Implementation notes:

Follow the design, but here are a couple expected items for the development effort.

• Do two types of fetches -- one with the labelSelector (opendatahub.io/dashboard) and one without -- RBAC will help the user see all the namespaces that belong to them
• If the results come back with anything openshift- or kube prefixed or default namespace... trim them out before saving the data
• The create flow does not change
• Store the last selected value of the dropdown in local storage (useBrowserStorage hook should make this easy)

---

Enhancement request

Allow the creation of data science project to specify an existing namespace. Currently DSP name cannot be the same to another existing namespace in the Openshift Cluster.

Details

Namespace is used to manage users and enforce cluster resource usage quota, e.g. the maximum numbers of CPUs, GPUs, pods. Creating new namespaces requires OCP admins to redo user binding and quota configuration.

[Gkrumbach07]

cc @andrewballantyne

[andrewballantyne]

@yuanchi2807 Would a satisfactory solution to this be able to see projects you have access to in OpenShift Console as a toggle? Or is your intent to only include "some" of your projects in the Data Science Projects view?

[andrewballantyne]

I have transferred this to the dashboard (UI component) as this will be fixed in our code.

[andrewballantyne]

@kywalker-rh do we have UX issue for supporting more than just DS Projects on our Project list page tracked?

[yuanchi2807]

@yuanchi2807 Would a satisfactory solution to this be able to see projects you have access to in OpenShift Console as a toggle? Or is your intent to only include "some" of your projects in the Data Science Projects view?

@andrewballantyne toggle or pulldown menu to pick an existing namespace would be great.

[shalberd]

sounds like a good idea, especially with regards to namespace-specific annotations, like tolerations, node selectors and so on, that are often already there on existing namespaces one has access to. Question would be: What level of access, I assume rolebinding with ClusterRole Admin to the project to be able to select the project? We have a similar approach of project/namespace first in our org.

[shalberd]

@yuanchi2807 on the other hand, in a non-GUI way, all you'd need to do for the namespaces to appear in Data Science Projects would be to add two additional labels:

'opendatahub.io/dashboard': 'true'

and optionally

'modelmesh-enabled': 'true' if you want it to be used for model serving.

That second one is being discussed

#1310

if you don't want to use Model Serving, just leave it out.

[andrewballantyne]

FWIW, the modelmesh label should already show up "late" if you use Model Serving -- we just want to make it "always" delayed.

[StevenBarre]

@shalberd are those labels documented anywhere?

[xianli123]

Hi @andrewballantyne @yuanchi2807 I updated the design based on your suggestions and the discussions in the original issue RHODS-8603. Please take a look at the design and feel free to let me know if there are any questions or new requirements. Thanks!

[andrewballantyne]

@shalberd are those labels documented anywhere?

@StevenBarre they are currently not. opendatahub.io/dashboard=true is the label we use for all our resources. We need to document this better internally to the repo.

[manosnoam]

In RHOAI 2.5, when having an OCP namespace (e.g. "noam-project") and trying to create same project name in the Dashboard, it is not allowed:

@andrewballantyne Is that the expected behavior for this feature ??

[andrewballantyne]

@manosnoam yes, this has always been true. This is why you can name your resource name, because you may want the display name but have another project behind the scenes used for other reasons.

[manosnoam]

@andrewballantyne in description I see "Enhancement request: Allow the creation of data science project to specify an existing namespace." .
I'm not sure I understand what is the feature, and how to test it then, if not by verifying we can reuse an existing OCP namespace for a new DS project.

[andrewballantyne]

@andrewballantyne You should have access to your k8s RBAC namespaces via the dropdown in the top left. You don't need to "create" a new project, you can get access to your existing one.

[manosnoam]

Very nice!

And my OCP project is available to be used as DS project:

[shalberd]

yes, that is a very nice new feature, saw this in a dev experience meeting a while ago, cool to see it in production. It is encouraging to see all positive developments, be it enterprise-readiness or cutting edge functionality.

[lugi0]

FWIW I see something weird with this functionality, I get only a subset of the available namespaces even though I'm using a cluster-admin user.
I could see why it wouldn't return the openshift default namespaces, but in my case it's also missing the redhat-ods-applications namespace.
What is the criteria for the namespaces that are shown in this page?

[DaoDaoNoCode]

@lugi0 Yes, we intentionally hide the namespace where the dashboard is deployed.

[andrewballantyne]

An arbitrary list of namespaces are hidden for cluster-admins to avoid accidental deployments into those namespaces. The criteria is somewhat vague and open to expanding. (the code)

I'd like to stress, this list is to help cluster-admins, not as a ironclad solution. We welcome feedback to expand it, but effectively it's low effort/priority to do so. Most users won't have access to all projects, and thus this is not a primary flow to concern ourselves with.

[shalberd]

I like that list a lot in that it prevents projects being used for Data Science Workbenches tasks that are not supposed to, even if one does have i.e. just View access to one of those namespaces.
as for the dashboardNamespaces not being available in Data Science Projects: that for now makes sense, as the Jupyter tile application is doing that ... creating notebooks in the main namespace, i.e. opendatahub or redhat-ods-applications.
I am fine with not creating any workbenches / notebooks in the main application namespace, i.e. opendatahub or redhat-ods-applications. @lugi0 that explains why you don't see it in the list.

[andrewballantyne]

We will readdress what the Jupyter Tile does and what it means for users when we migrate it. It's a bit of a messy situation right now with the no notebook-namespace or having it, and in general it shouldn't be used to deploy Data Science flows just for sanity and cleanness... the application namespace definitely needs to be only for that -- application resources -- and the Jupyter tile having that backwards is definitely not awesome.

[shalberd]

and in general it (the main application namespace) shouldn't be used to deploy Data Science flows just for sanity and cleanness... the application namespace definitely needs to be only for that -- application resources -- and the Jupyter tile having that backwards is definitely not awesome.

agreed, it is better to provision a new or to use an existing namespace except for the main DataScienceCluster / KfDef namespace for creating workbenches.

[lugi0]

@andrewballantyne @shalberd Not sure I'm getting your point, the jupyter tile deploys in rhods-notebooks rather than the applications namespace - which I have access to through this view (you can actually see the three stopped "workbenches", which are there only because those three users have previously deployed a NB through the Jupyter tile and thus have a Notebook CR in that namespace).
I think it's ok to arbitrarily decide to show certain namespaces or not, but if we need to validate the feature I think some precise criteria is needed in order to explore the view through users with different permissions and ensure that each one is only seeing what it's supposed to see - I will leave it up to @manosnoam to figure out what those tests are, so take it as my 2c and nothing more.

[andrewballantyne]

Not sure I'm getting your point, the jupyter tile deploys in rhods-notebooks rather than the applications namespace

@lugi0 This is not done automatically on ODH installs. This is configured in RHOAI, per the needs of the install. The Dashboard does not automatically create another namespace where we deploy items from the Jupyter tile, it's done via the resources that are deployed as part of the operator install. Let me know if you'd like me to get all the various variables/resources collected together and showcase where those toggles are. I imagine this isn't too much of a concern for our RHOAI installations, but if you're curious, we can investigate this from a "what does the dashboard do out of the gate with no configurations".

if we need to validate the feature I think some precise criteria is needed in order to explore the view through users with different permissions and ensure that each one is only seeing what it's supposed to see

@manosnoam please let me know if you want to talk about this. The only criteria we had was "I wanna see my openshift created namespaces" -- we limited the other use-cases through development to hide specific Cluster-Admin based access. This is not ironed to perfection, so if you think there is more to work with here... we should discuss it and look at enhancements.