How to configure the app and Ingress with different base path

[fahlke]

Describe the bug

When installing WEGO with the Helm chart, I want to expose the WebUI for local development and testing via an ingress under a different path than / (e.g.: /wego).

Currently, as far as I can see, there is no parameter or ENV var exposed to configure the application to make use of it. The only thing that is possible, is to configure the ingress resource via the Helm chart, which does not function when set to something different than /.

Also figured out, that there is actually a path parameter for the application that seems to be dead code. One can start the app with, for example, --path=/wego with no effect at all (see: cmd/gitops-server/cmd/cmd.go#L84).

Some other Helm charts correctly configure the application and ingress by allowing the user to change the path and route prefix. This is something I did in my local cluster with, for example, the kube-prometheus-stack and it is working as expected (apps are reachable via the ingress). This can be achieved by setting prometheus.prometheusSpec.routePrefix and prometheus.ingress.paths.

Environment

• Operating System: MacOS 12.4
• Weave-Gitops Helm chart version: 2.2.5
• Weave-Gitops app version: v0.9.1
• Flux Version: 0.31.5
• Kubernetes: v1.21.12 (kind, running local)
• Kong (for ingress): 2.8

To Reproduce
Steps to reproduce the behavior:

1. have a local Kind cluster running with Kong as ingress controller
2. get the Helm charts

   helm repo add weave https://helm.gitops.weave.works
   helm repo update weave
   

3. deploy WEGO with the helm chart

   helm upgrade weaveworks-gitops weave/weave-gitops \
     --install \
     -n flux-system \
     -f values.yaml  # see the values that were used below in "Additional Context"
   

4. verify the app is running

   kubectl get deploy -n flux-system -l='app.kubernetes.io/name=weave-gitops'
   

5. try to open the website in a browser or use curl

   curl -I http://localhost/wego
   

6. wait for the backend timeout (with HTTP/1.1 504 Gateway Time-out).
7. now try it with port-forwarding and do the curl again (expected response HTTP/1.1 200 OK)

   kubectl port-forward service/weaveworks-gitops-weave-gitops -n flux-system 9001:9001
   curl -I http://localhost:9001/wego
   

Expected behavior

When ingress path is set to /wego the website should be reachable.

Actual Behavior

The website is not reachable and the requests time out.

Additional Context (screenshots, logs, etc)

Values used to deploy WEGO via the Helm chart:

adminUser:
  create: true
  username: admin
  # htpasswd -bnBC 10 "" 'CHANGEME' | tr -d ':\n' | sed 's/$2y/$2a/'
  passwordHash: <use the result from the command above>
ingress:
  enabled: true
  className: kong
  hosts:
  - host: localhost
    paths:
    - path: /wego
      pathType: ImplementationSpecific

Alternative values used (with annotations for Kong to modify the requests):

adminUser:
  create: true
  username: admin
  # htpasswd -bnBC 10 "" 'CHANGEME' | tr -d ':\n' | sed 's/$2y/$2a/'
  passwordHash: <use the result from the command above>
ingress:
  enabled: true
  annotations:
    konghq.com/preserve-host: "true"
    konghq.com/strip-path: "true"
  className: kong
  hosts:
  - host: localhost
    paths:
    - path: /wego
      pathType: ImplementationSpecific

[kaybinwang]

Just ran into this issue when setting up the dashboard under a subpath too. Are there any plans to prioritize fixing the issue?

Happy to help contribute if it's a relatively straightforward solution and if I could get some code pointers.

[opudrovs]

@kaybinwang thank you for your offer of help!

Unfortunately, this issue is not straightforward because of the way the app is currently set up. We researched this issue earlier: configuring the backend part is not a problem, the issue is that the frontend is generated as static files and is not configurable enough to make "the app and Ingress with different base path" with the current app setup.

So, this issue will require more bandwidth for deeper research and a major rework, which we don't have right now. We'll get back to it when we have more bandwidth. We know that our users are interested in this functionality, and we keep this in our priority backlog.

[danielkimuipath]

Is there an update on this?

[opudrovs]

@danielkimuipath we are planning a major architectural rework of our products in the near future (hopefully, 1-2 months).

With the current architecture, there are technical limitations for implementing functionality requested in the current issue.

So, after we are done with the rework we'll revisit this issue.

[guilhermegouveiahr]

@kaybinwang thank you for your offer of help!

Unfortunately, this issue is not straightforward because of the way the app is currently set up. We researched this issue earlier: configuring the backend part is not a problem, the issue is that the frontend is generated as static files and is not configurable enough to make "the app and Ingress with different base path" with the current app setup.

So, this issue will require more bandwidth for deeper research and a major rework, which we don't have right now. We'll get back to it when we have more bandwidth. We know that our users are interested in this functionality, and we keep this in our priority backlog.

Waiting eagerly for this new feature.
Still can't provide access to my users from the internet.
They have to port-forward., because the main path is already occupied and the company won't allow another DNS.