During recent HCL Connections Activities Plus (Huddo Boards) deployments, I’ve encountered a recurring issue related to the Ingress PathType setting. This post outlines the problem, provides two possible solutions, and offers some technical background information.
The Problem #
On newer Kubernetes (K8s) releases (version 1.33 and above), using default Ingress policies/settings, Activities Plus (Huddo Boards) deployments would consistently fail with the following error messages:
I1021 15:17:07.322429 475088 warnings.go:110] "Warning: path /api-boards/?(.*) cannot be used with pathType Prefix"
I1021 15:17:07.375949 475088 warnings.go:110] "Warning: path /boards/?(.*) cannot be used with pathType Prefix"
Error: 2 errors occurred:
* admission webhook "validate.nginx.ingress.kubernetes.io" denied the request: ingress contains invalid paths: path /api-boards/?(.*) cannot be used with pathType Prefix
* admission webhook "validate.nginx.ingress.kubernetes.io" denied the request: ingress contains invalid paths: path /boards/?(.*) cannot be used with pathType Prefix
Interestingly, on an older OpenShift release(version 4.17, running K8s 1.30), the deployment would complete, showing only the warnings listed above. However, the Activities Plus application would still not function correctly. Specifically, user avatars were not displayed, and the file uploads were not accepted.
Solutions #
Depending on your environment and your requirements, there are multiple solutions for this issue.
1. Modifying the Ingress Controller Settings (K8s) #
To sucessfully resolve the deployment failure on K8S 1.33, I modified the Ingress Controller’s global settings/policies by adding the parameter controller.config.strict-validate-path-type=false.
While there are multiple ways to achieve this, I implemented it directly via the Helm upgrade/install command for the Ingress Controller deployment:
helm upgrade cnx-ingress -i ingress-nginx/ingress-nginx --namespace connections --set controller.service.type=NodePort,controller.service.nodePorts.http=32080,controller.service.nodePorts.https=32443,defaultBackend.enabled=true,controller.healthStatus=true,controller.healthCheckPath="/healthz",controller.livenessProbe.timeoutSeconds=60,controller.readinessProbe.timeoutSeconds=60,controller.config.strict-validate-path-type=false --wait
Important Note: As this specific K8S cluster is used solely for HCL Connections, making this global change to the Ingress Controller settings was not an issue. However, this might not be a viable option in all K8s environments due to potential broader impacts.
2. Changing the PathType Setting for Activities Plus Ingresses (Targeted Change) #
On the aforementioned OpenShift Cluster (K8s 1.30), despite completing the deployment with warnings, the Activities Plus application remained (partly) non-functional.
To address this, I modified the PathType parameter for both the huddo-boards-cp-core and huddo-boards-cp-webfront Ingresses from Prefix to ImplementationSpecific.
In OpenShift, this can be done via the OpenShift GUI or by using the following oc edit commands:
oc edit ingresses huddo-boards-cp-core
oc edit ingresses huddo-boards-cp-webfront
Executing either of these commands will open the YAML configuration file for the respective Ingress. Within this file, locate and modify the PathType parameter from Prefix to ImplementationSpecific. After applying this modification, the Activities Plus application successfully displayed user avatars and accepted file uploads.
Firstly, my decision to use ImplementationSpecific was influenced by the fact that other HCL Connections Ingresses typically use this PathType setting out of the box.
Technical Background #
According to the K8S documentionation on Ingress NGINX, Ingresses with ImplementationSpecific PathType setting are permited to use regular expressions. The default Ingresses for Huddo Boards utilize regex expressions (e.g., /api-boards/?(.*)).
This behavior strongly suggests that the issue arises because the Prefix PathType, under stricter Kubernetes policies, does not allow the use of regex in paths, leading to validation failures or unexpected application behavior. Changing it to ImplementationSpecific bypasses this restriction, enabling the regex patterns to function as intended.
Implying that a modification in a Helm Chart for the Activities Plus application is needed.