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
dbcompatibility_init_container	Repository from where to pull the Application Engine `init_container` 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) that you created in Generating the custom resource with the deployment script, 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" or "ROKS".

sc_ingress_enable, must be set to true to create an ingress on ROKS.
Sizing parameters

sc_deployment_profile_size, which determines the profile of your deployment. The default is small, but you can change the profile to medium or large.

Storage parameters
These parameters are mandatory.

sc_slow_file_storage_classname

sc_medium_file_storage_classname

sc_fast_file_storage_classname

sc_block_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.

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 image_pull_secrets parameter, the sc_image_repository parameter, and for the Application Engine repositories.
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 loaded the images to a local registry, enter your values in the sc_image_repository parameter and edit the admin.registrykey secret with the local "Registry Server Address" (for example mycorp-docker-local.mycorp.com) and the user credentials to pull the images from your registry.
```
sc_image_repository: <registry_domain_name>/<project-name>
```
Note: If your custom resource does not include 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:
     dbcompatibility_init_container:
       repository: <registry_url>:5000/<namespace>/dba-dbcompatibility-initcontainer
       tag: <version> 
     pull_policy: IfNotPresent
```
The <version> number is 21.0.3.
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.

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.