Upgrade Notes (Release 7.0.0)

Upgrading to Release 7.0.0 (High-Level Steps)

Depending on your current Data Fabric release, upgrading to release 7.0.0 can require different combinations of procedures. Upgrading to release 7.0.0 can require an OS upgrade and requires a JDK upgrade if your cluster is running release 6.1.x or earlier. The following table summarizes the high-level upgrade steps. Before beginning the upgrade, be sure to review the upgrade considerations later on this page.

If your cluster is running release	Use these steps to upgrade to release 7.0.0	See for more information
6.2.0	Upgrade your EEP to a "bridging EEP" such as EEP 7.1.2 or 8.1.0. Upgrade your OS to an OS that is supported by release 7.0.0. For example: RHEL 8.2 or 8.4* or 8.6* SLES 15 SP2 or 15 SP3 Ubuntu 18.04 You can skip the OS upgrade if the Operating System Support Matrix shows that your current OS is supported on release 7.0.0. Upgrade from release 6.2.0 to 7.0.0 using one of the upgrade workflows.	Upgrading Ecosystem Packs Java Upgrading Your Linux Operating System Operating System Support Matrix Upgrade Workflows (Release 6.x to 7.0.0)
6.1.0 or 6.1.1	Upgrade your OS to an OS that is supported by release 6.2.0 and release 7.0.0. For example: RHEL 8.2 or 8.4* or 8.6* Ubuntu 18.04 SLES 15 SP3 You can skip the OS upgrade if the Operating System Support Matrix shows that your current OS is supported on release 6.2.0 and release 7.0.0. Install Java JDK 11 or the equivalent. Upgrade from release 6.1.x to 7.0.0 using one of the upgrade workflows. Upgrade your EEP components after upgrading core, as indicated in the workflow.

*Release 7.0.0 can be used with RHEL 8.1 and 8.3, but Red Hat recommends upgrading from RHEL 7.x to even-numbered RHEL releases. For more information, see this article.

**See the upgrade consideration for Ubuntu later on this page.

***Supported only for EEP 8.1.0.

Professional Support for Upgrades

Upgrading can be time-consuming and complicated. Consider engaging HPE professional support services to assist in planning and executing your upgrade. For more information, contact your support representative. See Contact HPE.

Online Versus Offline Upgrades

You can upgrade core software using a "rolling upgrade" process that transitions the cluster to release 7.0.0 one node at a time. Except for the node being upgraded, the cluster remains online during this process.

IMPORTANT You cannot upgrade EEP components using an online or "rolling upgrade" process. EEP upgrades are always an offline process.

If you are upgrading from release 6.2.0 to release 7.0.0, you can upgrade your EEP to a "bridging EEP" to isolate any issues before performing the core upgrade. A bridging EEP is an EEP that is supported on both the release you are currently running and the release to which you want to upgrade. EEPs 7.1.2 and 8.1.0 are bridging EEPs. EEP Support and Lifecycle Status shows the EEPs that are supported for each core version.

If you are upgrading from release 6.1.x to release 7.0.0, no bridging EEP is available. However, you can upgrade core directly to release 7.0.0. You do not need to upgrade to release 6.2.0 first.

CAUTION Before upgrading directly from release 6.1.x to 7.0.0, be sure to review the COMSECURE-615 known issue in Known Issues at Release (Release 7.0.0).

Release 7.0.0 Requires EEP 8.1.0 or EEP 7.1.2

Release 7.0.0 requires EEP 8.1.0 or later. However, you can also use EEP 7.1.2 with release 7.0.0. For more information about EEPs, see What's New in EEP 8.1.0 and EEP 7.1.2 Reference Information.

32-GB Minimum Memory for Production Nodes

Minimum memory requirements for production nodes have changed. Production nodes require at least 32 GB of memory per node. For more information, see Memory and Disk Space.

Upgrades to CentOS Not Supported

Release 7.0.0 is not supported for use with CentOS. CentOS Linux 8 has reached End of Life (EOL) status. For more information, see this page.

Upgrades From Non-FIPS Mode to FIPS Mode Not Supported

Only new installations of FIPS clusters are currently supported. You cannot use the Installer or manual steps to upgrade a non-FIPS-compliant cluster to a FIPS-compliant cluster.

Upgrading from Ubuntu 16.0.4 to Release 7.0.0

Upgrading from Ubuntu 16.04 to release 7.0.0 requires a slightly different set of upgrade steps because:

Release 7.0.0 cannot be used with Ubuntu 16.04.
EEP 8.0.0 and later are not supported on Ubuntu 16.04.
Installer 1.17.0.0 and later cannot be used with Ubuntu 16.04.

To perform the upgrade:

Upgrade your OS to Ubuntu 18.04. See Upgrading Your Linux Operating System.
If you are using the Installer, update it to the latest version. See Updating the Installer.
Upgrade to EEP 8.1.0 and release 7.0.0 using the preceding high-level steps.

For a list of the operating systems on which you can install different versions of core, see Operating System Support Matrix.

SLES Upgrades Require the Option to Address a Package Vendor Change

In release 7.0.0, the vendor for core packages changed to "Hewlett Packard Enterprise." In earlier releases, the vendor was "MapR Technologies Inc." This change can affect SLES upgrades.

For a manual upgrade from release 6.2.0 to release 7.0.0 on SLES SP2, the zypper update command can fail because of a vendor mismatch in the RPM provider. Zypper returns an error saying that the vendor for the package you are trying to upgrade has changed.

To avoid this error, add the --allow-vendor-change option to the zypper update command. For an example, see Offline and Manual Upgrade Procedure.

Upgrades and Clear-Text Passwords

Upgrades from releases 6.1.x or 6.2.0 to release 7.0.0 leave the clear-text passwords in the ssl-server.xml and ssl-client.xml configuration files unchanged. However, after applications are tested and the upgrade is known to be successful, the cluster administrator can remove the clear-text passwords. For more information, see Removing Clear-Text Passwords After Upgrade.

`configure.sh -R` Behavior in Release 7.0.0

The following changes to configure.sh -R behavior occur when you upgrade from a release earlier than release 7.0.0 to release 7.0.0 or later:

mrhsm configuration files are automatically upgraded to support the new PKCS#11 file-store feature.
If the legacy cldb.key and/or dare.master.key exist in the ${MAPR_HOME}/conf/ directory, software automatically enables the PKCS#11 file store and imports these keys into the ${MAPR_HOME}/conf/tokens directory. Since, these legacy keys are no longer needed, it is a best practice to move them to a safe place to increase security. It is optional to copy over the ${MAPR_HOME}/conf/tokens to other nodes, as every occurrence imports the same keys during an upgrade:
- By default, data-fabric software initializes mrhsm using the same default hsm label and so pin as when you do a new release 7.0.0 installation if mrhsm has not already been initialized. You can change these default values by specifying -hsmlabel <label> -hsmsopin <so-pin> options.
- If mrhsm has already been initialized to use KMIP, you need to specify the -hsmsopin <so-pin> option to enable the file store correctly.

Hadoop and YARN Are Provided as Ecosystem Components

Beginning with core 6.2.0 and EEP 7.0.0, Hadoop and YARN services are no longer included in the repository for core packages. They are provided as ecosystem components in the EEP repository. If you are upgrading and need Hadoop and YARN services, you must install the packages as ecosystem components after upgrading. For more information, see Installing Hadoop and YARN.

Regenerating the mapruserticket File

Changes to the CanImpersonate parameter of the mapruserticket file in release 6.1.0 require users who upgrade manually to regenerate the file before restarting Warden. See Step 1: Restart and Check Cluster Services.

The file needs to be regenerated to ensure that impersonation works correctly for non-mapr users. Prior to release 6.1.0, all mapruserticket files were generated with CanImpersonate = false. Release 6.1.0 and later enforce the CanImpersonate parameter and set the parameter to true for freshly installed clusters. For upgraded clusters, if CanImpersonate is not set to true, some services will not be able to impersonate.