Known issues in 1.5.5 SP3

You might run into some known issues while using Cloudera AI on premises 1.5.5 SP3.

Cloudera AI on premises 1.5.5, 1.5.5 SP1 and 1.5.5 SP2 existing known issues are carried into Cloudera AI on premises 1.5.5 SP3.

For known issues fixed since Cloudera AI on premises 1.5.5, see:
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.

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.