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 refers to the OSs, JDKs, databases, components, and file formats with which we support deploying Cloudera Enterprise.
In this document, CDH refers to the Cloudera’s distribution including Apache Hadoop, and refers to all the projects in Cloudera Enterprise (CDH and all of its components, Cloudera Manager, Cloudera Navigator, Cloudera Director).
Cloudera Manager includes Cloudera Navigator and backup and disaster recovery (BDR) in this context.
A deprecated feature, component, platform, or functionality is one that Cloudera is planning to remove or discontinue support for in a future release. Cloudera supports items that are deprecated until they are removed but discourages future use and may not enable or select them by default and may choose to stop documenting their usage during the deprecation period. The deprecation notice gives customers time to plan for the removal or cessation of support. A list of deprecated items can be found in the Deprecated Items section of the product documentation.
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. If Cloudera announces the removal of a component in Cloudera Enterprise 6, that component will continue to be supported in Cloudera Enterprise 5 minor releases until those minor releases reach the End of Life stage. Using Mahout as an example, the following will happen: Mahout is removed from Cloudera Enterprise 6 and will not be present in any minor release of the Cloudera Enterprise 6 lifecycle. However, Mahout will continue to be supported in specific Cloudera Enterprise 5 minor releases according to the Cloudera Enterprise End of Life policy.
A major Cloudera release refers to Cloudera Enterprise 5, Cloudera Enterprise 6, and so on. The Cloudera major release life cycle refers to Cloudera Enterprise 4.x, Cloudera Enterprise 5.x, Cloudera Enterprise 6.x, and so on.
A minor Cloudera release refers to Cloudera Enterprise 5.1, Cloudera Enterprise 5.2, Cloudera Enterprise 6.2, and so on.
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
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 releases 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 10_0 or 11_0.
MySQL DB major releases are defined on the minor release number, such as 5.1,5.5, or 5.6
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.
When do we drop support for a component?
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 Enterprise release can be found in the supported platforms documentation.
When do we add support for new major OS release?
We add support for a new major OS release when there is significant demand in the market and among our customers.
Support for a new major OS release can be added to major or minor 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.
How many concurrent major 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 supporter major versions, for all supported OS distributions.
When do we drop support for major OS releases?
Support for major OS releases will be dropped after an OS version enters the end of life (EOL) period as specified by the 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.
For a supported major OS release, there will be a deprecation announcement at least six months before support is dropped.
We can suspend support for a major OS release at any time if a security vulnerability or significant production issue is discovered in the OS. We will resume support for that OS release after patches addressing the issue are provided by the OS vendor.
When do we add support for new minor OS releases?
TIER 1 Operating Systems: Cloudera proactively certifies new minor OS releases typically within a few weeks after OS release availability, using the five most current Cloudera Enterprise software releases available. Additionally, when a new major Cloudera Enterprise release is released, Cloudera will announce the minimum OS major and minor versions supported for such a release.
The only exception are technical issues identified in Cloudera source code that are needed to pass OS certification. These issues will be documented in the release notes as known issues and addressed in a future release.
TIER 2 and TIER 3 Operating Systems: Cloudera does not certify new minor OS releases automatically for Tier 2 and Tier 3 operating systems. New minor OS releases, for Tier 2, are evaluated on a case by case basis and only certified when there is significant market demand amongst Cloudera customers.
When do we drop support for minor OS releases?
A supported minor OS release can be dropped when it enters the end of life period as specified by the OS vendor, or at the end of a Cloudera major release line.
We can suspend support for a minor OS release at any time if a security vulnerability or significant production issue is discovered in the OS release. We will resume support for that OS release after patches addressing the issue are provided by the OS vendor.
Can customers have multiple OS releases deployed for the same Cloudera cluster?
All CDH hosts that make up a logical cluster need to run on the same major OS release to be covered by Cloudera Support.
CM needs to run on the same OS release as one of the CDH clusters it manages, to be covered by Cloudera Support.
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. However there are a few exceptions:
We will support clusters with mixed Operating System versions from the same OS vendor if the customer is in the process of upgrading the OS.
We will support clusters that have Operating Systems from different vendors if the customer is in the process of migrating from one OS vendor to another. Cloudera manager parcels and the agent upgrade workflow support multiple OS versions.
Nodes used solely to run Cloudera Data Science Workbench and other gateway nodes can be running a different version of the same OS from the version running other cluster services.
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. During this time should issues in the CDH product arise that are caused by the mixed OS environment we may be unable to patch or fix issues caused by the OS mismatch. 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 release 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 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 resume support for 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 CDH nodes within the same cluster on different JDK releases is not supported. The JDK release across a cluster needs to match the patch level and major version.
Additionally, Cloudera Manager must run on the same JDK release as one of all of the CDH clusters it manages. We recommend upgrading the JDK version on all CDH 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 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 CDH that depend on a DB installed, such as Cloudera Manager, Hive, Hue, and so on. We do not refer to DB support as external data sources to the Data Hub.
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.
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.
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 8.4.x or 5.5.x, would work is 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.
When do we add support for a new DB vendor?
If there is significant demand in the market and among our customers, we will add support for a new DB.
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 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.