Cloudera Platform Support Policy
The Cloudera Platform Support Policy provides customers, partners, users, and Cloudera internal stakeholders with clear guidance on platforms we support and our policies for adding, deprecating, and dropping support.
In this document, we cover the support policies for operating systems (OSs), Java Development Kits (JDKs), databases (DB), cloud platforms, and file formats.
Definitions
In this document, supported platforms refer to the OSs, JDKs, databases, components, and file formats with which we support deploying Cloudera on premises, Cloudera on cloud, and Cloudera Enterprise.
In this document, Cloudera on premises refers to the Cloudera’s distribution including Apache Hadoop, and refers to all the projects in Cloudera on premises and all of its components including Cloudera Manager).
A deprecated feature, component, or functionality is one that Cloudera is planning to remove or discontinue support for in a future release. Deprecated items are supported by Cloudera until they are removed. However, future use is discouraged by Cloudera as enablement by default or documentation updates may not be supported during the deprecation period. The deprecation notice gives customers time to plan for the removal or cessation of support. A list of deprecated can be found in the Deprecated Notices section of the product documentation (as an example, Cloudera 7.3.1 deprecation notices can be found here: Deprecation Notices In Cloudera Runtime 7.3.1).
A removed feature, component, platform, or functionality has already been removed from a major release of the product and is no longer supported within that major version going forward, but will remain supported in earlier major releases until those earlier versions reach end of life. As an example, Data Analytics Studio (DAS) has been deprecated and is no longer available in Cloudera Base on premises starting with 7.1.9. However, DAS will continue to be supported in Cloudera Base on premises 7.1.7 release until it has reached the End of Life Stage (EOS) based on the Cloudera Support Lifecycle Policy policy. Please note that if third party software (platforms, DBs, etc.) has end of life, an independent upgrade would be required.
Prior to 7.3.1, a major Cloudera platform release refers to Cloudera Enterprise 7, Cloudera Enterprise 6, and so on. A minor Cloudera release refers to Cloudera Enterprise 7.1, Cloudera Enterprise 6.2, and so on.
At the launch of Cloudera 7.3.1.0, the first numeral indicates the base version, the second numeral represents the major version number, the third numeral represents the minor version number and the last numeral represents either a cumulative hotfix (CHF) or a service pack (SP). A CHF is an update that contains all previous hotfixes to date and includes critical bug fixes, and security patches addressing a CVE (Common Vulnerabilities and Exposures) and other security fixes in Cloudera products. However, an SP is a tested set of all CHF, hotfixes, security and CVE updates, critical bug fixes, minor platform certifications and updates. Performance fixes, regression bug fixes and non-customer visible fixes or enhancements will be included in a service pack.
Take a look at the examples below to understand these releases:
- Cloudera 7.3.1.0 is the first minor release of the major release of 7.3.
- Cloudera 7.3.2.0 is the second minor release of the major release of 7.3.
- Cloudera 7.3.1.200 is the second CHF for a minor release of 7.3.1
To provide a sustainable and clear support model, supported Operating System (OS) releases are divided into TIERs. The TIERs reflect the uptake among our customers and the market in general. There are currently three TIERs:
TIER 1: RHEL, OEL, and CentOS
A ‘major’ RHEL release refers to versions such as RHEL 8 and RHEL 9.
A ‘minor’ RHEL release refers to updates within a major version, such as RHEL 8.7, RHEL 9.2, and so on.
TIER 2: SuSE and Ubuntu (LTS only)
TIER 3: Other Linux (Scientific), and RHEL and CentOS in SELinux configured in ‘enforcing’ mode
A ‘major’ JDK release refers to JDK 1.7, JDK 1.8 and so on.
A ‘minor’ JDK release refers to JDK 1.7_11,JDK 1.8_40, and so on.
We define a ‘major’ database release as the release lines on which new features are added, which varies by database vendor. For example,
Oracle DB major releases are defined on the major release number, such as 23 or 21. For example: Oracle Database 18c; Oracle Database 12c. Starting with Oracle Database 18c, the first numeral indicates the initial year in which an Oracle Database version is released. For example: 2018 is the initial release year for Oracle Database 18c (18.0.0.0.0)
MySQL DB major releases are defined on the minor release number, such as 8.0, or 8.4, etc.
Postgres DB major releases before 10.x are defined on the minor release number, such as 9.1 or 9.2. For 10.x and later, major releases are defined by the major release number (e.g. ‘10’)
A minor database release follows the “dot” or “double dot” release of the major release.
Component and Subcomponent Support
Components and subcomponents are added to Cloudera Enterprise based on market demand and component readiness. Support for a component can be dropped only in a Cloudera major release. A deprecation announcement will be made at least six months before support is dropped in documentation and/or direct communication to customers. Support for experimental and ‘technical preview’ features can be dropped at any time.
OS Platform Support
Information on OS releases supported for a Cloudera release can be found in the supported platforms documentation.
When do we add support for a new major or minor OS release?
We add support for a new major or minor OS release when there is significant demand in the market and among our customers.
Support for a new major or minor OS release can be added to major, minor or SPs of Cloudera releases.
We only add support for a new OS release if there are no known security vulnerabilities or other significant issues that could impact production deployment discovered in our testing. If issues are known or discovered, we will wait to add support until patches addressing the issue are provided by the OS vendor.
For minor OS releases, supporting the latest long-term releases is preferred. As an example, in 7.3.1, we support RHEL 8.10 and RHEL 8.8 while RHEL 8.9 is unsupported.
How many concurrent OS releases do we support?
For every Cloudera major or minor release, we will support at least two major OS versions and at least 2 minor versions from each of the supported major or minor versions, for all supported OS distributions.
When do we drop support for major or minor OS releases?
Support for major or minor OS releases will be dropped after an OS version enters the end of life (EOL) period as specified by the OS vendor, and/or at the end of a Cloudera major release line. If you are on an extended OS support contract with the vendor, and want to be supported by Cloudera on it, you need to discuss a separate support plan with us. Please contact your account team to have such a discussion to assure you are supported in the best way.
In cases where a major or minor OS release has not reached the end of life (EOL) period as per the OS vendor, we may still drop the support because, as mentioned above, we will only support the latest two versions. As an example, in 7.3.1.0, RHEL 8.10 and RHEL 8.8 are supported while RHEL 8.6 is unsupported even though, based on RHEL’s lifecycle policy, it has not reached EOL timelines.
For a supported major or minor OS release, there will be a deprecation announcement at least six months before support is dropped.
If a security vulnerability or significant production issue is discovered in any major or minor version of an OS, the customer should consider moving to another OS version that remediates the issues.
Can customers have multiple OS releases deployed for the same Cloudera cluster?
All CDP hosts that make up a logical cluster must run on the same major OS release to be eligible for Cloudera Support. Cloudera will provide support to customers during an OS upgrade on underlying nodes, regardless of whether the OS versions are from the same or different OS vendors (e.g., upgrading from RHEL 8.8 to RHEL 9.1 or upgrading from CentOS 7.9 to RHEL 9.1). However, in a mixed OS configuration, Cloudera will not support minor upgrades or patches (SP or CHF).
A mixed OS configuration refers to a temporary state during an upgrade or migration where different nodes in the cluster are running different OS versions (e.g., some nodes on RHEL 8 and others on RHEL 9). To engage support for cases unrelated to an OS upgrade, customers must complete the OS upgrade on all nodes.
During the OS upgrade process, no patches will be provided, and Cloudera will only support a mixed OS configuration for the duration necessary to complete the upgrade. It is not recommended to use a mixed OS environment for an extended period. Therefore, customers are advised to check the support matrix for CM and OS runtime version compatibility before performing an upgrade.
The risk of issues caused by running different minor OS releases is considered lower than the risk of running different major OS releases. Cloudera recommends running the same minor release cross-cluster because it simplifies issue tracking and supportability.
While we acknowledge this process takes time we expect it will finish at some point and it is not an open-ended commitment to support mixed OSes as the 'normal' state of the cluster. Customers need to advise their Cloudera Account team of the planned start and finish date of any planned OS migration or upgrade. Please note that mixed OS environments can lead to issues that may hinder the ability to patch or resolve problems effectively. Therefore, our recommendation is to expedite the completion of the OS migration or OS upgrade to mitigate the issue.
When do we add or drop support for a new OS vendor/distribution?
We add or drop support for particular OS distribution when there is significant demand in the market and among our customers.
The policy is the same as for adding or dropping support for a new major OS release.
JAVA Platform Support
Information on supported JDK releases for a Cloudera release can be found in the supported platforms documentation.
When do we add support for new major JDK releases?
We add support for deploying a Cloudera release with a new major JDK release when it is supported on the TIER 1 and TIER 2 supported OS releases, and when there is significant demand in the market and among our customers. We may also choose not to add support if there are known security vulnerabilities without patches available from the JDK vendor.
When do we add support for new major Java releases?
Adding support for new major Java language spec releases follows the support policy of adding support for new major JDK releases; that is, when there is significant demand in the market and among our customers to utilize new Java spec functionality.
If custom applications on the Cloudera platform depend on new Java specification functionality or on JDK internal optimizations, the custom application needs to be compiled with the JDK release supporting the newer functionality, and the Cloudera platform should also be deployed with the same JDK version.
Once the Cloudera platform supports the new major JDK release, running applications compiled with the same new major JDK releases are supported.
Any exceptions of new spec functionality supported will be listed in the Release Notes under Known Issues.
When do we drop support for JDK major releases?
We may drop support for major JDK releases at any point after the JDK major release enters the end of life period as specified by the JDK vendor.
An announcement about deprecation will be delivered at least six months prior to the end of support for that major version. Deprecation information is available in Cloudera documentation of supported platforms.
When do we add support for minor JDK releases?
For every minor Cloudera release, we will evaluate adding support for the latest available minor JDK release (for non-deprecated JDK releases). There is no commitment to add support for minor releases as they become available, but the intent is to add support for selected and stable newer minor JDK releases with the latest security fixes as they become supported on supported OS releases and pass internal testing.
The supported minor JDK releases will be listed in Cloudera release documentation and supported platforms documentation.
When do we drop support for JDK minor release versions?
A supported minor JDK release will remain supported from the time of support addition forward until the JDK version enters the end of life period as specified by the JDK vendor, or later. We may continue to support unsupported versions of JDK if we conclude that such migration may be too disruptive, complex and costly for our customers. As an example, JDK 8 is supported on 7.3.1 even though JDK 8 has officially reached the end of support.
We can suspend support for a JDK minor release at any time if a security vulnerability or significant production issue is discovered in the JDK release. We will support a subsequent minor release after patches addressing the issue are provided by the JDK vendor.
What about security patches?
We may choose to certify new JDK minor versions whenever a JDK security patch that affects Cloudera Enterprise is released by the JDK vendor. This certification can be independent of Cloudera releases if no changes are required for Cloudera to support the new minor version, or can be done in conjunction with a new Cloudera maintenance release or minor release.
Can customers have different JDK releases deployed for the same Cloudera cluster?
No. Running CDP nodes within the same cluster on different JDK releases is not supported. Cloudera products are certified and tested with specific JDK versions. Mixing JDK releases may result in inconsistencies, unexpected behaviors, or failures in services. Therefore, the JDK release across a cluster needs to match both the major and minor version.
As part of the upgrade process, verifying and upgrading the JDK is a critical pre-upgrade step to ensure compatibility, security, and performance. Using an unsupported JDK version can lead to runtime errors, service disruptions, or upgrade failures for CDP components including Cloudera Manager. Therefore, we recommend upgrading the JDK version on all CDP clusters prior to upgrading the Cloudera Manager requiring the new version, but Cloudera Manager assists in (and enforces) performing the JDK upgrade during the Cloudera Manager upgrade process.
When does Cloudera Manager change the preferred JDK for installation and deployment?
Given the frequent Java updates and the changes in the overall Java roadmap, Cloudera can change the preferred JDK major version in a minor Cloudera release after thorough testing and if there is a compelling reason to do so (i.e. important security fixes or a JDK update reaching EoL). Cloudera can also change the preferred JDK minor version in a maintenance release if an important security issue(s) has been identified, patches and tested prior to the release and Cloudera feels it urgent to update environments to consume the security fix(es).
When do we add or remove support for a JDK vendor’s distribution?
We add or remove support for a new JDK distribution based on demand in the market and among our customers.
The policy is the same as for adding or removing support for a new major JDK release.
DB Platform Support
Information on supported DB releases for a Cloudera release can be found in the supported platforms documentation. In this context, DB support refers to the DBs we support for the components in CDP that depend on a DB installed, such as Cloudera Manager, Hive, Hue, and so on.
When do we add a major DB release?
We add support for a major DB release when there is significant demand in the market and among our customers, and only when the release is supported by the Cloudera supported TIER 1 and TIER 2 OS releases.
We only add support for a new major DB release if there are no known security vulnerabilities or other significant production issues. If there are known issues, we will wait to add support until patches addressing the issue have been provided by the DB vendor.
When do we drop support for a major DB version?
We will only drop support for major DB releases when the major DB version enters the end of life period as specified by the DB vendor.
Prior to dropping support of a major DB release, we support it in a deprecated state for a Cloudera release lifecycle. An announcement about deprecation will be delivered at the time of deprecation. Deprecation information is also in Cloudera release documentation and supported platform documentation.
We cannot drop support for a major DB version if it is the only remaining supported version for a Cloudera-supported OS.
How many concurrent DB releases do we support?
For every Cloudera major or minor release, we will support at least two major DB versions and at least 2 minor versions from each of the supported major or minor versions, for all supported OS distributions. As an example, in 7.3.1, we support Postgres 15 and 16, while Postgres 14 is not certified even though it has not reached Postgres’s EOL timeline.
When do we add support for a minor DB release?
For every minor Cloudera release, we will evaluate adding support for the latest available minor DB release (for non-deprecated DB releases). There is no commitment to add support for minor releases as they become available, but the intent is to add support for selected and stable newer minor DB releases, as they become supported on supported OS releases and pass internal testing.
The supported minor DB releases will be listed in Cloudera release documentation and supported platforms documentation. Also note that at the launch of CHFs or SPs, we may not re-certify what was originally certified in the major and minor releases.
NOTE: In general, there is very little risk of issues between minor releases of open-source databases. That is, for a supported major Postgres or MySQL version, it is expected that all minor releases, such as 16.x or 8.0.x, would work as intended.
Can customers have different DB releases or DBs from different vendors deployed for the same Cloudera cluster?
We strongly recommend homogeneous DB deployment across the cluster, for simplicity and supportability.
Note: Deploying different vendors should not cause issues. However, deploying different versions of the same vendor DB, might cause complications because in some cases, different versions of the JDBC driver would be loaded in the same process space. If this deployment method is necessary, the drivers need to be backwards compatible.
The policy is the same as for adding a new major DB release.
File Format Support
Information on file formats supported for a Cloudera release can be found in the supported platforms documentation.
When do we add support for a new file format?
If there is significant demand in the market and among our customers, or if innovations require new file formats, we will add support for new file formats to our product roadmap.
When do we drop support for a new file format?
There is currently no foreseeable need or reason to drop support for a file format. We have not dropped support for any file format.
In the very unlikely event of dropping support for a file format, we would do so only in a major Cloudera release. We would announce a drop of support at least 12 months ahead of time in a separate deprecation announcement. Tools and guidelines will be provided for migration and conversion as and if needed.
When do we upgrade file format versions?
We do on occasion move to newer versions of file formats as they become available, such as with Avro and Parquet.
We do not move forward with file format upgrades in minor releases; we only allow minimal bug fixes.
All upgrades of file formats must be backwards compatible, even in major Cloudera releases.