Ability to configure available storage classes

[andrewballantyne]

Support multiple storage classes for PVCs (Cluster Storages) in the Projects view.

Mocks: https://www.sketch.com/s/f6fa37fc-0c25-49e3-8b24-ecaf981433a8/a/g1rOAvJ

Using feature branch f/storage-class

Dependencies

• UX: Configure available storage classes #1798
• Early adoption: [Feature Request]: Support a default-less StorageClass cluster in DS Projects #1701

Foundational Work

• [Feature Request]: Allow admin groups direct access to application items #1355
• Create Custom Resources to track Storage Classes metadata #1362

P0: Admins must be able to configure which storage classes should be available for users

• Must be able to configure storage classes other than the OpenShift default.
• Must be able to configure a 'default' storage for RHODS. This does not have to be the OpenShift default.
• Must be able to configure the name of the storage class as it should appear for users if exposed in the end user UI. Note: per Guillaume's comment below, the end user UI should show the admin configured display name as well as the real name. 

• Add Storage Class section in Admin Panel and Feature Flag #1363
• Storage Classes Table #1364
• Storage Class Filter and Pagination #1365
• Edit for Storage Class Table Row #1366

P0: Users should be able to select from available storage classes based on admin config when creating workbenches or NB serving sessions

• If only 1 storage class available, the UI should not present an option for users (since the one available will always be used).
• If more than 1 available, the UI should start with default configured by admin, but users should be able to select any of the available options.

• Select Storage Classes in Workbench creation #1367
• Display storage class selected in Workbenches #1368

[shalberd]

For listing available storage classes, you might need more than Clusterrole Admin. There is a ClusterRole basic-user that can list users and storageclasses. Especially for showing which users already have access to the project in project sharing, that might be good as well. https://docs.openshift.com/container-platform/4.10/authentication/using-rbac.html

If you go with the approach "Admins must be able to configure which storage classes should be available for users", then you do not need the storageclass list rights, that'd be easier. Nice idea with the ability to pick from multiple available storage classes, if defined. Makes the solution more flexible in comparison to the current jupyter tile approach with one storageclass globally.

I can't access the GUI sketches, but that is ok.

@andrewballantyne When you talk about default storage class, do you mean default storage class set at cluster-level or default storage class set in ODHDashboardConfig? There are clusters that have no default storage class, but you can still configure a default storage class for ODH Notebook PVC purposes via ODHDashboardConfig.

Even if there is a default storage class set in ODHDashboardConfig, you should still show the list of available storageclasses, with the focus in e.g. a dropdown on the default one.

Flow could be:

• check if there is a default storage class at cluster-level. If available, take that one as ODH Default.
• check if there is a default storage class at ODHDashboardConfig level. Use that one if it is different from cluster default storage class or if no cluster default storage class exists.
• put focus on default storageclass, as resolved in the first two steps, in GUI list, but with the option to still change to a different one on a workbench-by-workbench basis.

[andrewballantyne]

@shalberd as I understand it, all users can list storage classes (I tested this on my cluster with a basic user -- it was a while ago though). After listing, there is nothing else happening around storage class resources. We are not allowing creation, deletion or editing of the resource itself. We'll need to manage the metadata way from the storage class as this is a cluster resource that the admin probably shouldn't be marking up for our application use-case (a cluster could have multiple use-cases ongoing).

TBD if we use a CRD or some configmap setting / OdhDashboardConfig setting -- but we will need to store in an "enabled state", description and a display name for the end-user (data scientists). That'll be figured out part of this effort once @lucferbux starts flushing it out over the next week or two.

[shalberd]

all users can list storage classes

Yes

The clusterrole basic-user

openshifthostname/k8s/cluster/clusterroles/basic-user can list storageclasses, which is nice.

Any authenticated / logged-in user is assigned clusterole basic-user, so it's cool.

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: basic-users
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: 'true'
subjects:
  - kind: Group
    apiGroup: rbac.authorization.k8s.io
    name: 'system:authenticated'
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: basic-user

We'll need to manage the metadata way from the storage class as this is a cluster resource that the admin probably shouldn't be marking up for our application use-case.

Correct, our cluster has like 20 or more different storageclasses for all kinds of purposes. They cannot be tagged or annotated in any way, but people in an enterprise can pick the right one for their purposes themselves. I picked one with file storage instead of block storage for notebook storage purposes, but that is dependent on the environment (AWS, Azure, on-prem with e.g. NetApp) entirely. The most i would recommend on the GUI is having a hint as to what kind of storage type (block vs file) you would recommend from all the storageclasses listed, users can pick the right one themselves by name usually.

[andrewballantyne]

Another good note about something we should support with Storage Classes when we do this feature.

[dgutride]

Migrated to jira: https://issues.redhat.com/browse/RHOAIENG-332

[dgutride]

Moving to closed - future work will be tracked in Jira