Installing the operators using the Openshift console
IBM Cloud Pak® for Integration operators are installed and managed using the Operator Lifecycle Manager (OLM) in Red Hat OpenShift. After you install the operators using the Openshift web console, you can use them to deploy instances.
This task must be performed by a cluster administrator. For information about this function, see Roles and Permissions.
Operators extend a Kubernetes cluster by adding and managing additional resource types in the Kubernetes API. This enables the installation and management of software using standard Kubernetes tools. To learn more, see Understanding Operators in the Red Hat OpenShift documentation.
Operators available to install
The following list of operators is available to use in Installing operators, step 4. You can install any combination of operators. Any dependencies are pulled in automatically. Note that not all operators are supported on every environment.
IBM recommends installing the operators for Platform UI, Automation Foundation assets, and Operations Dashboard because they assist in the deployment and management of the other capabilities.
- IBM Cloud Pak for Integration
Provides a dashboard and central services for other Cloud Pak for Integration capabilities. Should be installed for most Cloud Pak for Integration installations.
- IBM Automation foundation assets
Stores, manages, retrieves and searches for integration assets for use within the IBM Cloud Pak for Integration and its capabilities.
- IBM Cloud Pak for Integration Operations Dashboard
Integration tracing across instances to allow troubleshooting and investigation of errors and latency issues.
- IBM API Connect
Provides the API management and Event Endpoint Management capabilities.
Note: You can deploy one instance of each API Connect into a particular namespace. If you want to deploy additional instances, you must deploy them into different namespaces.
- IBM App Connect
Provides application integration capabilities and a means to easily create and export flows that run in an App Connect instance.
- IBM Aspera HSTS
Provides high speed transfer server runtimes.
- IBM DataPower Gateway
Provides gateway runtimes.
- IBM Event Streams
Provides Event Streams runtimes.
- IBM MQ
Provides messaging runtimes.
Supported environments for operators
The following table indicating which operators are supported for a given environment.
| Operator | amd64 (x86_64) | s390x (IBM Z) | ppc64le (IBM Power) |
|---|---|---|---|
| IBM Cloud Pak for Integration | Yes | Yes | Yes |
| IBM Automation foundation assets | Yes | No | No |
| IBM Cloud Pak for Integration Operations Dashboard | Yes | No | No |
| IBM API Connect | Yes | No | No |
| IBM App Connect | Yes | Yes | Yes |
| IBM Aspera HSTS | Yes | Yes | No |
| IBM DataPower Gateway | Yes | No | No |
| IBM Event Streams | Yes | Yes | Yes |
| IBM MQ | Yes | Yes | No |
Guidelines for installing operators
When installing operators, follow these guidelines. For additional details and deployment recommendations, see Structuring your deployment.
default, kube-system, kube-public,openshift-node, openshift-infra, openshift.The term namespace (Kubernetes) as used here means the same thing as project (OpenShift).
Roles and permissions
Typically, a cluster administrator installs the operators, and an automation administrator creates the custom resources (installed instance of the operator) and configures the instances. For more information about these functions, see Roles and permissions.
Installation modes When installing operators, you can choose to install an operator in one of two modes:
All namespaces on the cluster mode runs the operator in the
openshift-operatorsnamespace and can process resources within any namespace on the cluster. This is the default installation mode.A specific namespace on the cluster mode runs the operator in the selected namespace, and the operator only processes resources created in that namespace.
When installing the CP4I operators, only use one of these installation modes. If you combine the two installation modes, Operator Lifecycle Manager (OLM) will not pick up the latest operator version.
Cloud Pak for Integration operators, in general
Operators can be installed at cluster scope (in all namespaces in the cluster) or at namespace scope (in an individual namespace).
If the operators are installed at cluster scope, the entire cluster effectively behaves as one large tenant.
If the operators are installed at namespace scope, each namespace effectively behaves as a different tenant.
Install all operators in the same mode, whether All namespaces on the cluster or A specific namespace on the cluster; do not combine the two modes.
When operators are installed in the All namespaces on the cluster installation mode, each operator must be installed in the openshift-operators namespace.
Installing multiple Cloud Paks
All IBM Cloud Paks installed in a cluster must be installed in the same mode, whether All namespaces on the cluster or A specific namespace on the cluster. If you are installing one of more Cloud Paks with Cloud Pak for Integration, you can't use both mode types together.
IBM Cloud Pak for Integration operator
When Cloud Pak for Integration is installed in the All namespaces on the cluster installation mode, there can be only one Platform UI installed per cluster, and all Cloud Pak instances are owned by that Platform UI.
When Cloud Pak for Integration is installed in A specific namespace on the cluster mode, one Platform UI can be installed in each namespace, and that Platform UI owns only the instances in that namespace.
Foundational services operator
For both installation modes, by default a single instance of IBM Cloud Pak foundational services is installed in the
ibm-common-servicesnamespace if the foundational services operator is not already installed on the cluster. The foundational services operator must be installed in the same mode as the Cloud Pak operators. However, regardless of the mode with which it is installed, by default the foundational services operator will install the Operand Deployment Lifecycle Manager operator in the A specific namespace on the cluster mode in theibm-common-servicesnamespace. While the Operand Deployment Lifecycle Manager operator is installed in this mode, it will extend its permissions to manage foundational services resources in all the namespaces where components of the Cloud Pak are installed. To use a custom namespace for foundational services, see Installing in a custom namespace before installing Cloud Pak for Integration operators.
Approval considerations
If you need the entire Cloud Pak for Integration (or only certain of its components) to use manual approval—and not update automatically—see Restricting automatic updates with an approval strategy.
Installing with the Red Hat OpenShift console
Installing operators
Log into the OpenShift web console with your OpenShift cluster admin credentials.
Make sure the Administrator perspective is selected.

Click Operators > OperatorHub > Integration & Delivery.
Click the tile for the operator you want to install, for example, IBM Cloud Pak for Integration.
Click Install.
In the Install Operator pane:
Select the desired operator channel. For information about available operators and operator channel versions, see Operator channel versions for IBM Cloud Pak for Integration releases.
Select the option either to install in one namespace or in all namespaces in your cluster. See Guidelines for installing operators for more information.
Select an approval strategy. You can select the automatic or manual option. For more information about a manual approval strategy, see Restricting automatic updates with an approval strategy.
Click Install.
Validating installation of an operator
To validate that an operator is installed:
Log into the OpenShift web console.
In the navigation menu, click Operators > Installed Operators.
Select the project in which the operator was installed. If you installed the operator using the All namespaces on the cluster installation mode, the operator pod is located in the
openshift-operatorsproject. Result: Locate your operator in the table and examine thestatuscolumn. When the operator is ready, the status showsSucceeded. You can now proceed to install other Cloud Pak for Integration operators.
Restricting automatic updates with an approval strategy
Operators can be upgraded automatically when new compatible versions are available. However, in some situations this automatic upgrade may be undesirable. You can control whether or not an operator is upgraded automatically by setting an approval strategy, either:
When the operator is installed.
After installation, by modifying its subscription.
The available approval strategies are:
Automatic (default): As new operator versions are made available on the subscription channel, they are installed automatically.
Manual: As new operator versions are made available on the subscription channel, the subscription indicates that there is an update available, but you have to approve the update manually.
To confirm or update the approval strategy for an operator in the OpenShift console:
Expand the Operators section in the navigation bar on the left, and select Installed Operators. Ensure you select the project that contains the operators you intend to confirm or modify.
Click the operator you want to confirm or modify.
Click the Subscription tab.
The Subscription Details at the top of the tab will show you the Channel referenced by the subscription, what the Approval strategy is, and what the Upgrade Status is.
If the Approval strategy is set to Automatic, the Upgrade Status should show Up to date.
If the Approval strategy is set to Manual, the Upgrade Status may show Upgrade available. In thvis case, there may be an available control that allows you to approve the InstallPlan that upgrades the operator.
You can also change the approval strategy by clicking the Subscription tab, then selecting the Approval strategy value. A Change Update Approval Strategy dialog appears and allows you to select a different strategy.
IBM Cloud Pak foundational services approval strategies
The approval strategy for foundational services is managed using the CommonService configuration resource. By default, foundational services is installed in a separate namespace, which means that its approval strategy must be set separately. However, if you choose to install foundational services in the same namespace as your other operators, it inherits the approval strategy selected for your other operators.
For more information, see Approval Strategy.