Checking the cluster configuration

You must check and edit the shared sections of the compiled custom resource file before you apply it to the operator.

About this task

In all cases, check the <Required> values for the image_pull_secrets and images parameters in the shared_configuration section. For more information, see Shared configuration parameters.

Table 1. Checking `<Required>` parameters for selected images
Parameter	Description
keytool_job_container	Repository from where to pull the UMS `keytool_job_container` and the corresponding tag.
dbcompatibility_init_container	Repository from where to pull the Application Engine `init_container` and the corresponding tag.
keytool_init_container	Repository from where to pull the UMS `keytool_init_container` and the corresponding tag.
umsregistration_initjob	Repository from where to pull the Application Engine `umsregistration_initjob` and the corresponding tag.
image_pull_secrets	Secrets in your target namespace to pull images from the specified repository.

Procedure

Locate the shared_configuration section in the custom resource (CR) file (ibm_cp4a_my_cr_final.yaml) you created in Generating the custom resource, then check and correct the deployment parameters.
The custom resource templates can include the following parameters:
License parameters
sc_deployment_license, which can be: non-production, or production.

sc_deployment_fncm_license, which can be: user, non-production, or production.

sc_deployment_baw_license, which can be: user, non-production, or production.
Platform parameters
sc_deployment_platform, which can be "OCP", "ROKS", or "other".

For 21.0.1 sc_deployment_hostname_suffix, check the infrastructure node name for OCP and ROKS.
Note: If your target platform sc_deployment_platform is set to OCP, proceed as follows:

Get the IP address of the cluster sub-domain.

Get the hostname by running the the following command.
oc get routes --all-namespaces | grep -i console

Ping the host to get the IP address.

Enter the address in the sc_deployment_hostname_suffix parameter.
sc_deployment_hostname_suffix:"{meta.namespace}.yourdomain.com"

sc_ingress_enable, must be set to true to create an ingress on ROKS.
Storage parameters
These parameters are mandatory.

sc_slow_file_storage_classname

sc_medium_file_storage_classname

sc_fast_file_storage_classname
Content pattern parameters
These parameters can be true or false.

sc_content_initialization

sc_content_verification
Optional: Configure the root secret, external SSL/TLS certificate secret, and the trusted certificate list.

The custom YAML file includes the root_ca_secret, external_tls_certificate_secret, and trusted_certificate_list parameters. The root_ca_secret parameter is the name of the secret that contains the root CA signer certificate for the Cloud Pak. If the secret does not exist, then a self-signed signer certificate is generated. For more information, see Providing the root CA certificate.

For production environments, it is likely that you want to use your own certificates that are trusted by your clients. The external_tls_certificate_secret parameter is used to store a wildcard certificate, which can be more convenient than a certificate for each subdomain. A multi-domain wildcard certificate can also be used to secure multiple domains and their subdomain names. For more information, see Providing certificates for external routes.

Important: If you choose to use self-signed certificates, certain features of the product might not work as expected because of modern browser restrictions that are related to self-signed certificates. A browser blocks any redirect to a site that uses a certificate that is not signed by a root CA that is trusted by the browser. This can result in access issues for business applications.

The trusted_certificate_list parameter can be used to trust root CA certificates for external services. For more information, see Connecting securely with external services.
Check the resource_registry_configuration section.
Automatic backup for the Resource Registry is recommended. For more information, see Enabling Resource Registry disaster recovery.
Note: Check that your hostname is valid. The length of the hostname must be fewer than 64 characters. If the hostname is too long, use a wildcard DNS (https://nip.io/).
Instead of the full name:
```
resource_registry_configuration:
   admin_secret_name: resource-registry-admin-secret
   hostname: hostname: rr-{{ meta.namespace }.I-have-a-very-long-hostname-which-exceeds-64-characters.cloud.com
```
Use a wildcard for the hostname:
```
resource_registry_configuration:
   admin_secret_name: resource-registry-admin-secret
   hostname: rr-{{ meta.namespace }.<Public IP of Hostname>.nip.io
```

Check the values for the UMS and Application Engine repositories, the image_pull_secrets parameter, and the sc_image_repository parameter.

All components use the same docker image repository. By default, the IBM Entitlement Registry is used "cp.icr.io". For an air gap installation make sure that the sc_image_repository parameter is set to the default value.

If you use an internal registry, enter your values for these parameters.

Note: If your custom resource does not include UMS or BAA, you do not see these lines in your custom resource file.

shared_configuration:

  sc_image_repository: cp.icr.io
  
  image_pull_secrets:
  - admin.registrykey
  images:
     keytool_job_container:
       repository: <registry_url>:5000/<namespace>/dba-keytool-initcontainer
       tag: <version> 
     dbcompatibility_init_container:
       repository: <registry_url>:5000/<namespace>/dba-dbcompatibility-initcontainer
       tag: <version>
     keytool_init_container:
       repository: <registry_url>:5000/<namespace>/dba-keytool-jobcontainer
       tag: <version>   
     umsregistration_initjob:
       repository: <registry_url>:5000/<namespace>/dba-umsregistration-initjob
       tag: <version>
     pull_policy: IfNotPresent

The <version> number is 21.0.x.

Enter the parameter values for your LDAP instance in the ldap_configuration section.
If you need to create a secret for the lc_bind_secret parameter to store the bind dn and bind password, then go ahead and create it.
```
kubectl create secret generic my-ldap-tds-secret --from-literal=ldapUsername="cn=root" --from-literal=ldapPassword="XXXXXXXX"
```
Important: When the LDAP password expires or changes, you must remember to update this secret with the new password, and then restart any pods that got stuck or failed as a result of the LDAP being inaccessible, for example the UMS ums-scim pods.

Set the value in the custom resource file.

Note: LDAP Anonymous authentication does not need a secret.

If you want to use SSL-enabled LDAP in your container environment, you must create the SSL secret with the certificate of the LDAP server.
1. Get the root CA that is used to sign your LDAP server and save it to a certificate, for example ldap-server-cert.crt. See OpenSSL for instructions to export the root CA of your external service.
2. To create the secret, run the following command.
```
kubectl create secret generic secretName --from-file=tls.crt=your_cert_path/ldap-server-cert.crt
```
  Substitute your values for secretName and your_cert_path/ldap-server-cert.crt. The certificate and key files must be in Privacy Enhanced Mail (PEM) format.
3. After you obtain the certificate and create the secret, you enable SSL and provide the secret name in the custom resource YAML file in the ldap_configuration section.
```
ldap_configuration:
  …
    lc_ldap_ssl_enabled: true
    lc_ldap_ssl_secret_name: "<secretName>"
```
  Set the enabled parameter to true and provide your own secret name.
Enter the parameter values for your data source instance in the datasource_configuration section.

Your deployment might need a number of databases. Follow the configuring instructions for each component to complete this section.
Check the Kafka parameters in the kafka_configuration section.
The customization of the following parameters is needed only if you specified "bai" in the sc_optional_components parameter. If Business Automation Insights is not part of the deployment, you do not need to configure these parameters and they can be kept empty.
- bootstrap_servers: A comma-separated list of host:port values for the connection to the Kafka cluster.
- security_protocol: Value for the Kafka security.protocol property. Valid values are: PLAINTEXT, SSL, SASL_PLAINTEXT, SASL_SSL.
- sasl_mechanism: Value for the Kafka sasl.mechanism property. Valid values are: PLAIN, SCRAM-SHA-512.
- connection_secret_name: If the Kafka server needs authentication or uses SSL communications, the value of this field must provide the name of a secret that contains the following keys as base64-encoded strings:
  - kafka-username: Kafka username.
  - kafka-password: Kafka password.
  - kafka-server-certificate: Server certificate for SSL communications.