Deploying foundational services instance by using the OpenShift command-line interface (CLI)

Edit online

The following procedure guides you through the deployment of the foundational services instance by using the OpenShift command-line interface (CLI).

Procedure

Edit online
  1. Creating the OperandRequest instance
  2. Verifying the installation
  3. Accessing the foundational services console
  4. Accessing Business Teams Service console
  5. Enabling or disabling foundational services after installation

In your OpenShift console, go to foundational-services namespace > Operators > Installed Operators page, you see the IBM Cloud Pak foundational services operator and the Operand Deployment Lifecycle Manager operator.

The Operand Deployment Lifecycle Manager provides the following APIs:

  • OperandConfig includes all services that are available for you to install in your cluster.
  • OperandRegistry is for internal management of the services.
  • OperandRequest is the API where you add the services that you want to install in your cluster.
  • OperandBindInfo is the API that manages secrets and configmaps between namespaces.
  • OperatorConfig is for internal management of the operators.
Note: When the sourceName is not explicitly specified for an operator in OperandRegistry, the Operand Deployment Lifecycle Manager (ODLM) looks for the available CatalogSource of an operator when creating the subscription. ODLM chooses the CatalogSource according to the following criteria :
  1. Excluding the following community CatalogSources: certified-operators, community-operators, redhat-marketplace, redhat-operators, ibm-cp-automation-foundation-catalog, operatorhubio-catalog.
  2. CatalogSources in the operator namespace (private CatalogSource) have a higher priority than CatalogSources in other namespaces (global CatalogSource).
  3. CatalogSources with higher .spec.priority values are picked up first.
  4. If both CatalogSources are in the same namespace and have the same priority, the CatalogSource that is used to install ODLM and is available to install the operator is chosen first.
  5. If all above conditions are the same, the CatalogSources are sorted based on their names in lexicographical order, and the first one with the shortest name will be picked up.

Operand Deployment Lifecycle Manager creates the OperandRegistry and OperandConfig instances by default. You must manually create the OperandRequest instance to specify the services that you want to install in your cluster.

Creating the OperandRequest instance

Edit online

  1. Create the operand-request.yaml file with the following definition. Specify only the services that you want to install in your cluster. Remove the service entries (operands) that you do not want to install.

    For a list of foundational services that you can install, see IBM Cloud Pak foundational services Operators and versions.

    apiVersion: operator.ibm.com/v1alpha1
kind: OperandRequest
metadata:
  name: <custom-name-of-operand-request>
  namespace: <your-foundational-services-namespace>
  labels:
    app.kubernetes.io/instance: operand-deployment-lifecycle-manager
    app.kubernetes.io/managed-by: operand-deployment-lifecycle-manager
    app.kubernetes.io/name: operand-deployment-lifecycle-manager
spec:
  requests:
    - operands:
        - name: ibm-im-operator
        - name: ibm-platformui-operator
      registry: common-service
    Note: You can create the OperandRequest in any namespace. If you create the OperandRequest in a different namespace than where OperandRegistry and OperandConfig custom resources are, change the namespace: parameter value to the namespace from where you are creating the OperandRequest. Add the registryNamespace:<your-foundational-services-namespace> parameter in the OperandRequest. See the following example:
    apiVersion: operator.ibm.com/v1alpha1
kind: OperandRequest
metadata:
  name: <custom-name-of-operand-request>
  namespace: <OperandRequest namespace>
spec:
  requests:
    - operands:
        - name: ibm-im-operator
         .
         .
         .
      registry: common-service
      registryNamespace: <your-foundational-services-namespace>

  2. In the spec.requests.operands section, retain the operator names of the services that you want to install in your cluster. You can remove the services that you do not want. If you awant to install additional services that are not listed in the example, reach out to your IBM Cloud Paks team for the operator names.

  3. (Optional) Add bindings to access a service. This step is optional. For more information, see Accessing the services.

  4. Create the OperandRequest instance.

    oc apply -f operand-request.yaml

Checking the status of the operator

Edit online

You can verify the status of the operators by running the following commands:

oc -n <operator-namespace> get csv

Following is a sample command and output:

oc -n <your IBM Cloud Pak® namespace> get csv

NAME                                          DISPLAY                                VERSION   REPLACES                                      PHASE
cloud-native-postgresql.v1.25.1               EDB Postgres for Kubernetes            1.25.1    cloud-native-postgresql.v1.22.8               Succeeded
ibm-cert-manager-operator.v4.2.16             IBM Cert Manager                       4.2.16    ibm-cert-manager-operator.v4.2.15             Succeeded
ibm-common-service-operator.v4.13.0           IBM Cloud Pak foundational services    4.13.0    ibm-common-service-operator.v4.12.0           Succeeded
ibm-commonui-operator.v4.9.0                  Ibm Common UI                          4.9.0                                                   Succeeded
ibm-iam-operator.v4.12.0                      IBM IM Operator                        4.12.0                                                  Succeeded
operand-deployment-lifecycle-manager.v4.5.1   Operand Deployment Lifecycle Manager   4.5.1     operand-deployment-lifecycle-manager.v4.5.0   Succeeded

Checking pod status

Edit online

To verify the installation, check the status of the pods in the foundational-services namespace. You can run the following command:

oc get pods -n <your-foundational-services-namespace>

Accessing the foundational services console

Edit online

Retrieve your access URL, username, and password.

Getting the console URL

Edit online

Get the URL to access the console.

You can get the IBM Cloud Pak console route for accessing the Administration panel by running the following command:

oc get route -n <your-foundational-services-namespace> cp-console -o jsonpath='{.spec.host}' && echo

The response is your https://<cluster_address>. <cluster_address> is the IBM Cloud Pak console route. Following is a sample output:

cp-console.apps.mycluster.mydomain.com

Based on the example output, your console URL would be https://cp-console.apps.mycluster.mydomain.com.

Getting the console username

Edit online

The default username to access the console is cpadmin. You can get the default username by running the following command:

oc -n <your-foundational-services-namespace> get secret platform-auth-idp-credentials -o jsonpath='{.data.admin_username}' | base64 -d && echo

Getting the password

Edit online

You can get the password for the default username by running the following command:

oc -n <your-foundational-services-namespace> get secret platform-auth-idp-credentials -o jsonpath='{.data.admin_password}' | base64 -d &&echo

Following is a sample output:

EwK9dj9fwPZHyHTyu9TyIgh9klZSzVsA

Based on the example output, you would use EwK9dj9fwPZHyHTyu9TyIgh9klZSzVsA as the password.

You can change the default password at any time. For more information, see Changing the cluster administrator password.

Note: Any user with access to the foundational-services namespace can retrieve this password since it is stored in a secret in the foundational-services namespace. To minimize password exposure, allow limited users to access the foundational-services namespace.

Accessing Business Teams Service console

Edit online

Navigate to http://<cpd_host>/teamserver/ui to access the UI where the cpd-host is the cpd route. To obtain the cpd route, run the following command:

oc get route cpd

Log in with a user role that has the Administrate business teams permission. For more information, see Business Teams Service Authorization.

Enabling or disabling foundational services after installation

Edit online

After you create an instance of the OperandRequest, you must use the same instance to enable or disable foundational services.

To enable or disable foundational services after installation, run the following command to edit the OperandRequest instance:

oc -n <your-foundational-services-namespace> edit operandrequest <custom-name-of-operand-request>