Troubleshooting deployment issues with App Connect Designer

If you attempt to create an App Connect Designer instance with a FREE license such as AppConnectEnterpriseNonProductionFREE within a namespace that contains a ResourceQuota object, the deployment might fail. A ResourceQuota object typically sets limits for maximum resource consumption within a namespace. When quotas are enforced for resources such as CPU or memory, the quota system might reject pod creation if you do not specify requests or limits for those values in the pod definition of a custom resource that you want to deploy. For a Designer instance (which isn't licensed and therefore has no default CPU limits applied on its containers), you might see the following type of error:

Error creating: pods "designer-name-ui-6d4576c7b7-mzqqk" is forbidden: failed quota: mynamespace: must specify limits.cpu for: designer-name-proxy

The following image shows an example of this message in the Red Hat® OpenShift® web console.

As a workaround for this error, add integrationRuntime and pod fields to the end of the spec section in the Designer custom resource (CR). For example, suppose the Designer CR initially looks like this:

apiVersion: appconnect.ibm.com/v1beta1
kind: DesignerAuthoring
metadata:
  name: my-designer-auth
  labels:
    backup.appconnect.ibm.com/component: designerauthoring
  namespace: ace-demo
spec:
  license:
    accept: true
    license: L-KPRV-AUG9NC
    use: AppConnectEnterpriseNonProductionFREE
  couchdb:
    storage:
      size: 10Gi
      type: persistent-claim
      class: ocs-storagecluster-ceph-rbd
    replicas: 1
  designerMappingAssist:
    incrementalLearning:
      schedule: Every 15 days
    enabled: true
  authentication:
    integrationKeycloak:
      enabled: false
  authorization:
    integrationKeycloak:
      enabled: false
  designerFlowsOperationMode: local
  replicas: 1
  version: '13.0'

Add integrationRuntime and pod fields to the spec section as follows:

apiVersion: appconnect.ibm.com/v1beta1
kind: DesignerAuthoring
metadata: 
  name: my-designer-auth
  labels:
    backup.appconnect.ibm.com/component: designerauthoring
  namespace: ace-demo
spec:
  license:
    accept: true
    license: L-KPRV-AUG9NC
    use: AppConnectEnterpriseNonProductionFREE
  couchdb:
    storage:
      size: 10Gi
      type: persistent-claim
      class: ocs-storagecluster-ceph-rbd
    replicas: 1
  designerMappingAssist:
    incrementalLearning:
      schedule: Every 15 days
    enabled: true
  authentication:
    integrationKeycloak:
      enabled: false
  authorization:
    integrationKeycloak:
      enabled: false
  designerFlowsOperationMode: local
  replicas: 1
  version: '13.0'
  integrationRuntime:
    containers:
      designereventflows:
        resources:
          limits:
            cpu: 1300m
      designerflows:
        resources:
          limits:
            cpu: 1200m
      proxy:
        resources:
          limits:
            cpu: 500m
      runtime:
        resources:
          limits:
            cpu: 1000m
  pod:
    containers:
      connectorAuthService:
        resources:
          limits:
            cpu: 500m
      couchdb:
        resources:
          limits:
            cpu: 500m
      mappingAssist:
        resources:
          limits:
            cpu: 1500m
      proxy:
        resources:
          limits:
            cpu: 100m
      ui:
        resources:
          limits:
            cpu: 500m

When you try to access a flow or an auto-save is attempted, you might see the following message:

Failed to retrieve flows
There was a problem retrieving your flows

Try to resolve this issue by checking whether the problem is certificate-related. To do so, examine the logs in the pod named designerName-fda-xxxxxx-yyyy (for example, des-01-quickstart-fda-7b656dfbbf-rpnkp), where designerName is the metadata.name value that defines the name of the Designer instance in the custom resource (CR), and xxxxxx and yyyy are generated sets of characters.

1. Check for the pod names for the Designer instance by running the following command.

   oc get pod -o name -l app.kubernetes.io/name=designerName -n namespaceName

   For example:

   oc get pod -o name -l app.kubernetes.io/name=des-01-quickstart -n ace-test

   The designerName-fda-xxxxxx-yyyy pod contains two containers that are named as follows:

   • designerName-fda (for example, des-01-quickstart-fda)
   • designerName-proxy (for example, des-01-quickstart-proxy)
2. View the log for the designerName-fda container.

   oc logs -f podName -c containerName

   For example:

   oc logs -f des-01-quickstart-fda-7b656dfbbf-rpnkp -c des-01-quickstart-fda

   Check the output for the following type of error:

   ERROR Failed to get document from flows DB for user: default [flowDB.js:1]
   dataObj: "{\"message\":\"The connection failed because the SSL certificate is not valid. To use a self-signed certificate, set the `disableSslVerification` parameter in the constructor options.\",\"name\":\"Error\",\"stack\":\"Error: The connection failed because the SSL certificate is not valid. To use a self-signed certificate, set the `disableSslVerification` parameter in the constructor options.\\

   If you see this error, there might be a mismatch between the certificates that are loaded by the microservices and by the CouchDB database that stores flow definition artifacts in the container’s file system. This mismatch can occur if the certificates have been updated or rotated. CouchDB automatically pick ups any new certificates, but the microservices need to be restarted to pick up new certificates.

3. To restart the microservices to pick up any new certificates, run the following commands in a bash shell (but not ksh).
   1. If necessary, switch to the namespace where the Designer instance is deployed.

      oc project designerNamespace

   2. Run the following command.

      
      oc get deployments -l appconnect.ibm.com/kind=DesignerAuthoring,app.kubernetes.io/name=designerName --no-headers |  awk '{print $1 }' |  xargs oc patch deploy $0 -p "{\"spec\":{\"template\":{\"metadata\":{\"annotations\":{\"appconnect-restart\":\"`date +'%s'`\"}}}}}"

      For example:

      
      oc get deployments -l appconnect.ibm.com/kind=DesignerAuthoring,app.kubernetes.io/name=des-01-quickstart --no-headers |  awk '{print $1 }' |  xargs oc patch deploy $0 -p "{\"spec\":{\"template\":{\"metadata\":{\"annotations\":{\"appconnect-restart\":\"`date +'%s'`\"}}}}}"

      This command triggers a rolling restart of all the pods (apart from the CouchDB pods) that are used by the Designer instance.

4. After all the pods have restarted, try to access the Designer UI.
5. If the issue is not resolved, open a case with IBM Support as described in Contacting IBM.

When creating an App Connect Designer instance, you are required to choose a storage class (spec.couchdb.storage.class) if the storage type (spec.couchdb.storage.type) for CouchDB is set to persistent-claim.

If a Designer instance is created with a spec.version value that resolves to 12.0.5.0-r1-lts or 12.0.5.0-r2, your specified storage class in the custom resource (CR) is not honored and the deployed instance instead uses the cluster's default storage class. This issue is resolved in 12.0.5.0-r3 or later, but if you upgrade from 12.0.5.0-r1-lts or 12.0.5.0-r2 to 12.0.5.0-r3 or later, the original default storage class will still be used with the Designer instance. To switch to the actual storage class that is defined in the CR, you must delete and then re-create your instance. (You will need to export any saved flows before you delete the instance, and then import the flows after re-creating the instance.)

For more information, see App Connect Designer reference: Creating an instance and Exporting and importing flows.