Known issues in foundational services

After the platform-auth-service pod restarts, an incorrect entityID appears in the SAML metadata file.

• If you use foundational services version 4.6.8 to 4.6.14, the incorrect entity is https://platform-auth-service:9443/ibm/saml20/defaultSP.
• If you use a foundational services version before 4.6.8, or if you use version 4.6.15 and later, the incorrect entity is https://platform-auth-service:9443/idauth/ibm/saml20/defaultSP.

The spHostAndPort and createSession SAML web browser SSO configurations are not retained.

Symptoms After the platform-auth-service pod restarts, the downloaded SAML metadata file shows the entityID as https://platform-auth-service:9443/ibm/saml20/defaultSP or https://platform-auth-service:9443/idauth/ibm/saml20/defaultSP instead of the expected configured value, and SAML logins fail.

After successful SAML IdP registration, the platform-identity-provider pod creates a saml.xml file. The pod copies the file to the platform-auth-service pods in the /config/configDropins/defaults/saml.xml location. If the platform-auth-service pod crashes, the new pods read the IdP configuration from the database and re-create the same file on startup. SAML web browser SSO configurations like spHostAndPort and createSession are not written back into the file.

Resolution

Edit the SAML connection and save it without any changes.

1. From the list of IdPs that are configured, select the SAML IdP. The View SAML connection window opens.
2. From Connection details, click Edit.
3. Then, click Save. The platform-identity-provider pod can rewrite and copy over the correct files on the platform-auth-service pods.

The common-service-db-im-tls-secret secret is refreshed every 3 months. But the operator doesn't restart the platform-identity-management pods after the im-datastore-edb-secret certificate is refreshed, and the operator encounters an expired certificate. The IM component fails for authentication and authorization operations.

Symptoms

The platform-identity-management pod logs contain the [SequelizeConnectionError]: 00D8C999997F0000:error:0A003415:SSL routines:ssl3_read_bytes:sslv3 alert certificate expired error.

Resolution

Manually restart the platform-auth-service, platform-identity-provider, and platform-identity-management identity management pods within a month of when the common-service-db-im-tls-cert certificate was last renewed. After the first expiration, other expirations occur about every 2 months.

When you upgrade from foundational services v3.19 to a 4.6.x version before 4.6.16, IM audit log forwarding is prevented.

Log forwarding is supported only when Zen is installed. If Zen is installed, IM sends the audit logs to zen-audit-svc when you enable the auditing service for IM. If Zen is not installed, forwarding audit logs for IM is not supported.

For more information, see Auditing IM service.

If you upgrade IBM Cloud Pak foundational services from version 3.19.x to version 4.6.x, the SAML configuration might not be retained when it is configured with the cloudctl command line tool.

Symptom: Data that was previously migrated doesn't have the SAML configuration, and logging in with SAML is no longer possible.

Resolution: To resolve the issue, see SAML configured with cloudctl isn't retained after upgrading from foundational services 3.19.x to 4.x.

From foundational services version 4.6.10, IM operator requires the TLS certificate verification for external EDB PostgreSQL connections. If the existing server certificates do not contain Subject Alternative Name (SAN), replace the existing server certificate in an external EDB PostgreSQL server with the new server certificate that contains SANs. The SAN attribute values have to be DNS names that the certificate is valid for, or IP address for the server where the certificate is used. This requirement follows the modern security best practices and guidelines in RFC 9525.

Symptoms

The following error message is displayed in the IM operator log:

{"level":"info","ts":"2025-02-26T20:21:21Z","logger":"controller_authentication","msg":"Perform any pending migrations","Request.Namespace":"production","Request.Name":"example-authentication","subreconciler":"handleMigrations"}
{"level":"info","ts":"2025-02-26T20:21:21Z","logger":"controller_authentication","msg":"Retrieving change logs","Request.Namespace":"production","Request.Name":"example-authentication"}
{"level":"info","ts":"2025-02-26T20:21:21Z","logger":"controller_authentication","msg":"Connecting to PostgresDB","Request.Namespace":"production","Request.Name":"example-authentication","PostgresDB.Host":"postgres-client-auth1.fyre.ibm.com","PostgresDB.Port":"5432"}
{"level":"error","ts":"2025-02-26T20:21:21Z","logger":"controller_authentication","msg":"Failed to connect to PostgresDB","Request.Namespace":"production","Request.Name":"example-authentication","error":"failed to connect to `host=postgres-client-auth1.fyre.ibm.com user=postgres database=imcnpdb`: failed to write startup message (write failed: tls: failed to verify certificate: x509: certificate relies on legacy Common Name field, use SANs instead)","stacktrace":"github.com/IBM/ibm-iam-operator/database/schema/v1.GetChangelogs\n\t/home/prow/go/src/github.com/IBM/ibm-iam-operator/database/schema/v1/tables.go:1523\ngithub.com/IBM/ibm-iam-operator/database.PlanMigrations\n\t/home/prow/go/src/github.com/IBM/ibm-iam-operator/database/migrate.go:61\ngithub.com/IBM/ibm-iam-operator/controllers/operator.(*AuthenticationReconciler).handleMigrations\n\t/home/prow/go/src/github.com/IBM/ibm-iam-operator/controllers/operator/migration.go:378\ngithub.com/IBM/ibm-iam-operator/controllers/operator.(*AuthenticationReconciler).Reconcile\n\t/home/prow/go/src/github.com/IBM/ibm-iam-operator/controllers/operator/authentication_controller.go:369\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Reconcile\n\t/home/prow/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.16.1/pkg/internal/controller/controller.go:119\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler\n\t/home/prow/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.16.1/pkg/internal/controller/controller.go:316\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem\n\t/home/prow/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.16.1/pkg/internal/controller/controller.go:266\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2\n\t/home/prow/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.16.1/pkg/internal/controller/controller.go:227"}
{"level":"error","ts":"2025-02-26T20:21:21Z","logger":"controller_authentication","msg":"Failed to handle migrations","Request.Namespace":"production","Request.Name":"example-authentication","subreconciler":"handleMigrations","error":"failed to form a migration plan: failed to retrieve changelogs: failed to connect to `host=postgres-client-auth1.fyre.ibm.com user=postgres database=imcnpdb`: failed to write startup message (write failed: tls: failed to verify certificate: x509: certificate relies on legacy Common Name field, use SANs instead)","stacktrace":"github.com/IBM/ibm-iam-operator/controllers/operator.(*AuthenticationReconciler).handleMigrations\n\t/home/prow/go/src/github.com/IBM/ibm-iam-operator/controllers/operator/migration.go:381\ngithub.com/IBM/ibm-iam-operator/controllers/operator.(*AuthenticationReconciler).Reconcile\n\t/home/prow/go/src/github.com/IBM/ibm-iam-operator/controllers/operator/authentication_controller.go:369\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Reconcile\n\t/home/prow/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.16.1/pkg/internal/controller/controller.go:119\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler\n\t/home/prow/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.16.1/pkg/internal/controller/controller.go:316\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem\n\t/home/prow/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.16.1/pkg/internal/controller/controller.go:266\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2\n\t/home/prow/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.16.1/pkg/internal/controller/controller.go:227"}
{"level":"info","ts":"2025-02-26T20:21:21Z","logger":"controller_authentication","msg":"Update status before finishing loop.","Request.Namespace":"production","Request.Name":"example-authentication"}
 

Resolution

To resolve the issue, see IM pods cannot be deployed when foundational services is configured with external EDB PostgreSQL.

SAML IdP registration fails when the size of the idp_metadata is more than 1.5 MB.

Symptom

The following error message is displayed:

Payload Too Large
 

Invalid JSON input
 

Resolution

From foundational services 4.11, the maximum accepted size of the metadata is 2 MB. To resolve the issue, upgrade the existing foundational services version to v4.11.

The SAML login fails when you configure SAML with IdP initiated login.

Symptom

The following error is displayed:

500: The SAML login attempt failed. This failure could indicate that the SAML identity provider has been misconfigured. If this is an IDP initiated SAML provider, verify that the relay state parameter is set.
 

Resolution

To resolve the issue, set the relay state in the IdP end. For more information, see SAML login fails when you configure SAML with IdP initiated login.

The Display name and email are displayed as undefined undefined for IBM Security Verify. The values are not retrieved when listed from the associated IdP group in Cloud Pak for Data.

Symptom

The Display name and email in the group is displayed as undefined undefined when you list the users in the group in IBM Security Verify.

The following is the sample error in IBM Security Verify:

Resolution

This limitation is planned to be fixed in an upcoming release.

Updating default Admin username in foundational services v4.6.3 fails and returns 400 Bad request. You need to update the Admin username manually.

Symptom

You cannot update the default admin username using the idmgmt/identity/api/v1/users/defaultAdmin API and the following error message is displayed:

400 Bad request
 

Resolution

From foundational services v4.6.4, the issue is fixed and you can update the default admin username using the idmgmt/identity/api/v1/users/defaultAdmin API.

Client registration fails in the Platform UI console when you upgrade foundational services version 3.22 or version 3.23 to foundational services version 4.x.x.

Symptoms

You might fail to register the client in Platform UI console in the following scenarios:

• When you upgrade the foundational services version 3.22 or version 3.23 to foundational services version 4.x.x and migrate more than one LDAP.

• When you have more than one LDAP before upgrading foundational services version 3.22 or version 3.23 to foundational services version 4.x.x.

Resolution

This limitation is planned to be fixed in an upcoming release. Until then, to work around the issue, see Client registration failure in Platform UI console.

Platform UI console login fails when you upgrade foundational services version 3.22 or version 3.23 to foundational services version 4.x.x.

Symptom

There might be intermittent login failure in Platform UI console when you upgrade the foundational services version 3.22 or version 3.23 to foundational services version 4.x.x and then configure the multiple LDAPs.

Resolution

This limitation is planned to be fixed in an upcoming release. Until then, to work around the issue, see Intermittent login failure in Platform UI console.

In foundational services version 3.23 and later, the username in the group is displayed as undefined undefined when you list the users in the group in Platform UI console by using Azure SCIM integration or SAML without LDAP configuration.

Resolution

It is a known limitation. Currently, no workaround is available.

In foundational services version 3.23, Okta user cannot log out in the Platform UI once that user login to Okta as SAML IdP (Identity provider).

It happens because the Okta user might be logging out from the Cloud Pak only, not from Okta. As a result, the Okta user still resides in the cookie of your browser and the Cloud Pak cannot log out the Okta user. You need to log out from Okta to delete the cookie from your browser. Once you log out from the Okta, you can login with new user or the same user with new session.

The login page is displayed again instead of the home page of the console once you provide the login details. However, the second time you don't need to provide the details in the login page, you just need to click Login and the home page of the console will be displayed. It is a known limitation. Currently, no workaround is available.

Before you register the OIDC clients by using IdP V3 API, you need to login into third party ID provider. And, then you can register the OIDC clients in the application. While registering, you use application url as cp-console url and redirect URL as https://<cp-console-url>/ibm/api/social-login/redirect/<name of the oidc>. However, you might face issue while opening the cp-console browser. When you click the configured ID provider name, you might not be redirected to the authentication page of that IdP.

Resolution

To troubleshoot the issue, see OIDC registration fails to update.

You must use the name exactly the way it is configured in your LDAP directory.

You must assign roles individually to SAML users in IM.

The OpenShift group does not synchronize when a user is added or removed from an LDAP group.

An OpenShift group is created when you add the LDAP group to teams. When a user is added or removed from an LDAP group at the LDAP server side, the OpenShift group does not update by any process or thread in IM.

Resolution

To resolve this issue, delete and re-add the LDAP group to teams to recreate the OpenShift group with the latest members.

An OpenShift group is created when you add the LDAP group to teams. An OpenShift user is created when you add an LDAP user to teams, or when this LDAP user logs in to the IBM Cloud Pak console. When a user is removed from an LDAP group at the LDAP server side, the OpenShift group does not update by any process or thread in IM. An OpenShift user or group is deleted only if this user or group is deleted from teams.

Resolution To resolve this issue, delete and re-add the LDAP group to teams to recreate the OpenShift group with the latest members, and manually delete the OpenShift user. To delete the user, use the following command: oc delete user <user_id>.

The SAML and LDAP authentication types are displayed in the cp-console login page when you migrate IM from version 3.x to 4.x with the configuration of SAML with LDAP dependency using V2 API.

Resolution

To resolve the issue, update the Identity Provider (IdP) for SAML with LDAP dependency with V3 API schema elements. For more information, see SAML with LDAP dependency using V2 API does not work correctly.

The SAML identity provider is removed from the SAML configuration when you upgrade from OCP version 4.10 to 4.12.

To resolve the issue, complete the following steps:

1. Restart the MongoDB and auth pods.

   oc delete pod -n ibm-common-services -l app=icp-mongodb
    

2. Verify that the pods are running.

   oc get pod -n ibm-common-services | egrep 'NAME | icp-mongodb'
    

   If the pod status shows as Running, proceed with the next step.

3. Delete the auth pods.

   oc delete pod -n ibm-common-services -l k8s-app=auth-idp
   oc delete pod -n ibm-common-services -l k8s-app=auth-pap 
   oc delete pod -n ibm-common-services -l k8s-app=auth-pdp 
    

4. Verify the pod status.

   oc get pod -n ibm-common-services | egrep 'NAME|auth-idp|auth-pap|auth-pdp
    

IM access token API (/idprovider/v1/auth/identitytoken) fails when you upgrade IBM Cloud Pak for Data version 4.7.4 to 5.0.0.

The following error is diplayed in the log when you generate IM access token:

Failed to get access token, Liberty error: {\"error_description\":\"CWWKS1406E: The token request had an invalid client credential. The request URI was \\/oidc\\/endpoint\\/OP\\/token.\",\"error\":\"invalid_client\"}"
 

To resolve the IM access token issue, run the following command to restart the oidc-client-registration job:

oc -n <your-foundational-services-namespace> delete job oidc-client-registration
 

This issue is resolved in foundational services version 4.8.x.

The value of client_secret is stored in the database with the empty value when you update the SAML ISV connection using the console.

To resolve the issue, add the secret in the Client secret field in the SCIM configuration section. For more information, see Unable to find and add the IDP users and user groups using the console .

You cannot onboard OpenShift user group to IM because the groups property of the user.openshift.io API is deprecated. For more information, see User [user.openshift.io/v1].

To resolve the issue, you can add the individual users manually and provide access to each user instead of managing the access as groups.

When you update the deployment profile, for example from starterset to large, the capacity of hardware resources does not automatically update.

To resolve this problem, restart the common-service-db pods.

Unable to login to cp-console or cpd using LDAP authentication. The ClassCastException error is displayed if the ObjectClass or ObjectCategory attribute is not defined in the Liberty XML file.

Symptoms

The following error is displayed in the logs of the auth-service pods:

Exception = java.lang.ClassCastException
Source = com.ibm.ws.security.oauth20.plugins.jose4j.OidcUserClaims
probeid = 178
Stack Dump = java.lang.ClassCastException: com.ibm.wsspi.security.wim.model.Entity incompatible with com.ibm.wsspi.security.wim.model.PersonAccount
  at com.ibm.ws.security.oauth20.plugins.jose4j.OidcUserClaims.getUserinfoFromRegistryMap(OidcUserClaims.java:136)
  at com.ibm.ws.security.oauth20.plugins.jose4j.OidcUserClaims.getUserinfoFromRegistry(OidcUserClaims.java:177)
  at com.ibm.ws.security.openidconnect.web.OidcEndpointServices.getUserinfoFromRegistry(OidcEndpointServices.java:1001)
  at com.ibm.ws.security.openidconnect.web.OidcEndpointServices.userinfo(OidcEndpointServices.java:922)
  at com.ibm.ws.security.openidconnect.web.OidcEndpointServices.handleOidcRequest(OidcEndpointServices.java:281)
  at com.ibm.ws.security.openidconnect.web.OidcEndpointServlet.handleRequest(OidcEndpointServlet.java:111)
  at com.ibm.ws.security.openidconnect.web.OidcEndpointServlet.doPost(OidcEndpointServlet.java:69)
  at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
 

Resolution

From foundational services v4.6.3, IM supports the LDAP Entity type configuration for LDAP User and Group entities to define the ObjectClass or ObjectCategory attributes automatically in the Liberty XML file. For more information, see Unable to login to cp-console or cpd using LDAP authentication.

Zen reconciles multiple times to complete EDB PostgreSQL database migration when you upgrade from foundational services version 3.x to 4.6.

Symptoms

The following errors might be displayed in the ibm-zen-operator pod logs:

stderr: 'W0425 07:10:15.993498    6885 reflector.go:456] k8s.io/client-go/tools/watch/informerwatcher.go:146: watch of *unstructured.Unstructured ended with: an error on the server ("unable to decode an event from the watch stream: no kind \"Pod\" is registered for version \"v1\" in scheme \"k8s.io/client-go/dynamic/scheme.go:29\"") has prevented the request from succeeding'^[[0m^M
 

stderr: 'error: no matching resources found'^[[0m^M
 

The following error might be displayed in the ibm-iam-operator logs:

{"level":"error","ts":"2024-05-28T06:41:18Z","logger":"controller_authentication","msg":"Encountered an error while performing the current migration","Request.Namespace":"cp4ba","Request.Name":"example-authentication","subreconciler":"handleMigrations","error":"failure occurred during MongoToV1: server selection error: server selection timeout, current topology: { Type: ReplicaSetNoPrimary, Servers: [{ Addr: mongodb.ibm-common-services.svc.cluster.local:27017, Type: Unknown, Last error: dial tcp 172.30.246.180:27017: i/o timeout }, ] }","stacktrace":"github.com/IBM/ibm-iam-operator/controllers/operator.(*AuthenticationReconciler).handleMigrations\n\t/home/prow/go/src/github.com/IBM/ibm-iam-operator/controllers/operator/authentication_controller.go:432\ngithub.com/IBM/ibm-iam-operator/controllers/operator.(*AuthenticationReconciler).Reconcile\n\t/home/prow/go/src/github.com/IBM/ibm-iam-operator/controllers/operator/authentication_controller.go:850\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Co...
 

Resolution

To resolve the issue, update the network policy of ibm-iam-operator to enable traffic for the mongo service. For more information, see Zen reconciles multiple times during EDB PostgreSQL database migration.

A login issue might occur by switching to the unified route when IBM Cloud Pak® foundational services is installed with a large profile, such as if multiple replicas of pods are running.

Resolution

If you encounter this issue, deunify the route. For more information, see A login issue might occur with the unified route when running a large profile.

When you upgrade to IBM Cloud Pak foundational services version 4.6 or later while using EDB PostgreSQL cluster as a database, the common-service-db EDB PostgreSQL cluster custom resource (CR) might not be successfully created. This issue might occur if you apply a patch for the license key of the embedded EDB PostgreSQL database on an old version of IBM Cloud Pak foundational services.

This issue can occur when you upgrade to one of the following versions of IBM Cloud Pak foundational services: 4.6.2 to 4.6.7, 4.7.x, 4.8.x and 4.9.x. This issue is fixed in foundational services version 4.6.8, 4.10.0 and later. For more information, see EDB PostgreSQL cluster custom resource is not created during upgrade.

After you install or upgrade to IBM Cloud Pak foundational services version 4.6 or later while using EDB PostgreSQL cluster as a database, the status of common-service-db EDB PostgreSQL cluster custom resource (CR) is stuck in the Setting up primary state or no state.

To resolve the issue, delete the existing common-service-db EDB PostgreSQL cluster CR and re-create it. For more information, see Status of EDB PostgreSQL cluster custom resource is stuck in the Setting up primary state or no state.

The cp-console address is changed after the CS operator is upgraded to v4, but IAM service remains in v3. For more information, see cp-console address is changed after CS operator is upgraded to v4, but IAM service is still in v3.

OLM is unable to generate new installation plans for updates or new installations. For more information about the issue and the steps to resolve the issue, see OLM is unable to generate new install plans.

After you upgrade foundational services, you might see some of the operator pods are in Crashloopbackoff status. This is because of an Operator Lifecycle Manager (OLM) known issue. For more information about the issue and the steps to resolve the issue, see Operator upgrade fails - OLM known issue.

When there is an OpenShift user admin it collides with IBM Cloud Pak foundational services default user admin. To resolve the issue, rename the IBM Cloud Pak foundational services default username if an admin username exists in OpenShift. For more information, see Changing the default admin username.

When you install or upgrade foundational services, you might see that some of the operators are in a Pending, Unknown, or Can't Update status. This is because of an Operator Lifecycle Manager (OLM) known issue.

For more information about the issue and the steps to resolve the issue, see the following topics:

• Install: Operator shows Pending status in a namespace - OLM known issue
• Upgrade: Operator installation hangs during upgrade

When you install foundational services on Azure environment with Azure storage, foundational services pods do not start. To resolve this issue, get the scc.uid from the installation namespace before creating the custom Azure storage class. For more information, see Using Azure File storage class.

After upgrading an OpenShift cluster to OpenShift version 4.15.x via the OpenShift console, the foundational services operator CSV fails with the following message: install strategy failed: rolebindings.rbac.authorization.k8s.io "ibm-common-service-operator-service-auth-reader".

To resolve this issue, see Install strategy fails after upgrading OpenShift to 4.15.x.

ZenService fails to be in the ready status for EDB PostgreSQL. The following error message is logged in the Zen operator log:

stderr: 'error: no matching resources found'
 

To resolve the issue, add the instana: True parameter in the ZenService custom resource. For more information, see ZenService fails to be in the ready status for EDB PostgreSQL.

The zen operator fails when you install or upgrade to Zen version 6.0.4 with the external PostgreSQL database.

Symptom

The following error message is displayed in the Zen operator log:

6.0.4/roles/0010-infra has failed with error: All items completed
 

Resolution

To resolve the issue, you need to update the service resource for the zen-metastore-edb. For more information, see Zen operator fails when you install or upgrade to Zen version 6.0.4.

When you update the deployment profile, for example from starterset to large, the capacity of hardware resources does not automatically update. To resolve this problem, restart the common-service-db pods.

If your changes in the CommonService custom resource (CR) are reverted, create a cs-custom-iam CommonService CR in the common service operator namespace. For more information, see Customization of the CommonService CR is reverted by the IBM Cloud Pak operator.

If you previously configured settings directly in the platform-auth-idp ConfigMap and then directly upgraded to IBM Cloud Pak® foundational services 4.12, some of those settings might be reset to their defaults. If needed, write any custom settings that were originally specified in the ConfigMap to the CommonService CR instead. For more information, see ConfigMap fields are reset after an upgrade.

When you run the setup_tenant.sh script to update the CommonService CR, you might see an error message that indicates an invalid value due to .metadata.resourceVersion field in the CommonService CR. For more information, see Invalid value error when updating the CommonService CR by using the setup_tenant.sh script.

In the cert-manager-controller pod, there are error messages that indicate there is more than one CertificateRequest for one or more Certificates. If CNCF cert-manager and foundational services cert-manager are installed in the cluster, the following output is displayed:

ibm-common-services    cert-manager-cainjector-xxx-xxx</br><br>ibm-common-services    cert-manager-controller-xxx-xxx
ibm-common-services    cert-manager-webhook-xxx-xxx</br><br>ibm-common-services    ibm-cert-manager-operator-xxx-xxx
cert-manager    cert-manager-cainjector-xxx-xxx</br><br>cert-manager    cert-manager-xxx-xxx</br><br>cert-manager cert-manager-webhook-xxx-xxx
 

For more information, see Problem when you install two different cert-managers.

The self-signed CA certificate that is used by IBM Cloud Pak foundational services and created by the cert-manager service has a duration of 90 days. The CA certificate is refreshed by cert-manager but the leaf certificates that use the CA certificate must be manually refreshed.

Recommend that user check the expiration date for the CA certificate and refresh the CA certificate before the expiration date and renew the leaf certificates. The CA certificate duration can also be updated.

The following error message is displayed in the cert-manager-controller pod:

"error"="multiple CertificateRequests were found for the...
 

To resolve the issue, delete the duplicate CertificateRequests. See Multiple CertificateRequest objects block Certificate objects from becoming ready.

After you upgrade to foundational services version 4.0 or later, the Error 404 - Not found error message is displayed when you select the Licensing menu in the IBM Cloud Pak console.

To resolve the issue, remove the ibm-license-service-reporter-bindinfo-ibm-license-service-reporter-zen configmap from the namespace where you deployed the foundational services. For more information, see Retrieving License Service Reporter console route to access the License Service Reporter console directly. -->

Attempting to upgrade the ZenService custom resource results in the following error message that indicates the previous operation has not finished:

Requested operation is aborted as status for the current operation,
        install, is InProgress and requested version 4.5.0 is not the version of
        the previously started operation
 

To resolve this problem, see Upgrade of Platform UI (zen) operand fails. -->

When upgrading Events operator from previous versions, a Zookeeper pod ends up in a CrashLoopBackOff state.

Resolution

To resolve this problem, see Zookeeper pod hangs in a CrashLoopBackOff state.

Events operator is periodically printing the following message: Failed to acquire lock during the reconciliation process, and it is timing out. This might indicate that the lock was not properly released due to an error.

Resolution

To resolve the problem, restart the Events operator to release the lock.

If the FlinkDeployment CR is misconfigured, the Flink pod fails to run.

If jobManagerDeploymentStatus is in MISSING or DEPLOYED_NOT_READY status, check the status.error to get the details of the configuration failure. For more detailed information related to the jobManagerDeploymentStatus error, you can check the Flink operator pod logs. For more information, see Flink operand pods fail to run.

The TLS-proxy container fails to start with readOnlyRootFileSystem option set to true. For more information, see TLS-proxy (nginx) container fails to start.

If an Red Hat® OpenShift® cluster is restarted and all master, infra, and worker nodes are restarted manually or because of an outage, the JobManager pods might fail with a CrashLoopBackOff state and might not recover. For more information, see Pods fail after an OpenShift cluster is restarted.

During the upgrade from Elasticsearch operand to OpenSearch, the highest ordinal pod in each of the role-based statefulsets cannot join the existing cluster and fails to pass the ready checks. Haproxy logs show frequent SSL handshake errors. The CA certificates on the new pods' haproxy containers fail to validate the TLS certificates that are provided by the old pods and vise versa.

Resolution

To resolve the issue, delete the pods from the old cluster. When the statefulset creates the new pods, these pods have the right certificates to join the other pods that participate in the new cluster.

For more information, see New pods cannot join the cluster during or after upgrade from Elasticsearch to OpenSearch.