Known issues for Cloudera Management Console 1.5.5 SP4

Review the known issues for Cloudera Data Services on premises, the impact or changes to the functionality, and the applicable workaround. These issues are specific to Cloudera Management Console.

Known issues identified in 1.5.5 SP4 release

OPSX-8410: (Data Recovery Service): After the secondary cluster restore, stale primary Cloudera Manager values show up: After a secondary cluster restore, some hyperlinks in the management control alerts can have obsolete hyperlinks pointing to the primary Cloudera Manager.; Navigate to Cloudera Manager directly and navigate to the Cloudera Embedded Container Service Web UI.

OPSX-8426: (Data Recovery Service): Workbenches are listed in the secondary cluster even when Cloudera AI was not part of backup and restore: When data services are excluded in a secondary cluster restore, their actual workloads are not restored. But the UIs of the excluded data services can have some obsolete references from primary cluster. This is because Cloudera Control Plane is restored fully in all restores and data services persist some metadata as a part of Control Plane/embedded database.; You must manually clean up these artifacts from Data Services UI.

OPSX-6858: (Data Recovery Service): Vault certificate from the primary cluster is showing up in secondary cluster: Administration → CA certificates is listing one vault cert from primary cluster post secondary cluster restore. Issuer and SAN also show incorrect information.; You must rotate internal certs after a successful restore from Cloudera Manager so that certs generated in secondary cluster are used instead of some certs that get copied over from the primary cluster.

OPSX-8380: (Data Recovery Service): Full platform backup does not include newly enabled data services: Enabling a new Data Service will not add it automatically to existing ‘Full Platform’ backups. Users must create a new backup policy if they need to backup the newly added Data Service. Also, if an existing Data service is deleted completely, existing ‘Full platform’ backups fail.; A new backup policy should be created.

OPSX-8409: (Data Recovery Service): Restoring SAML from primary to secondary fails SAML login with an invalid URI: Any settings/configurations done outside the Cloudera Management Console to enable SAML needs to be reviewed after a secondary restore.; References of ‘primary control plane’ in such external configurations should be changed to ‘secondary control plane’ after secondary cluster restore is successful. Failing to do this can trigger auth/login issues

OPSX-8406: (Data Recovery Service): The Node taint annotations from Pods are restored but if taint is not present, restore operation fails: If node tainting feature was enabled in the primary cluster, then the same/similar configurations should be enabled in the secondary cluster as well; None

OPSX-8349: (Data Recovery Service): Backup fails with about 12 environments with timeout: Users must revert to the old external Data Recovery Service settings that was supported using Longhorn’s BackupTarget feature.
These settings can negatively impact the new DRS (Velero based) solution by consuming more storage/resources/network and can cause Backups to take a long time or even fail.; None

OPSX-8538: (Data Recovery Service): Re-restore NamespaceDeleter fails: orchestrators recreate VW namespaces during the delete operation: Deletion of some Cloudera Data Warehouse namespaces time out causing same/primary cluster restores to fail (Race condition/intermittent issue).; Scale down cdp-release-dwx-server and cdp-release-dwx-worker deployments in cdp namespace and then re-trigger the restore operation.

OPSX-8537: (Data Recovery Service): CNPG operator Out of Memory at 500Mi blocks the restore gate — Embedded DB stuck at 2/3 instances: The cnpg-operator OOMKilled at default 500Mi memory limit during post-restore CNPG reconciliation on a 153-node cluster with 30 Hive + 30 Impala + 2 Trino VWs.; Patch the cnpg-operator deployment memory to 1Gi in the cnpg-system.