Cloudera Docs

Known issues in 1.5.5 SP1

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

Cloudera AI on premises 1.5.5 existing known issues are carried into Cloudera AI on premises 1.5.5 SP1. For more details, see Known issues for Cloudera AI on premises 1.5.5. For known issues fixed since Cloudera AI on premises 1.5.5, see Fixed issues in 1.5.5 SP1.

DSE-47608: Update Hive on Base to use the correct SSL configuration value

SSL is always set to true when discovering the Hive on TEZ data connection, regardless of whether SSL is enabled.

Workaround:

As a workaround, the JDBC URL can be modified by editing the data connection settings.

DSE-47480: MLUsers are able to delete other users' deployed endpoints

Cloudera AI Inference service lacks fine-grained authorization, allowing endpoints created by one user to be deleted by another user.

DSE-47517: Parallel backup or restore during other ongoing Platform actions ends up workbench in failed state

Backup and restore actions lack validation checks for ongoing platform actions, leading to conflicts when triggered simultaneously with other platform actions.

No workaround exists for this issue. However, Cloudera recommends avoiding the initiation of any other workbench actions while a platform action is in progress on the same workbench.

DSE-46826: Registry upgrade is incorrectly returning 500 even though upgrade flow is being triggered

The registry upgrade process returns an HTTP 500 error in the UI and CLI, despite successfully completing in the background. The issue is linked to missing records and Docker secrets, likely due to recent changes in secrets handling.

Workaround:

Recreating the Cloudera AI Registry with valid Ozone credentials resolves the error and ensures that the upgrade completes successfully.

DSE-47916: Update storage configuration option overwrites the S3 Region parameter

The S3 Region parameter with an empty value overwrites the existing s3Region value when using the Update storage configuration option in the UI or the updateMlServingAppS3Creds API. This causes model deployment failures, as updating only the mandatory fields clears the s3Region value, leading to authorization errors.

Workaround:

Always include the S3 Region parameter when using either the updateMlServingAppS3Creds API or the Update storage configuration option in the UI.

DSE-47973: Update Storage Configuration disabled in Update Creds failed state

If the credentials update fails, the S3 storage configuration cannot be updated. Additionally, the UI does not display a warning to inform the user that the S3 storage configuration has been disabled.

DSE-48821: Dashboards referenced by applications must not be cleaned up

In Cloudera AI, after cleaning up outdated dashboards in the database, certain applications might disappear from the Application page of the Cloudera AI. Also, you might receive the following error message: Cannot read properties of null (reading ‘creator’).

The deletion of older records in the dashboards table was carried out to address web-to-database query performance issues caused by an excessive number of entries. However, if an application continues to reference an old dashboard and the application is not marked as deleted, the referenced dashboard ID in the applications table is automatically set to NULL value due to a trigger defined on the constraints.

This issue occurs only when the Automated Database Cleanup feature is enabled or when a Manual Cleanup script is used. For more information, see Historical workload cleanup settings and Cleaning up and backing up the Cloudera AI Workbench database manually.

Workaround:

  1. Identify the affected applications using the following query:
    current_dashboard_id is set to null but not deleted apps
    sense=# select a.current_dashboard_id,a.id,a.name, a.description,u.username,u.email from applications a, users u where a.creator_id=u.id and a.current_dashboard_id is null and a.deleted_at is null;
        
        current_dashboard_id | id |         name         |     description      | username |       email
        ----------------------+----+----------------------+----------------------+----------+-------------------
        | 75 | Recreate Application | Recreate Application | admin    | [email protected]
        (1 row)

  2. Update the dashboard reference (current_dashboard_id) to a fixed existing one.

    After this update, the application logs might point to a different application. This issue will be resolved once you restart the application using Step 4, as Cloudera AI will automatically assign the correct dashboard ID.

    sense=# select  id,application_id from dashboards where application_id is not null limit 1;
        id        | application_id
        ------------------+----------------
        268uw5z5fui1iypl |             69
    1. Update the current dashboard to the existing one of all affected applications using the following command:
      update applications set current_dashboard_id='268uw5z5fui1iypl' where applications.current_dashboard_id is null and applications.deleted_at is null;

      At this stage, you can access the Applications page, however, unexpected logs might appear as the application is temporarily linked to an unrelated dashboard.

  3. Restart the affected applications using the details from Step 1, including the application name and the email address of the owner.
    Perform the following steps to restart the application:

    1. In the Cloudera console, click the Cloudera AI tile.

      The Home page displays.

    2. Select the required Workbench.

      The Cloudera AI Workbench page displays.

    3. Open the Cloudera AI console.
    4. Click Projects in the left navigation pane and select the required project.
    5. Go to the project Overview page.
    6. Click Applications.
    7. Find the required application by its Name value.
    8. Click the icon and select Application Details > Settings > Resource Profile > CPU/Memory
    9. Update the application and restart it.
  4. Update the dashboard cleanup procedure to include the following where condition:
    // backup the dashboards table as usual
        // and modify the delete where condition to have
        delete from dashboards where finished_at < NOW() - INTERVAL '1 month' and id not in (select distinct current_dashboard_id from applications where applications.deleted_at is null) ;

This ensures that the referenced dashboards of all active and non-deleted, applications are excluded from the cleanup process.