Release NotesPDF version

Known Issues

You might run into some known issues while using Cloudera Machine Learning on Private Cloud.

On RHEL 8.8, during the first CML workspace installation on GPU with Embedded Container Service external registry, pods might get stuck in the init or crashloop state.

First-time workspace installation is expected to fail. Cloudera recommends that you consider this as a test workspace, and apply the following manual workaround for creating subsequent workspaces:
  1. Restart or delete the pods which are in init or crashloop state in the test workspace.
  2. Once all pods are in the running state, create new workspaces as needed.
  3. Delete the test workspace from the CML UI if no longer needed.

With this bug present on Private Cloud Data Services 1.5.2 and 1.5.3, Runtime repositories added on the Site Administration>Runtimes page will not be scanned for new Runtimes. Adding Runtime repositories to CML was a new feature in 1.5.2. Unfortunately with this bug, the feature is completely unusable.

Workaround:

Manually enable Runtime updates with an API call using the legacy API key of the adminitsrator user. That will let CML check the registered runtime registries for new runtimes every 24 hours. The syntax of the API call is as follows:
curl 'https://<CML_URL>/api/v1/site/config' \
-X 'PATCH' \
-u <ADMIN_APIv1_KEY>: \
-H 'content-type: application/json' \ 
-d '{"enable_runtime_updates":true}'

Changing the default Hadoop CLI Runtime Addon causes jobs, models, and application workloads to be unable to start up.

Workaround:
  1. Open affected workload settings.
  2. Update the workload (this updates the Hadoop CLI Addon associated with the workload to the default one.)
  3. For Jobs: update.
  4. For Applications: update and restart.
  5. For Models: deploy a new build.
Please see Machine Learning Site administration>Disable Addons for related tasks.

Scala and R are not supported for Spark Pushdown.

Workaround: None.

When you enable the Unified timezone feature, the ECS cluster timezone is synchronized with the Cloudera Manager Base time zone, and the CML sessions will fail to launch with Exit Code 34. You will also see timestamp discrepancies with workloads. For more information, see ENGESC-28507.

Workaround:

If you use CML workspaces, disable the Unified Timezone feature by following the instructions in ECS unified time zone.