Let the user define their preferred "ingress.spec.rules.host.http.paths.backend.path" value for ingress resources created by the chart.
Summary
The problem is that with the ingress-controller of my kubernetes cluster the path field in the ingress definition is treated as an exact match, while the webservice application does a redirect when targeting the root path ("/").
Steps to reproduce
- install in the cluster an ingress-controller that doesn't have an option for understanding prefixes for path matches.
- install the chart normally as described in the gitlab chart documentation just avoiding the nginx-controller installation.
- open a browser at the host name defined in the chart values file.
- you should get your default-backend or an error page from the controller. This is due to the fact that the first request to "/" that passes through the ingress has been redirected to "/users/sign_in" and the controller can't route the request to the good pod.
Configuration used
global:
hosts:
domain: example.com
ingress:
configureCertmanager: false
class: nsx #I'm using a controller that is not nginx in my cluster.
gitlab-exporter:
enabled: false
appConfig:
backups:
bucket: gitlab-backups
tmpBucket: tmp
rails:
bootsnap:
enabled: false
gitlab:
gitlab-exporter:
enabled: false
task-runner:
backups:
objectStorage:
config:
secret: s3cmd-secret
key: config
certmanager:
install: false
registry:
enabled: false
gitlab-runner:
install: false
prometheus:
install: false
nginx-ingress:
enabled: false
minio:
enabled: false
Current behavior
ingress.spec.rules.host.http.paths.backend.path is not configurable and match exact "/" root path. The webservice redirect the request to "/users/sign_in" and the controller can't match anymore the new request ending with no frontend showed.
Expected behavior
I'm expecting to have the possibility to configure the ingress.path field, so that I could choose to use a regexp for path matching.
Possible approaches for solution
A)Let the user configure the "ingress.spec.rules.host.http.paths.backend.path" field so that a regex could be used instead, i.e. "/*". With this configuration, if the ingress controller supports regexp matches, it would be feasible to adapt the chart for different controllers.
B) Starting from kubernetes version 1.18 it is possible to avoid this type of issue thanks to the new defined field pathType for ingress definitions. With this field set it is possible to explicitly tell the controller that the path is a prefix. the only issue with the solution of adding a default pathType field would be retro-compatibility since this is not supported prior than version 1.18.
C) completely remove the field. I don't know if this could have some side-effects but I could test that it works for my configuration.
Versions
- Chart: gitlab-4.4.4
- Platform:
- Self-hosted: PKS
- Kubernetes:
- Client: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.7", GitCommit:"b4455102ef392bf7d594ef96b97a4caa79d729d9", GitTreeState:"clean", BuildDate:"2020-06-17T11:39:47Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"linux/amd64"}
- Server: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.8+vmware.1", GitCommit:"3cbbcf0977af5f3cf455115d060b081f2b8e2329", GitTreeState:"clean", BuildDate:"2020-06-29T22:33:24Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"linux/amd64"}
- Helm: (
helm version
)- Client: version.BuildInfo{Version:"v3.3.4", GitCommit:"a61ce5633af99708171414353ed49547cf05013d", GitTreeState:"clean", GoVersion:"go1.14.9"}