Installation and upgrade

Use Harbor to do an automated installation or upgrade to the latest Component Pack for HCL Connections. It's best for new and existing customers to read this introduction to better understand how to integrate the Harbor-based Component Pack with the Connections version currently deployed.

Using Component Pack images on Harbor with Connections 7

A single set of Component Pack images on Harbor was introduced in Connections 8.0, and can now be used for 7.0 and earlier releases. That said, the application will vary depending on your current Metrics setup, as the process involves replacing Elasticsearch with OpenSearch as the default backend for Metrics, OrientMe, and Search.

Installation and upgrade general approach: You will notice that we are going to use the same commands to install or upgrade Component Pack. For an upgrade from Component Pack 7, the baseline we use includes Kubernetes-based components, like Elasticsearch 7-based Metrics. Refer to the HCL Connections System Requirements for the Kubernetes versions and platforms tested with the Component Pack.; It is recommended to review all the steps first and perform a system backup before doing the installation/upgrade.

For new deployments: Follow the installation steps outlined in Steps to install or upgrade from Component Pack 7 to the latest using Harbor to deploy the images using helm charts hosted on Harbor.

For existing deployments using Elasticsearch

Elasticsearch indices will need to migrate to OpenSearch. Guidance depends on which Connections version you currently have deployed:

For Connections 7.0 with Component Pack 7 images, follow the upgrade steps outlined in Steps to install or upgrade from Component Pack 7 to the latest using Harbor. The 7.0 version carries Elasticsearch 7, so during the upgrade you will migrate the Elasticsearch indices to OpenSearch using cp_migrate_data_from_es7_to_opensearch.html.
For Connections 6.5 CR1 and earlier, there is no direct upgrade path to the Harbor-based Component Pack. You first need to upgrade to Component Pack 7 using the zip deployment in cp_install_services_tasks_helm2.html, and then migrate to OpenSearch in the following order:
- First, from Elasticsearch 5.5.1 to Elasticsearch 7. Refer to cp_install_services_tasks_helm2.html#cp_install_services_tasks__section_msj_vsy_gpb.
- Then, migrate to OpenSearch using Migrating data from Elasticsearch 7 to OpenSearch.

For existing deployments using Cognos: Metrics events will first need to migrate to Elasticsearch in a supported manner, and then move to OpenSearch.

Ansible automation option provided by HCL

Starting with version 7, HCL Software is providing Ansible automation tested in house as a preferred way of setting up Component Pack and its dependencies. If you don't have any experience with managing Kubernetes and its dependencies, or you simply want to see what the automation experience looks like, you can use the Ansible package to create your first single-node or distributed Component Pack cluster. This automation will, from Component Pack point of view, set up Kubernetes, kubectl, Helm, and execute all the steps needed to provide an out-of-the-box set up of Component Pack.

For more specifics on how to use the automation, see HCL's open-source GitHub for the documents Quickstart for setting up HCL Connections and Component Pack using Ansible automation and HCL Connections and Component Pack automation scripts.

Replacing Component Pack

Component Pack runs on top of the Kubernetes, and for important data uses persistent storage. That storage lives, in a supported way, on NFS or Amazon EFS, if you are running stuff on Amazon, so your data should be already safe.

It is possible to simply recreate Kubernetes cluster and reinstall Component Pack and simply continue using it with the data as where you left it before you did it. Removing Component Pack and/or Kubernetes doesn't affect your data at all. Just don't remove the data.

In theory, you can have multiple Kubernetes clusters with multiple installations of Component Pack, and on Connections side, by manipulating httpd.conf in your IHS, you can decide to which one to point to. Just don't try to have multiple clusters using same PVs at the same time for the sake of data consistency and reliability.