Technical service bulletins
Learn about the technical service bulletins (TSBs) with the Cloudera Data Engineering service on cloud, the impact or changes to the functionality, and the workaround.
- TSB 2025-837: Cloudera Data Engineering Airflow errors leading to hung jobs and SLA misses
- Issues in Cloudera Data Engineering on cloud releases that have been upgraded to Airflow version 2.9 may lead to Directed Acyclic Graph (DAG) runs hanging and SLA misses. Cloudera has released a patch to address these issues, which needs to be manually applied in affected environments.
- Knowledge article
- For the latest update on this issue see the corresponding Knowledge Base article: TSB 2025-837: Cloudera Data Engineering Airflow errors leading to hung jobs and SLA misses
- TSB 2025-797: Using Spark vectorized reads on Iceberg tables with Parquet files could result in malformed data
- Due to an upstream Apache Iceberg issue, in specific situations, customers executing Spark vectorized reads on Iceberg tables with Parquet files may encounter malformed output and data incorrectness.
- TSB 2024-768: CDE graphs appear empty due to internal Prometheus OOM errors
- When using a CDE service that underwent an in-place upgrade from CDE 1.19.x to CDE 1.20.3/1.21.0), charts on the CDE administration page and Grafana dashboard might not show data. This issue occurs when the CDE internal Prometheus server encounters out of memory (OOM) errors, which is caused by the pre-upgrade Prometheus configurations not being carried over during upgrade. The upgrade path from CDE 1.20.3 to CDE 1.21.0 is not affected.
- Knowledge article
- For the latest update on this issue see the corresponding Knowledge Base article: TSB 2024-768: CDE Graphs appear empty due to internal Prometheus OOM errors
- TSB 2024-727: Upgrade YuniKorn in CDE deployments
- Apache YuniKorn (YuniKorn) 1.3.0, deployed as part of Cloudera Data Engineering (CDE) versions 1.19.3 and 1.19.4, can stop scheduling pods that cause workloads to get stuck even when cluster resources are available. Issues were found in the YuniKorn 1.3.0 release that get triggered by Spark jobs using gang scheduling in combination with preemption. These issues lead to accounting leaks and can result in YuniKorn stopping the scheduling of all pods in the cluster.
- Knowledge article
- For the latest update on this issue see the corresponding Knowledge Base article: TSB 2024-727: Upgrade YuniKorn in CDE deployments
- TSB 2023-658: Within CDP Public Cloud environments, CDE CLI access key authentication does not work for a[0-9].*, b[1-9].*, c[1-9].* workload domains
- Using the Cloudera Data Engineering (CDE) command line interface (CLI) with access key-based authentication may cause authentication errors within CDP Public Cloud environments. The cause of the issue is the discrepancy in the way JSON Web Token (JWT) audience claim value is obtained between different components within the Cloudera Data Platform (CDP) Public Cloud.
- Knowledge article
- For the latest update on this issue see the corresponding Knowledge Base article: TSB 2023-658: Within CDP Public Cloud environments, CDE CLI access key authentication does not work for a[0-9].*, b[1-9].*, c[1-9].* workload domains
- TSB 2022-588: Kubeconfig and new version of aws-iam-authenticator
- Regenerate Kubeconfig and in conjunction use a newer version of aws-iam-authenticator on AWS. Kubeconfig in Cloudera Data Platform (CDP) Public Cloud Data Services needs to be regenerated because the Kubeconfig generated before June 15, 2022 uses an old APIVersion (client.authentication.k8s.io/v1alpha1) which is no longer supported. This causes compatibility issues with aws-iam-authenticator starting from v0.5.7. To be able to use the new aws-iam-authenticator, the Kubeconfig needs to be regenerated.
- Knowledge article
- For the latest update on this issue see the corresponding Knowledge Base article: TSB 2022-588: Kubeconfig and new version of aws-iam-authenticator
- TSB 2022-587: CDE 1.14 and above using Kubernetes 1.21 will fail service account token renewal after 90 days
- Cloudera Data Engineering (CDE) on Amazon Web Services (AWS) running version CDE 1.14
and above using Kubernetes 1.21 will observe failed jobs after 90 days of service uptime
[1].
[1] “For Amazon Elastic Kubernetes Service (EKS) clusters, the extended expiry period is 90 days. Your Amazon EKS cluster's Kubernetes API server rejects requests with tokens older than 90 days.”
- Knowledge article
- For the latest update on this issue see the corresponding Knowledge Base article: TSB 2022-587: CDE 1.14 and above using Kubernetes 1.21 will fail service account token renewal after 90 days
