Known issues for Cloudera AI on premises 1.5.5 SP3

DSE-50448 and DSE-50449 : Cloudera AI API secret exposure for OpenTelemetry (OTel) collectors

To support Observability on Cloudera Data Services on premises, API keys can now be securely exposed as Kubernetes secrets. This enablement allows OpenTelemetry (OTel) collectors to authenticate and access Cloudera APIs directly, ensuring seamless collection of metrics and trace data from the platform.

DSE-55163: Cloudera Data Visualization query with Hive connection fails with error

Queries that use Hive data connections synced from Cloudera Data Warehouse to Cloudera AI fail with the following error: Failed to open new session: Cannot modify applicationName at runtime. It is not in the list of parameters that are allowed to be modified at runtime.

As a result, Hive queries and database listing operations do not work through synced connection.

Workaround: After syncing the connection, open the Edit Data Connection dialog for the failing connection. In the Advanced tab, delete the Application name value and leave the field blank.

DSE-49364: Upgrade Hadoop addon's base image to ubuntu 24.04 LTS

Hadoop Runtime add-on images lower than version 2025.01 are not compatible with 20.04-based Runtime images.

DSE-56531: livelog-publisher crashes when the livelog pod restarts

When a large number of workloads are running in the Cloudera AI Workbench, livelog‑publisher pods might crash and restart. During periods when the livelog‑publisher is unavailable, container logs from active user workloads might be lost. This impacts the content displayed in the Logs tab for Sessions and Jobs, as well as the Container Logs tab for Applications.

Workaround: There is no workaround.

Cloudera AI Inference service

The gemma2, nemotron‑nano‑12b, and paddleocr models are planned for deprecation. Cloudera recommends avoiding these models and selecting alternative options available in Model Hub.

DSE-56443: Cloudera AI UI returns 431 Request Header Fields Too Large error for users belonging to many groups

If you are a member of a large number of groups, you might encounter a 431 Request Header Fields Too Large error when accessing the Cloudera AI Registry using the UI. This occurs because the authentication token grows proportionally with group memberships, and when it exceeds the header size limit of 8 KB, Knox rejects the request.

Workaround: Verify the groups that the user belongs to, remove the user from any unnecessary groups, and then synchronize the environments:

1. Open the Management Console > User Management.
2. Search for the user and open Resource Roles tab.
3. Check which environments the user is attached to.
4. Remove the user from any unnecessary groups.
5. Run a synchronization of environments.

DSE-58058: Model Endpoint Details page fails to render for Cloudera AI Inference service

If you navigate to the Model Endpoint Details page for model endpoints hosted in lower Cloudera AI Inference service versions, the page might fail to render or display an Unknown status in Cloudera AI 1.5.5 SP3. This issue occurs because the user interface (UI) requires backend fields that are absent from lower backend versions.

Workaround:

Upgrade to Cloudera AI 1.5.5 SP3 and higher releases.

DSE-59376: Updating existing jobs fails in Cloudera AI 1.5.5 SP3 on Cloudera Embedded Container Service

After upgrading to Cloudera AI 1.5.5 SP3 on Cloudera Embedded Container Service, updating an existing Cloudera AI job, such as changing the runtime, can fail with one of the following validation errors: CPU must be greater than 0 vCPU or Memory must be greater than 0 GiB. Additionally, the Resource Profile displayed in the Update Job configuration always defaults to the first profile in the list instead of displaying the profile currently configured for the job.

Workaround:

1. In the left navigation pane, click Jobs.

   The Jobs Overview page is displayed.

2. Select the relevant job.

   The details of the actual job are displayed.

3. Record the Resource Profile currently configured for the job, including the CPU and memory values. You will use this information when updating the job configuration.
4. Click Update Job.
5. Select the Resource Profile selector.
   • If the configured profile is not the first entry in the list, select the same profile. Verify that the displayed CPU and memory values match the values recorded in step 3.
   • If the configured profile is the first entry in the list, select a different profile, then reselect the original profile.
6. Click Save.

The job updates successfully with the correct resource values.

Known issues for Fine-Grained Access Control

Fine-Grained Access Control is the new permission system for inference endpoints that allows Administrators to control who can View, Access (invoke), or Manage each endpoint.

The following known issues represent initial rollout issues:

UI not respecting permission levels (DSE-57690, DSE- 57699, DSE-57737, DSE-57738)

The frontend currently displays all buttons and actions regardless of the user role. When a user attempts an unauthorized action, the backend correctly denies the request, but the resulting errors can be confusing. The UI currently does not hide or disable actions that the user does not have permission to perform.

DSE-57700: Users with Manage permissions can self‑demote or lock themselves out

Users with Manage permissions on an endpoint can modify their own permission row, allowing them to downgrade or remove themselves entirely. If they are the only users with Manager permission, the endpoint ends up an orphan with no remaining administrator.

DSE-57739: Empty access control creates ghost endpoint and trap state

When an MLAdmin creates an endpoint with Access Control enabled, the Global Access Control list is initially empty. As a result, MLUsers cannot see the endpoint at all (creating a ghost endpoint). Furthermore, after the administrator selects a role in Modify General Access setting, that selection cannot be cleared. This creates a trap state that prevents the access control list from returning an empty state.

DSE-57740: Missing explicit access restrictions (Hide/Deny) to prevent specific MLUsers from viewing endpoints

Currently, an MLAdmin cannot explicitly restrict, hide, or deny access to a specific endpoint for individual users or groups. Because access can only be granted, this prevents multi‑tenancy isolation.

Knox token and API key issues

Knox provides API token–based authentication for programmatic access to inference endpoints, as opposed to UI‑based access.

DSE-57450: Knox API token returning 403 Forbidden

API requests authenticated with newly generated Knox API tokens fail with an HTTP 403 Forbidden response and an empty body. The issue affects calls to service endpoints for example, /api/describeService, on Cloudera on premises deployments.

DSE-57743: UI allows token generation for users missing from Knox DB, resulting in silent inference failures (403)

The Knox API token UI issues authentication tokens without verifying whether the user exists in the Knox database. Consequently, MLUsers or MLAdmins not registered in Knox can successfully generate a token. However, this tokenit is invalid causing all subsequent inference requests to fail with a silent 403 Forbidden error.

DSE-57702: Generate API key fails to copy to clipboard in Incognito or Private browsing

In Incognito or Private browsing mode, clicking Generate API Key creates the Knox API token but fails to copy it to the clipboard, displaying a Failed to copy: API key message. Browsers block clipboard access in private mode, leaving the clipboard empty or unchanged.

DSE-57742: Open Knox UI button redirects to base cluster homepage instead of Knox token management

On the endpoint UI, clicking the Open Knox UI button — intended to let users manage and view their issued tokens — redirects to a generic base cluster URL instead of deep-linking to the Knox service interface.

Quota Management issues

DSE-60253: Default accelerator quota is not updated when requested value equals max_gpu_count

When updating the default accelerator quota for a heterogeneous GPU type, setting the quota value equal to max_gpu_count, that is the maximum number of that accelerator type on any node in the cluster, could result in the API returning a success response without committing the update to the database.

DSE-60254: No UI error is displayed when user or team quotas exceed the Workbench resource pool quota

When a Workbench resource pool has a configured quota for CPU, memory, or GPU resources, and an administrator attempts to set a user or team quota for any of these resource types to a value that exceeds the resource pool quota, the UI accepts the input without displaying a validation error.

The backend API correctly identifies the violation and returns the following error message: gpu: provided value is greater than max quota value for resource pool

DSE-60256: Quota Management Grafana Dashboard does not display values for workloads using Heterogeneous GPUs

When workloads are run using heterogeneous GPUs, environments configured with multiple distinct GPU types, the Quota Management Grafana dashboard fails to display usage values or resource allocation metrics for those workloads. As a result, the administrators cannot use the Quota Management Grafana dashboard to track or audit GPU quota consumption in environments running heterogeneous GPU workloads.

Workaround: Use the Resource Usage, Usage dashboards or the Quota Overview page to view accurate workload usage and heterogeneous GPU count information.

DSE-59835: Heterogeneous GPU custom quota is not reset correctly after reverting to default quota

When resetting a custom heterogeneous GPU quota to the default quota for a user, the system could fail to persist the default quota configuration. Upon launching a workload, the quota reverts to the previously configured custom quota values instead of applying the default quota settings.

DSE-59829: Quota usage for a user is not displayed for heterogeneous GPU

When workloads are actively running on heterogeneous GPU setups, the system could fail to display user quota usage correctly. Quota metrics for CPU, memory, heterogenous GPU resources continuously report zero values (0) despite active resource consumption.

DSE-60259: Resource usage details on the Projects Overview do not display Heterogeneous GPU usage for workloads

When a workload is actively running and using heterogeneous GPU resources, the Projects Overview page fails to display the corresponding resource consumption details.