Cloudera Docs

September 10, 2026

The Cloudera Data Engineering 1.26.1-H1 service introduces behavioral updates, provides resolutions for identified bugs, and identifies unresolved behaviors with their documented workarounds for Cloudera on cloud.

DEX-22794: Azure v1–v4 capacity growth restrictions

Starting July 31, 2026, Microsoft Azure enforces capacity growth restrictions on v1–v4 Virtual Machine (VM) families, blocking new deployments and scale-out activities with full retirement scheduled by July 31, 2028. This impacts the default infrastructure of Cloudera Data Engineering, specifically affecting the ability to scale Spark compute pools.

As a result, new deployments, capacity expansion requests, and quota increase requests for impacted VM series are not approved. Quotas already approved in existing subscriptions for these VM series are not affected.

Impacted VM series

The following VM series are set to retire by 31 July 2028 and are subject to growth controls:

  • Compute-optimized: F, Fs, Fsv2
  • General-purpose: D, Ds, Dv2, Dsv2, Av2, Amv2, B, Bs
  • Memory-optimized: G, Gs
  • Storage-optimized: Ls, Lsv2

The following VM series are subject to growth controls:

  • General-purpose: Dv3, Dsv3, Dv4, Dsv4, Ddv4, Ddsv4, Dav4, Dasv4
  • Memory-optimized: Ev3, Esv3, Ev4, Esv4, Edv4, Edsv4, Eav4, Easv4

This change affects the following processes:

  • New VM deployments
  • VM scale-out activities requiring additional capacity
  • Quota increase requests
  • Future growth plans on impacted VM series

This change does not affect existing deployments operating within capacity currently allocated. You can continue running your existing workloads without interruption.

If you are planning future growth, expansion, or new deployments, you must evaluate migration to newer-generation VM series that provide improved performance, enhanced security, broader availability, and longer-term platform support.

Recommended VM series

  • General-purpose workloads: Dv5, Dv6, and Dv7 series or variants (Dl/Dd)
  • Memory-intensive workloads: Ev5, Ev6, and Ev7 or variants (Ed) series

Azure workload and database instance type fallback

As part of Microsoft's retirement of Azure v1–v4 Virtual Machine (VM) families, Cloudera Data Engineering migrated AKS node pool and MySQL Flexible Server instance types to v5+ VM SKU equivalents. The Azure workload and database instance type fallback feature provides the fallback mechanisms if a v5 VM SKU is not available in your specific Azure region or subscription.

This feature introduces two tenant-level entitlements:

  • DE_AZURE_LEGACY_WORKLOAD_INSTANCE_TYPE
  • DE_AZURE_LEGACY_DB_INSTANCE_TYPE

Both these entitlements are disabled by default.

These entitlements allow you to maintain legacy instance types in regions where v5 SKU capacity or quotas are currently unavailable.

This feature also provides a pre-flight SKU availability check to validate v5 SKU support before initiating any irreversible upgrade operations, such as the two-phase, delete-then-create migration operations, ensuring cluster stability.

For more information, see Azure workload and database instance type fallback.

Restoring a Cloudera Data Engineering Service with configuration replacement

Cloudera Data Engineering now supports the service-config-replacement option for full configuration replacement during Service restoration. Restoring a Cloudera Data Engineering Service with configuration replacement allows you to overwrite the entire backup configuration, for example to update deprecated instance types, as a complete overwrite rather than a partial merge. This provides greater flexibility and control when restoring Cloudera Data Engineering Services, compared to the previously existing service-property-override option.

For more information, see Restoring a Cloudera Data Engineering Service with configuration replacement.

DEX-22841: Resolved Livy pod thread leak in Cloudera Data Engineering 1.26.1

In Cloudera Data Engineering version 1.26.1, Livy pods could experience native thread exhaustion, leading to job failures and HTTP 500 errors. Livy pods could enter a silent complete outage, meaning that all batch and API requests returned HTTP 500, while the pod remained in Running state, preventing Kubernetes from automatically restarting it.

The cause was native thread exhaustion ("unable to create native thread"). A Livy token-refresh bug recreated the Kubernetes client every 5 minutes without closing the previous instance. In Cloudera Data Engineering 1.26, Fabric8 7.x uses Vert.x (~10 native threads per leaked client), causing threads to grow linearly until reaching the cgroup pids.max (~37K) limit. In Cloudera Data Engineering 1.25 and lower versions, the token-refresh leak was present but remained largely latent because Fabric8 used OkHttp.

This issue is resolved in this release.

Action required: Upgrade to the Cloudera Data Engineering 1.26.1-H1 release containing the Livy fix that removes the redundant Kubernetes client re-creation from the service account token-refresh loop and updates the token on the existing client only.

Workaround: Cloudera recommends upgrading to the Cloudera Data Engineering 1.26.1-H1 Hotfix release. Alternatively, you can mitigate the issue by manually restarting the affected Livy pod in the Virtual Cluster to reset the accumulated native thread count. This action clears the outage but the leak resumes until the patch fix is applied. You must monitor Vert.x thread growth by running the following command:
$> jstack 1 | grep -c "vert.x-eventloop-thread-0"

After running this command, proactively restart the long-lived pods.

ENGESC-33920: Resolved TGT generator race condition in FreeIPARecovery

In this issue, a race condition is now resolved in the TGT generator that caused CLIENT_NOT_FOUND errors in FreeIPARecovery. Logs from the tgtgen pod indicated that the FreeIPARecovery synchronization process was crashing due to an IndexOutOfBoundsException, leading to CLIENT_NOT_FOUND retries.