Open Data Hub logo
DOCS
BLOG
COMMUNITY
GITHUB
GET STARTED

Info alert:Important Notice

Please note that more information about the previous v2 releases can be found here. You can use "Find a release" search bar to search for a particular release.

Managing resources

As an Open Data Hub administrator, you can manage the following resources:

  • Open Data Hub admin and user groups

  • Dashboard customization

  • Custom workbench images

  • Cluster PVC size

  • Connection types

  • Cluster storage classes

  • Basic workbenches

Selecting Open Data Hub administrator and user groups

By default, all users authenticated in OpenShift can access Open Data Hub.

Also by default, users with cluster-admin permissions are Open Data Hub administrators. A cluster admin is a superuser that can perform any action in any project in the OpenShift cluster. When bound to a user with a local binding, they have full control over quota and every action on every resource in the project.

After a cluster admin user defines additional administrator and user groups in OpenShift, you can add those groups to Open Data Hub by selecting them in the Open Data Hub dashboard.

Prerequisites

  • You have logged in to Open Data Hub as a user with Open Data Hub administrator privileges.

  • The groups that you want to select as administrator and user groups for Open Data Hub already exist in OpenShift Container Platform. For more information, see Managing users and groups.

Procedure

  1. From the Open Data Hub dashboard, click Settings → User management.

  2. Select your Open Data Hub administrator groups: Under Data science administrator groups, click the text box and select an OpenShift group. Repeat this process to define multiple administrator groups.

  3. Select your Open Data Hub user groups: Under Data science user groups, click the text box and select an OpenShift group. Repeat this process to define multiple user groups.

    Important
    		 The system:authenticated setting allows all users authenticated in OpenShift to access Open Data Hub.

  4. Click Save changes.

Verification

  • Administrator users can successfully log in to Open Data Hub and have access to the Settings navigation menu.

  • Non-administrator users can successfully log in to Open Data Hub. They can also access and use individual components, such as projects and workbenches.

Customizing the dashboard

The Open Data Hub dashboard provides features that are designed to work for most scenarios. These features are configured in the OdhDashboardConfig custom resource (CR).

To see a description of the options in the Open Data Hub dashboard configuration, see Dashboard configuration options.

As an Open Data Hub administrator, you can customize the interface of the dashboard. For example, you can show or hide some of the dashboard navigation menu items. To change the default settings of the dashboard, edit the OdhDashboardConfig CR as described in Editing the dashboard configuration.

Editing the dashboard configuration

As an Open Data Hub administrator, you can customize the interface of the dashboard by editing the dashboard configuration.

Prerequisites

  • You have Open Data Hub administrator privileges.

Procedure

  1. Log in to the OpenShift Container Platform console as a user with Open Data Hub administrator privileges.

  2. In the Administrator perspective, click Home → API Explorer.

  3. In the search bar, enter OdhDashboardConfig to filter by kind.

  4. Click the OdhDashboardConfig custom resource (CR) to open the resource details page.

  5. From the Project list, select the Open Data Hub application namespace; the default is opendatahub.

  6. Click the Instances tab.

  7. Click the odh-dashboard-config instance to open the details page.

  8. Click the YAML tab.

  9. Edit the values of the options that you want to change.

    For example, to show or hide a menu item in the dashboard navigation menu, update the spec.dashboardConfig section to edit the relevant dashboard configuration option.

    Note

    If a dashboard configuration option is not included in the OdhDashboardConfig CR, the default value is used.

    To change the default behavior for such options, edit the OdhDashboardConfig CR to add the missing entry to the spec.dashboardConfig section, and set the preferred value:

    • To show the feature, set the value to false

    • To hide the feature, set the value to true

    Example

    By default, the Distributed workloads menu item is shown in the dashboard navigation menu. To hide this menu item, set the disableDistributedWorkloads value to true, as follows:

    disableDistributedWorkloads: true

    For more information about dashboard configuration options and their default values, see Dashboard configuration options.

  10. Click Save to apply your changes and then click Reload to synchronize your changes to the cluster.

Verification

  • Log in to Open Data Hub and verify that your dashboard configurations apply.

Dashboard configuration options

The Open Data Hub dashboard includes a set of core features enabled by default that are designed to work for most scenarios. Open Data Hub administrators can configure the Open Data Hub dashboard from the OdhDashboardConfig custom resource (CR) in OpenShift Container Platform.

If a dashboard configuration option is not included in the OdhDashboardConfig CR, the default value is used. To change the default behavior for such options, edit the OdhDashboardConfig CR to add the missing entry to the spec.dashboardConfig section, and set the preferred value:

  • To show the feature, set the value to false

  • To hide the feature, set the value to true

For more information about setting dashboard configuration options, see Editing the dashboard configuration.

Table 1. Dashboard feature configuration options
Feature configuration option Default Description

spec.dashboardConfig.
disableAcceleratorProfiles

false

Shows the Settings → Accelerator profiles menu item in the dashboard navigation menu. To hide this menu item, set the value to true.

Note: The spec.dashboardConfig.disableAcceleratorProfiles option is superseded by the spec.dashboardConfig.disableHardwareProfiles option. If both options are set to false, the disableHardwareProfiles option overrides the disableAcceleratorProfiles option, and the Settings → Hardware profiles menu item is shown in the dashboard navigation menu.

spec.dashboardConfig.
disableAdminConnectionTypes

false

Shows the Settings → Connection types menu item in the dashboard navigation menu. To hide this menu item, set the value to true.

spec.dashboardConfig.
disableBYONImageStream

false

Shows the Settings → Workbench images menu item in the dashboard navigation menu. To hide this menu item, set the value to true.

spec.dashboardConfig.
disableClusterManager

false

Shows the Settings → Cluster settings menu item in the dashboard navigation menu. To hide this menu item, set the value to true.

spec.dashboardConfig.
disableCustomServingRuntimes

false

Shows the Settings → Serving runtimes menu item in the dashboard navigation menu. To hide this menu item, set the value to true.

spec.dashboardConfig.
disableDistributedWorkloads

false

Shows the Distributed workloads menu item in the dashboard navigation menu. To hide this menu item, set the value to true.

spec.dashboardConfig.
disableFineTuning

(Technology Preview)

true

Hides the Models → Model customization menu item in the dashboard navigation menu, and the LAB-tune menu item and button for registered model versions. To show these items, set the value to false.

LAB-tuning is a Technology Preview feature in this Open Data Hub release.

spec.dashboardConfig.
disableHardwareProfiles

(Technology Preview)

true

Hides the Settings → Hardware profiles menu item in the dashboard navigation menu, and shows the Settings → Accelerator profiles menu item if the spec.dashboardConfig.disableAcceleratorProfiles value is set to false. To show the Settings → Hardware profiles menu item in the dashboard navigation menu, set the value to false.

If both options are set to false, the disableHardwareProfiles option overrides the disableAcceleratorProfiles option, and the Settings → Hardware profiles menu item is shown in the dashboard navigation menu.

Hardware profiles is a Technology Preview feature in this Open Data Hub release.

spec.dashboardConfig.
disableHome

false

Shows the Home menu item in the dashboard navigation menu. To hide this menu item, set the value to true.

spec.dashboardConfig.
disableInfo

false

On the Applications → Explore page, when a user clicks on an application tile, an information panel opens with more details about the application. To disable the information panel for all applications on the Applications → Explore page , set the value to true.

spec.dashboardConfig.
disableISVBadges

false

Shows the label on a tile that indicates whether the application is Red Hat-managed, Partner managed, or Self-managed. To hide these labels, set the value to true.

spec.dashboardConfig.
disableKServe

false

Enables the ability to select KServe as a model-serving platform. To disable this ability, set the value to true.

spec.dashboardConfig.
disableKServeAuth

false

Enables the ability to use authentication with KServe. To disable this ability, set the value to true.

spec.dashboardConfig.
disableKServeMetrics

false

Enables the ability to view KServe metrics. To disable this ability, set the value to true.

spec.dashboardConfig.
disableKServeRaw

false

On the Settings → Cluster settings page, in the Single-model serving platform section, shows the Default deployment mode list.

On the Deploy model dialog when using the single-model serving platform:

      - If the Red Hat OpenShift Serverless Operator and Red Hat OpenShift Service Mesh Operator are installed, shows the Deployment mode list.

      - If the Red Hat OpenShift Serverless Operator and Red Hat OpenShift Service Mesh Operator are not installed, hides the Deployment mode list, and sets the deployment mode to Standard.

To hide these deployment-mode lists and set the deployment mode to Advanced when using the single-model serving platform, set the spec.dashboardConfig.disableKServeRaw value to true.

spec.dashboardConfig.
disableModelCatalog

(Technology Preview)

true

Hides the Models → Model catalog menu item in the dashboard navigation menu. To show this menu item, set the value to false.

Model catalog is a Technology Preview feature in this Open Data Hub release.

spec.dashboardConfig.
disableModelMesh

false

Enables the ability to select ModelMesh as a model-serving platform. To disable this ability, set the value to true.

spec.dashboardConfig.
disableModelRegistry

(Technology Preview)

false

Shows the Models → Model registry menu item and the Settings → Model registry settings menu item in the dashboard navigation menu. To hide these menu items, set the value to true.

Model registry is a Technology Preview feature in this Open Data Hub release.

spec.dashboardConfig.
disableModelRegistrySecureDB

(Technology Preview)

false

Shows the Add CA certificate to secure database connection section in the Create model registry dialog and the Edit model registry dialog. To hide this section, set the value to true.

Model registry is a Technology Preview feature in this Open Data Hub release.

spec.dashboardConfig.
disableModelServing

false

Shows the Models → Model deployments menu item in the dashboard navigation menu, and the Models tab in data science projects. To hide these items, set the value to true.

spec.dashboardConfig.
disableNIMModelServing

false

Enables the ability to select NVIDIA NIM as a model-serving platform. To disable this ability, set the value to true.

spec.dashboardConfig.
disablePerformanceMetrics

false

Shows the Endpoint Performance tab on the Model deployments page. To hide this tab, set the value to true.

spec.dashboardConfig.
disablePipelines

false

Shows the Data science pipelines menu item in the dashboard navigation menu. To hide this menu item, set the value to true.

spec.dashboardConfig.
disableProjects

false

Shows the Data science projects menu item in the dashboard navigation menu. To hide this menu item, set the value to true.

spec.dashboardConfig.
disableProjectScoped

false

Distinguishes between global items and project-scoped items (if project-scoped items exist) in the Open Data Hub web console. This option applies to workbench images, hardware profiles, accelerator profiles, and model-serving runtimes for KServe. To disable this functionality, set the value to true.

spec.dashboardConfig.
disableProjectSharing

false

Allows users to share access to their data science projects with other users. To prevent users from sharing data science projects, set the value to true.

spec.dashboardConfig.
disableServingRuntimeParams

false

Shows the Configuration parameters section in the Deploy model dialog and the Edit model dialog when using the single-model serving platform. To hide this section, set the value to true.

spec.dashboardConfig.
disableStorageClasses

false

Shows the Settings → Storage classes menu item in the dashboard navigation menu. To hide this menu item, set the value to true.

spec.dashboardConfig.
disableSupport

false

Shows the Support menu item when a user clicks the Help icon in the dashboard toolbar. To hide this menu item, set the value to true.

spec.dashboardConfig.
disableTracking

true

Disables the collection of data about Open Data Hub usage in your cluster. To enable data collection, set the value to false. You can also set this option in the Open Data Hub dashboard interface from the Settings → Cluster settings navigation menu.

spec.dashboardConfig.
disableTrustyBiasMetrics

false

Shows the Model Bias tab on the Models page. To hide this tab, set the value to true.

spec.dashboardConfig.
disableUserManagement

false

Shows the Settings → User management menu item in the dashboard navigation menu. To hide this menu item, set the value to true.

spec.dashboardConfig.
enablement

true

Enables Open Data Hub administrators to add applications to the Open Data Hub dashboard Applications → Enabled page. To disable this ability, set the value to false.

spec.groupsConfig

No longer used

Read-only. To configure access to the Open Data Hub dashboard, use the spec.adminGroups and spec.allowedGroups options in the OpenShift Container Platform Auth resource in the services.platform.opendatahub.io API group.

spec.modelServerSizes

Small, Medium, Large

Allows you to customize names and resources for model servers.

spec.notebookController.
enabled

true

Shows the Start basic workbench tile in the Applications section, and the Start basic workbench button on the Data science projects page. To hide these items, set the value to false.

spec.notebookSizes

Small, Medium, Large, X Large

Allows you to customize names and resources for workbenches. The Kubernetes-style sizes are shown in the drop-down menu that appears when launching a workbench with the Notebook Controller.

Note: These sizes must follow conventions. For example, requests must be smaller than limits.

spec.templateOrder

[]

Specifies the order of custom Serving Runtime templates. When the user creates a new template, it is added to this list.

Importing a custom workbench image

You can import custom workbench images that cater to your Open Data Hub project’s specific requirements. From the Workbench images page, you can enable or disable a previously imported workbench image and create an accelerator profile or a hardware profile as a recommended accelerator for existing workbench images.

You must import it so that your Open Data Hub users (data scientists) can access it when they create a project workbench.

Prerequisites

  • You have logged in to Open Data Hub as a user with Open Data Hub administrator privileges.

  • Your custom image exists in an image registry that is accessible to Open Data Hub.

  • The Settings → Workbench images dashboard navigation menu item is enabled, as described in Creating a custom image from a default Open Data Hub image.

  • If you want to associate an accelerator with the custom image that you want to import, you know the accelerator’s identifier - the unique string that identifies the hardware accelerator. You must also have enabled GPU support. This includes installing the Node Feature Discovery and NVIDIA GPU Operators. For more information, see NVIDIA GPU Operator on Red Hat OpenShift Container Platform in the NVIDIA documentation.

Procedure

  1. From the Open Data Hub dashboard, click Settings → Workbench images.

    The Workbench images page appears. Previously imported images are displayed. To enable or disable a previously imported image, on the row containing the relevant image, click the toggle in the Enable column.

  2. Optional: If you want to associate an accelerator and you have not already created an accelerator profile or a hardware profile, click Create profile on the row containing the image and complete the relevant fields. If the image does not contain an accelerator identifier, you must manually configure one before creating an associated accelerator profile or a hardware profile.

  3. Click Import new image. Alternatively, if no previously imported images were found, click Import image.

    The Import workbench image dialog appears.

  4. In the Image location field, enter the URL of the repository containing the image. For example: quay.io/my-repo/my-image:tag, quay.io/my-repo/my-image@sha256:xxxxxxxxxxxxx, or docker.io/my-repo/my-image:tag.

  5. In the Name field, enter an appropriate name for the image.

  6. Optional: In the Description field, enter a description for the image.

  7. Optional: From the Accelerator identifier list, select an identifier to set its accelerator as recommended with the image. If the image contains only one accelerator identifier, the identifier name displays by default.

  8. Optional: Add software to the image. After the import has completed, the software is added to the image’s meta-data and displayed on the workbench creation page.

    1. Click the Software tab.

    2. Click the Add software button.

    3. Click Edit (The Edit icon).

    4. Enter the Software name.

    5. Enter the software Version.

    6. Click Confirm (The Confirm icon) to confirm your entry.

    7. To add additional software, click Add software, complete the relevant fields, and confirm your entry.

  9. Optional: Add packages to the workbench images. After the import has completed, the packages are added to the image’s meta-data and displayed on the workbench creation page.

    1. Click the Packages tab.

    2. Click the Add package button.

    3. Click Edit (The Edit icon).

    4. Enter the Package name. For example, if you want to include data science pipeline V2 automatically, as a runtime configuration, type odh-elyra.

    5. Enter the package Version. For example, type 3.16.7.

    6. Click Confirm (The Confirm icon) to confirm your entry.

    7. To add an additional package, click Add package, complete the relevant fields, and confirm your entry.

  10. Click Import.

Verification

  • The image that you imported is displayed in the table on the Workbench images page.

  • Your custom image is available for selection when a user creates a workbench.

Additional resources

Managing cluster PVC size

Configuring the default PVC size for your cluster

To configure how resources are claimed within your Open Data Hub cluster, you can change the default size of the cluster’s persistent volume claim (PVC) ensuring that the storage requested matches your common storage workflow. PVCs are requests for resources in your cluster and also act as claim checks to the resource.

Prerequisites

  • You have logged in to Open Data Hub as a user with Open Data Hub administrator privileges.

Note
 Changing the PVC setting restarts the workbench pod and makes Jupyter unavailable for up to 30 seconds. As a workaround, it is recommended that you perform this action outside of your organization’s typical working day.
Procedure

  1. From the Open Data Hub dashboard, click Settings → Cluster settings.

  2. Under PVC size, enter a new size in gibibytes or mebibytes.

  3. Click Save changes.

Verification

  • New PVCs are created with the default storage size that you configured.

Additional resources

Restoring the default PVC size for your cluster

To change the size of resources utilized within your Open Data Hub cluster, you can restore the default size of your cluster’s persistent volume claim (PVC).

Prerequisites

  • You have logged in to Open Data Hub as a user with Open Data Hub administrator privileges.

Procedure

  1. From the Open Data Hub dashboard, click Settings → Cluster settings.

  2. Click Restore Default to restore the default PVC size of 20GiB.

  3. Click Save changes.

Verification

  • New PVCs are created with the default storage size of 20 GiB.

Additional resources

Managing connection types

In Open Data Hub, a connection comprises environment variables along with their respective values. Data scientists can add connections to project resources, such as workbenches and model servers.

When a data scientist creates a connection, they start by selecting a connection type. Connection types are templates that include customizable fields and optional default values. Starting with a connection type decreases the time required by a user to add connections to data sources and sinks. Open Data Hub includes pre-installed connection types for S3-compatible object storage databases and URI-based repositories.

As an Open Data Hub administrator, you can manage connection types for users in your organization as follows:

  • View connection types and preview user connection forms

  • Create a connection type

  • Duplicate an existing connection type

  • Edit a connection type

  • Delete a custom connection type

  • Enable or disable a connection type in a project, to control whether it is available as an option to users when they create a connection

Viewing connection types

As an Open Data Hub administrator, you can view the connection types that are available in a project.

Prerequisites

  • You have logged in to Open Data Hub as a user with Open Data Hub administrator privileges.

Procedure

  1. From the Open Data Hub dashboard, click Settings → Connection types.

    The Connection types page appears, displaying the available connection types for the current project.

  2. Optionally, you can select the Options menu Options menu and then click Preview to see how the connection form associated with the connection type appears to your users.

Creating a connection type

As an Open Data Hub administrator, you can create a connection type for users in your organization.

You can create a new connection type as described in this procedure or you can create a copy of an existing connection type and edit it, as described in Duplicating a connection type.

Prerequisites

  • You have logged in to Open Data Hub as a user with Open Data Hub administrator privileges.

  • You know the environment variables that are required or optional for the connection type that you want to create.

Procedure

  1. From the Open Data Hub dashboard, click Settings → Connection types.

    The Connection types page appears, displaying the available connection types.

  2. Click Create connection type.

  3. In the Create connection type form, enter the following information:

    1. Enter a name for the connection type.

      A resource name is generated based on the name of the connection type. A resource name is the label for the underlying resource in OpenShift.

    2. Optionally, edit the default resource name. Note that you cannot change the resource name after you create the connection type.

    3. Optionally, provide a description of the connection type.

    4. Specify at least one category label. By default, the category labels are database, model registry, object storage, and URI. Optionally, you can create a new category by typing the new category label in the field. You can specify more than one category.

      The category label is for descriptive purposes only. It allows you and the users in your origanization to sort the available connection types when viewing them in the Open Data Hub dashboard interface.

    5. Check the Enable users in your organization to use this connection type when adding connections" option if you want the connection type to appear in the list of connections available to users, for example, when they configure a workbench, a model server, or a pipeline.

      Note that you can also enable/disable the connection type after you create it.

    6. For the Fields section, add the fields and section headings that you want your users to see in the form when they add a connection to a project resource (such as a workbench or a model server).

      Note that the connection name and description fields are included by default, so you do not need to add them.

      • Optionally, select a model serving compatible type to automatically add the fields required to use its corresponding model serving method.

      • Click Add field to add a field to prompt users to input information, and optionally assign default values to those fields.

      • Click Add section heading to organize the fields under headings.

  4. Click Preview to open a preview of the connection form as it will appear to your users.

  5. Click Save.

Verification

  1. On the Settings → Connection types page, the new connection type appears in the list.

Duplicating a connection type

As an Open Data Hub administrator, you can create a new connection type by duplicating an existing one, as described in this procedure, or you can create a new connection type as described in Creating a connection type.

You might also want to duplicate a connection type if you want to create versions of a specific connection type.

Prerequisites

  • You have logged in to Open Data Hub as a user with Open Data Hub administrator privileges.

Procedure

  1. From the Open Data Hub dashboard, click Settings → Connection types.

  2. From the list of available connection types, find the connection type that you want to duplicate.

    Optionally, you can select the Options menu Options menu and then click Preview to see how the related connection form appears to your users.

  3. Click the Options menu Options menu, and then click Duplicate.

    The Create connection type form appears populated with the information from the connection type that you duplicated.

  4. Edit the form according to your use case.

  5. Click Preview to open a preview of the connection form as it will appear to your users and verify that the form appears as you expect.

  6. Click Save.

Verification

In the Settings → Connection types page, the duplicated connection type appears in the list.

Editing a connection type

As an Open Data Hub administrator, you can edit a connection type for users in your organization.

Note that you cannot edit the connection types that are pre-installed with Open Data Hub. Instead, you have the option of duplicating a pre-installed connection type, as described in Duplicating a connection type.

When you edit a connection type, your edits do not apply to any existing connections that users previously created. If you want to keep track of previous versions of this connection type, consider duplicating it instead of editing it.

Prerequisites

  • You have logged in to Open Data Hub as a user with Open Data Hub administrator privileges.

  • The connection type must exist and must not be a pre-installed connection type (which you are unable to edit).

Procedure

  1. From the Open Data Hub dashboard, click Settings → Connection types.

  2. From the list of available connection types, find the connection type that you want to edit.

  3. Click the Options menu Options menu, and then click Edit.

    The Edit connection type form appears.

  4. Edit the form fields and sections.

  5. Click Preview to open a preview of the connection form as it will appear to your users and verify that the form appears as you expect.

  6. Click Save.

Verification

In the Settings → Connection types page, the duplicated connection type appears in the list.

Enabling a connection type

As an Open Data Hub administrator, you can enable or disable a connection type to control whether it is available as an option to your users when they create a connection.

Note that if you disable a connection type, any existing connections that your users created based on that connection type are not effected.

Prerequisites

  • You have logged in to Open Data Hub as a user with Open Data Hub administrator privileges.

  • The connection type that you want to enable exists in your project, either pre-installed or created by a user with administrator privileges.

Procedure

  1. From the Open Data Hub dashboard, click Settings → Connection types.

  2. From the list of available connection types, find the connection type that you want to enable or disable.

  3. On the row containing the connection type, click the toggle in the Enable column.

Verification

  • If you enabled a connection type, it is available for selection when a user adds a connection to a project resource (for example, a workbench or model server).

  • If you disabled a connection type, it does not show in the list of available connection types when a user adds a connection to a project resource.

Deleting a connection type

As an Open Data Hub administrator, you can delete a connection type that you or another administrator created.

Note that you cannot delete the connection types that are pre-installed with Open Data Hub. Instead, you have the option of disabling them so that they are not visible to your users, as described in Enabling a connection type.

Prerequisites

  • You have logged in to Open Data Hub as a user with Open Data Hub administrator privileges.

  • The connection type must exist and must not be a pre-installed connection type (which you are unable to delete).

Procedure

  1. From the Open Data Hub dashboard, click Settings → Connection types.

  2. From the list of available connection types, find the connection type that you want to delete.

    Optionally, you can select the Options menu Options menu and then click Preview to see how the related connection form appears to your users.

  3. Click the Options menu Options menu, and then click Delete.

  4. In the Delete connection type? form, type the name of the connection type that you want to delete and then click Delete.

Verification

In the Settings → Connection types page, the connection type no longer appears in the list.

Managing storage classes

OpenShift Container Platform cluster administrators use storage classes to describe the different types of storage that is available in their cluster. These storage types can represent different quality-of-service levels, backup policies, or other custom policies set by cluster administrators.

About persistent storage

Open Data Hub uses persistent storage to support workbenches, project data, and model training.

Persistent storage is provisioned through OpenShift Container Platform storage classes and persistent volumes. Volume provisioning and data access are determined by access modes.

Understanding storage classes and access modes can help you choose the right storage for your use case and avoid potential risks when sharing data across multiple workbenches.

Storage classes in Open Data Hub

Storage classes in Open Data Hub are available from the underlying OpenShift cluster. A storage class defines how persistent volumes are provisioned, including which storage backend is used and what access modes the provisioned volumes can support. For more information, see Dynamic provisioning in the OpenShift documentation.

Cluster administrators create and configure storage classes in the OpenShift cluster. These storage classes provision persistent volumes that support one or more access modes, depending on the capabilities of the storage backend. Open Data Hub administrators then enable specific storage classes and access modes for use in Open Data Hub.

When adding cluster storage to your project or workbench, you can choose from any enabled storage classes and access modes.

Access modes

Storage classes create persistent volumes that can support different access modes, depending on the storage backend. Access modes control how a volume can be mounted and used by one or more workbenches. If a storage class allows more than one access mode, you can select the one that best fits your needs when you request storage. All persistent volumes support ReadWriteOnce (RWO) by default.

Access mode Description

ReadWriteOnce (RWO) (Default)

The storage can be attached to a single workbench or pod at a time and is ideal for most individual workloads. RWO is always enabled by default and cannot be disabled by the administrator.

ReadWriteMany (RWX)

The storage can be attached to many workbenches simultaneously. RWX enables shared data access, but can introduce data risks.

ReadOnlyMany (ROX)

The storage can be attached to many workbenches as read-only. ROX is useful for sharing reference data without allowing changes.

ReadWriteOncePod (RWOP)

The storage can be attached to a single pod on a single node with read-write permissions. RWOP is similar to RWO but includes additional node-level restrictions.
Using shared storage (RWX)

The ReadWriteMany (RWX) access mode allows multiple workbenches to access and write to the same storage volume at the same time. Use RWX access mode for collaborative work where multiple users need to access shared datasets or project files.

However, shared storage introduces several risks:

  • Data corruption or data loss: If multiple workbenches modify the same part of a file simultaneously, the data can become corrupted or lost. Ensure your applications or workflows are designed to safely handle shared access, for example, by using file locking or database transactions.

  • Security and privacy: If a workbench with access to shared storage is compromised, all data on that volume might be at risk. Only share sensitive data with trusted workbenches and users.

To use shared storage safely:

  • Ensure that your tools or workflows are designed to work with shared storage and can manage simultaneous writes. For example, use databases or distributed data processing frameworks.

  • Be cautious with changes. Deleting or editing files affects everyone who shares the volume.

  • Back up your data regularly, which can help prevent data loss due to mistakes or misconfigurations.

  • Limit access to RWX volumes to trusted users and secure workbenches.

  • Use ReadWriteMany (RWX) only when collaboration on a shared volume is required. For most individual tasks, ReadWriteOnce (RWO) is ideal because only one workbench can write to the volume at a time.

Configuring storage class settings

As an Open Data Hub administrator, you can manage the following OpenShift Container Platform cluster storage class settings for use within Open Data Hub:

  • Display name

  • Description

  • Access modes

  • Whether users can use the storage class when creating or editing cluster storage

These settings do not impact the storage class within OpenShift Container Platform.

Prerequisites

  • You have logged in to Open Data Hub as a user with Open Data Hub administrator privileges.

Procedure

  1. From the Open Data Hub dashboard, click Settings → Storage classes.

    The Storage classes page appears, displaying the storage classes for your cluster as defined in OpenShift Container Platform.

  2. To enable or disable a storage class for users, on the row containing the storage class, click the toggle in the Enable column.

  3. To edit a storage class, on the row containing the storage class, click the action menu (⋮) and then select Edit.

    The Edit storage class details dialog opens.

  4. Optional: In the Display Name field, update the name for the storage class. This name is used only in Open Data Hub and does not impact the storage class within OpenShift Container Platform.

  5. Optional: In the Description field, update the description for the storage class. This description is used only in Open Data Hub and does not impact the storage class within OpenShift Container Platform.

  6. For storage classes that support multiple access modes, select an Access mode to define how the volume can be accessed. For more information, see About persistent storage.

    Only the access modes that have been enabled for the storage class by your cluster and Open Data Hub administrators are visible.

  7. Click Save.

Verification

  • If you enabled a storage class, the storage class is available for selection when a user adds cluster storage to a data science project or workbench.

  • If you disabled a storage class, the storage class is not available for selection when a user adds cluster storage to a data science project or workbench.

  • If you edited a storage class name, the updated storage class name is displayed when a user adds cluster storage to a data science project or workbench.

Additional resources

Configuring the default storage class for your cluster

As an Open Data Hub administrator, you can configure the default storage class for Open Data Hub to be different from the default storage class in OpenShift Container Platform.

Prerequisites

  • You have logged in to Open Data Hub as a user with Open Data Hub administrator privileges.

Procedure

  1. From the Open Data Hub dashboard, click Settings → Storage classes.

    The Storage classes page appears, displaying the storage classes for your cluster as defined in OpenShift Container Platform.

  2. If the storage class that you want to set as the default is not enabled, on the row containing the storage class, click the toggle in the Enable column.

  3. To set a storage class as the default for Open Data Hub, on the row containing the storage class, select Set as default.

Verification

  • When a user adds cluster storage to a data science project or workbench, the default storage class that you configured is automatically selected.

Additional resources

Overview of object storage endpoints

To ensure correct configuration of object storage in Open Data Hub, you must format endpoints correctly for the different types of object storage supported. These instructions are for formatting endpoints for Amazon S3, MinIO, or other S3-compatible storage solutions, minimizing configuration errors and ensuring compatibility.

Important

Properly formatted endpoints enable connectivity and reduce the risk of misconfigurations. Use the appropriate endpoint format for your object storage type. Improper formatting might cause connection errors or restrict access to storage resources.

MinIO (On-Cluster)

For on-cluster MinIO instances, use a local endpoint URL format. Ensure the following when configuring MinIO endpoints:

  • Prefix the endpoint with http:// or https:// depending on your MinIO security setup.

  • Include the cluster IP or hostname, followed by the port number if specified.

  • Use a port number if your MinIO instance requires one (default is typically 9000).

Example:

http://minio-cluster.local:9000
Note

Verify that the MinIO instance is accessible within the cluster by checking your cluster DNS settings and network configurations.

Amazon S3

When configuring endpoints for Amazon S3, use region-specific URLs. Amazon S3 endpoints generally follow this format:

  • Prefix the endpoint with https://.

  • Format as <bucket-name>.s3.<region>.amazonaws.com, where <bucket-name> is the name of your S3 bucket, and <region> is the AWS region code (for example, us-west-1, eu-central-1).

Example:

https://my-bucket.s3.us-west-2.amazonaws.com
Note

For improved security and compliance, ensure that your Amazon S3 bucket is in the correct region.

Other S3-Compatible Object Stores

For S3-compatible storage solutions other than Amazon S3, follow the specific endpoint format required by your provider. Generally, these endpoints include the following items:

  • The provider base URL, prefixed with https://.

  • The bucket name and region parameters as specified by the provider.

  • Review the documentation from your S3-compatible provider to confirm required endpoint formats.

  • Replace placeholder values like <bucket-name> and <region> with your specific configuration details.

Warning

Incorrectly formatted endpoints for S3-compatible providers might lead to access denial. Always verify the format in your storage provider documentation to ensure compatibility.

Verification and Troubleshooting

After configuring endpoints, verify connectivity by performing a test upload or accessing the object storage directly through the Open Data Hub dashboard. For troubleshooting, check the following items:

  • Network Accessibility: Confirm that the endpoint is reachable from your Open Data Hub cluster.

  • Authentication: Ensure correct access credentials for each storage type.

  • Endpoint Accuracy: Double-check the endpoint URL format for any typos or missing components.

Additional resources

Managing basic workbenches

Accessing the administration interface for basic workbenches

You can use the administration interface to control basic workbenches in your Open Data Hub environment.

Prerequisite

  • You have logged in to Open Data Hub as a user with Open Data Hub administrator privileges.

Procedure

  • To access the administration interface for basic workbenches from Open Data Hub, perform the following actions:

    1. In Open Data Hub, in the Applications section of the left menu, click Enabled.

    2. Locate the Start basic workbench tile and click Launch application.

    3. On the page that opens when you launch a basic workbench, click the Administration tab.

      The Administration page opens.

  • To access the administration interface for basic workbenches from JupyterLab, perform the following actions:

    1. Click File → Hub Control Panel.

    2. On the page that opens in Open Data Hub, click the Administration tab.

      The Administration page opens.

Verification

  • You can see the administration interface for basic workbenches.

Starting basic workbenches owned by other users

Open Data Hub administrators can start a basic workbench for another existing user from the administration interface for basic workbenches.

Prerequisites

  • You have logged in to Open Data Hub as a user with Open Data Hub administrator privileges.

  • You have launched the Start basic workbench application, as described in Starting a basic workbench.

Procedure

  1. On the page that opens when you launch a basic workbench, click the Administration tab.

  2. On the Administration tab, perform the following actions:

    1. In the Users section, locate the user whose workbench you want to start.

    2. Click Start workbench beside the relevant user.

    3. Complete the Start a basic workbench page.

    4. Optional: Select the Start workbench in current tab checkbox if necessary.

    5. Click Start workbench.

      After the server starts, you see one of the following behaviors:

      • If you previously selected the Start workbench in current tab checkbox, the JupyterLab interface opens in the current tab of your web browser.

      • If you did not previously select the Start workbench in current tab checkbox, the Workbench status dialog box prompts you to open the server in a new browser tab or in the current tab.

        The JupyterLab interface opens according to your selection.

Verification

  • The JupyterLab interface opens.

Accessing basic workbenches owned by other users

Open Data Hub administrators can access basic workbenches that are owned by other users to correct configuration errors or to help them troubleshoot problems with their environment.

Prerequisites

  • You have logged in to Open Data Hub as a user with Open Data Hub administrator privileges.

  • You have launched the Start basic workbench application, as described in Starting a basic workbench.

  • The workbench that you want to access is running.

Procedure

  1. On the page that opens when you launch a basic workbench, click the Administration tab.

  2. On the Administration page, perform the following actions:

    1. In the Users section, locate the user that the workbench belongs to.

    2. Click View server beside the relevant user.

    3. On the Workbench control panel page, click Access workbench.

Verification

  • The JupyterLab interface opens in the user’s workbench.

Stopping basic workbenches owned by other users

Open Data Hub administrators can stop basic workbenches that are owned by other users to reduce resource consumption on the cluster, or as part of removing a user and their resources from the cluster.

Prerequisites

  • You have logged in to Open Data Hub as a user with Open Data Hub administrator privileges.

  • You have launched the Start basic workbench application, as described in Starting a basic workbench.

  • The workbench that you want to stop is running.

Procedure

  1. On the page that opens when you launch a basic workbench, click the Administration tab.

  2. Stop one or more servers.

    • If you want to stop one or more specific servers, perform the following actions:

      1. In the Users section, locate the user that the workbench belongs to.

      2. To stop the workbench, perform one of the following actions:

        • Click the action menu (⋮) beside the relevant user and select Stop server.

        • Click View server beside the relevant user and then click Stop workbench.

          The Stop server dialog box appears.

      3. Click Stop server.

    • If you want to stop all workbenches, perform the following actions:

      1. Click the Stop all workbenches button.

      2. Click OK to confirm stopping all servers.

Verification

  • The Stop server link beside each server changes to a Start workbench link when the workbench has stopped.

Stopping idle workbenches

You can reduce resource usage in your Open Data Hub deployment by stopping workbenches that have been idle (without logged in users) for a period of time. This is useful when resource demand in the cluster is high. By default, idle workbenches are not stopped after a specific time limit.

Note

If you have configured your cluster settings to disconnect all users from a cluster after a specified time limit, then this setting takes precedence over the idle workbench time limit. Users are logged out of the cluster when their session duration reaches the cluster-wide time limit.
Prerequisites

  • You have logged in to Open Data Hub as a user with Open Data Hub administrator privileges.

Procedure

  1. From the Open Data Hub dashboard, click Settings → Cluster settings.

  2. Under Stop idle workbenches, select Stop idle workbenches after.

  3. Enter a time limit, in hours and minutes, for when idle workbenches are stopped.

  4. Click Save changes.

Verification

  • The notebook-controller-culler-config ConfigMap, located in the redhat-ods-applications project on the Workloads → ConfigMaps page, contains the following culling configuration settings:

    • ENABLE_CULLING: Specifies if the culling feature is enabled or disabled (this is false by default).

    • IDLENESS_CHECK_PERIOD: The polling frequency to check for a notebook’s last known activity (in minutes).

    • CULL_IDLE_TIME: The maximum allotted time to scale an inactive notebook to zero (in minutes).

  • Idle workbenches stop at the time limit that you set.

Adding workbench pod tolerations

If you want to dedicate certain machine pools to only running workbench pods, you can allow workbench pods to be scheduled on specific nodes by adding a toleration. Taints and tolerations allow a node to control which pods should (or should not) be scheduled on them. For more information, see Understanding taints and tolerations.

This capability is useful if you want to make sure that workbenches are placed on nodes that can handle their needs. By preventing other workloads from running on these specific nodes, you can ensure that the necessary resources are available to users who need to work with large workbench sizes.

Prerequisites

  • You have logged in to Open Data Hub as a user with Open Data Hub administrator privileges.

  • You are familiar with OpenShift Container Platform taints and tolerations, as described in Understanding taints and tolerations.

Procedure

  1. From the Open Data Hub dashboard, click Settings → Cluster settings.

  2. Under Workbench pod tolerations, select Add a toleration to workbench pods to allow them to be scheduled to tainted nodes.

  3. In the Toleration key for workbench pods field, enter a toleration key. The key is any string, up to 253 characters. The key must begin with a letter or number, and can contain letters, numbers, hyphens, dots, and underscores. For example, workbenches-only.

  4. Click Save changes. The toleration key is applied to new workbench pods when they are created.

    For existing workbench pods, the toleration key is applied when the workbench pods are restarted. If you are using a basic workbench, see Updating workbench settings by restarting your workbench. If you are using a workbench in a data science project, see Starting a workbench.

Next step

In OpenShift Container Platform, add a matching taint key (with any value) to the machine pools that you want to dedicate to workbenches. For more information, see Controlling pod placement using node taints.

Verification

  1. In the OpenShift Container Platform console, for a pod that is running, click Workloads → Pods. Otherwise, for a pod that is stopped, click Workloads → StatefulSet.

  2. Search for your workbench pod name and then click the name to open the pod details page.

  3. Confirm that the assigned Node and Tolerations are correct.

Troubleshooting common problems in workbenches for administrators

If your users are experiencing errors in Open Data Hub relating to Jupyter, their Jupyter notebooks, or their workbench, read this section to understand what could be causing the problem, and how to resolve the problem.

A user receives a 404: Page not found error when logging in to Jupyter

Problem

If you have configured Open Data Hub user groups, the user name might not be added to the default user group for Open Data Hub.

Diagnosis

Check whether the user is part of the default user group.

  1. Find the names of groups allowed access to Jupyter.

    1. Log in to the OpenShift Container Platform web console.

    2. Click User Management → Groups.

    3. Click the name of your user group, for example, {oai-user-group}.

      The Group details page for that group appears.

  2. Click the Details tab for the group and confirm that the Users section for the relevant group contains the users who have permission to access Jupyter.

Resolution

  • If the user is not added to any of the groups allowed access to Jupyter, add them.

A user’s workbench does not start

Problem

The OpenShift Container Platform cluster that hosts the user’s workbench might not have access to enough resources, or the workbench pod may have failed.

Diagnosis

  1. Log in to the OpenShift Container Platform web console.

  2. Delete and restart the workbench pod for this user.

    1. Click Workloads → Pods and set the Project to rhods-notebooks.

    2. Search for the workbench pod that belongs to this user, for example, jupyter-nb-<username>-*.

      If the workbench pod exists, an intermittent failure may have occurred in the workbench pod.

      If the workbench pod for the user does not exist, continue with diagnosis.

  3. Check the resources currently available in the OpenShift Container Platform cluster against the resources required by the selected workbench image.

    If worker nodes with sufficient CPU and RAM are available for scheduling in the cluster, continue with diagnosis.

  4. Check the state of the workbench pod.

Resolution

  • If there was an intermittent failure of the workbench pod:

    1. Delete the workbench pod that belongs to the user.

    2. Ask the user to start their workbench again.

  • If the workbench does not have sufficient resources to run the selected workbench image, either add more resources to the OpenShift Container Platform cluster, or choose a smaller image size.

The user receives a database or disk is full error or a no space left on device error when they run notebook cells

Problem

The user might have run out of storage space on their workbench.

Diagnosis

  1. Log in to Jupyter and start the workbench that belongs to the user having problems. If the workbench does not start, follow these steps to check whether the user has run out of storage space:

    1. Log in to the OpenShift Container Platform web console.

    2. Click Workloads → Pods and set the Project to rhods-notebooks.

    3. Click the workbench pod that belongs to this user, for example, jupyter-nb-<idp>-<username>-*.

    4. Click Logs. The user has exceeded their available capacity if you see lines similar to the following:

      Unexpected error while saving file: XXXX database or disk is full
Resolution

  • Increase the user’s available storage by expanding their persistent volume.

  • Work with the user to identify files that can be deleted from the /opt/app-root/src directory on their workbench to free up their existing storage space.

Note

When you delete files using the JupyterLab file explorer, the files move to the hidden /opt/app-root/src/.local/share/Trash/files folder in the persistent storage for the workbench. To free up storage space for workbenches, you must permanently delete these files.