Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support For Non Root Path Hosting #94

Open
rovermicrover opened this issue Aug 3, 2023 · 21 comments
Open

Support For Non Root Path Hosting #94

rovermicrover opened this issue Aug 3, 2023 · 21 comments

Comments

@rovermicrover
Copy link

The dashboard expects Qdrant to be hosted at the root of a domain otherwise it breaks. Our clusters work by hosting each service, or which Qdrant is one, on the same domain each with their own sub path. So for instance www.foo.com/qdrant.

@generall
Copy link
Member

Should be fixed with #113

@timvisee
Copy link
Member

Closing this because we believe this is fixed in Qdrant v1.5.1. Please feel free to open this again if the issue persists.

@matteosdocsity
Copy link

matteosdocsity commented Sep 13, 2023

@timvisee exposing Qdrant via Nginx with
location /qdrant { proxy_pass http://qdrant:6333/; proxy_set_header Host $http_host; proxy_redirect off; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_set_header api-key $http_api_key; }

nothing has changed, my_host/qdrant/dashboard responds 404, while my_host/qdrant and all rests API are ok, as they were before the 1.5.1

@timvisee
Copy link
Member

@timvisee exposing Qdrant via Nginx with location /qdrant { proxy_pass http://qdrant:6333/; proxy_set_header Host $http_host; proxy_redirect off; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_set_header api-key $http_api_key; }

nothing has changed, my_host/qdrant/dashboard responds 404, while my_host/qdrant and all rests API are ok, as they were before the 1.5.1

You are correct.

I tried to reproduce this, and yes, the dashboard fails to load. It wrongly tries to load assets from the root path.

By the way, I believe that your Nginx snippet is wrong and that it should be something like the snippet below. But even then, the dashboard would still be unusable.

location ~ ^/qdrant/(.*) {
    proxy_pass http://127.0.0.1:6333/$1?$args;
    proxy_redirect off;
    proxy_http_version 1.1;
}

@Formartha
Copy link

Any solution for this? I'm unable to work behind ngnix as well..

@timvisee
Copy link
Member

timvisee commented Mar 4, 2024

Any solution for this? I'm unable to work behind ngnix as well..

Could you elaborate why?

@Formartha
Copy link

Sure.
Using NGNIX with docker compose dons't allow me to open the dashboard UI. The code is in this project: https://github.com/Formartha/ai1899

The exact affected files are:

@JosuaKrause
Copy link

JosuaKrause commented Mar 18, 2024

the fix (getting the base url from window.location) above only works on the js part (and only if the js was already loaded successfully). but the initial load of dashboard/ contains all absolute URLs in the HTML (e.g., /dashboard/assets/index-99eb787e.js) which makes the dashboard try to access https://myurl.com/dashboard/assets/index-99eb787e.js instead of e.g., https://myurl.com/qdrant/dashboard/assets/index-99eb787e.js (if the subpath is qdrant). So the js cannot get loaded in the first place.

Is there a solution to this?

@fedecompa
Copy link

I have the same problem. I want to expose the dashboard of the first node of the cluster behind Traefik, for example with the following route:

traefik.http.routers.qdrant-http.rule: "Host(server.name) && PathPrefix(/qdrant-test)"

But I can't do that, since the qdrant dashboard does not support an enviroment variable for the base_path=qdrant-test.

So I'm forced to do something like this:

traefik.http.routers.qdrant-http.rule: "Host(server.name) && PathPrefix(/qdrant,/cluster,/dashboard,/collections,/telemetry)"

traefik.http.middlewares.qdrant_sp.stripprefix.prefixes: "/qdrant"

And if I want to expose more instances of qdrant behind the same reverse proxy I'm forced to use different "server.name" for the Host.

@JosuaKrause
Copy link

I agree, an env variable would be great for this

@shaileshj2803
Copy link

Can we please have a fix for this?

@viniciusraupp
Copy link

I have same problem, without solution.

@metalshanked
Copy link

same issue here

@oddFEELING
Copy link

Same problem here. I have 2 services with my server routed to root page and qdrant routed to /qdrant/ using reverse proxy on nginx. API seems to work but the dashboard won't come up (Shows white blank page) . Tried messing with the config on https://qdrant.tech/documentation/guides/configuration/ but no result. Anyone done this before?

@oddFEELING
Copy link

Sure. Using NGNIX with docker compose dons't allow me to open the dashboard UI. The code is in this project: https://github.com/Formartha/ai1899

The exact affected files are:

* https://github.com/Formartha/ai1899/blob/main/docker-compose.yaml

* https://github.com/Formartha/ai1899/blob/main/nginx.conf

Checked your repo now, the image i am using for qdrant is qdrant/qdrant, does the current image you pull from solve this issue? it's been a few months since the issue, what is your walk around?

@Enolerobotti
Copy link

Same problem on kubernetes ingress-nginx. As a walk around I had to create an additional ingress object to provide paths to /dashboard, /issues, /collections and /telemetry. Similar to the @fedecompa 's solution (BTW, thanks!). Now I can access dashboard on both myhost.com/dashboard and myhost.com/qdrant/dashboard. There is a drawback indeed. We cannot serve more than one instance on one host.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/rewrite-target: /$2
  labels:
    app: qdrant
  name: qdrant
  namespace: qdrant
spec:
  rules:
  - host: myhost.com
    http:
      paths:
      - backend:
          service:
            name: qdrant
            port:
              number: 6333
        path: /qdrant(/|$)(.*)
        pathType: ImplementationSpecific

---

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: qdrant-dashboard
  namespace: qdrant
  labels:
    app: qdrant
  annotations:
    kubernetes.io/ingress.class: nginx
spec:
  ingressClassName: nginx
  rules:
    - host: myhost.com
      http:
        paths:
          - pathType: Prefix
            backend:
              service:
                name: qdrant
                port:
                  number: 6333
            path: /dashboard
          - pathType: Prefix
            backend:
              service:
                name: qdrant
                port:
                  number: 6333
            path: /issues
          - pathType: Prefix
            backend:
              service:
                name: qdrant
                port:
                  number: 6333
            path: /collections
          - pathType: Prefix
            backend:
              service:
                name: qdrant
                port:
                  number: 6333
            path: /telemetry

@prd-tuong-nguyen
Copy link

same problem

@PylotLight
Copy link

PylotLight commented Oct 15, 2024

We are also having this issue still at work where we are hosting qdrant and the assets are not able to be loaded correctly when using a istio virtualservice.
Is there a workaround/fix for rewriting the uri's here?

@pleomax0730
Copy link

same problem

@PylotLight
Copy link

PylotLight commented Oct 28, 2024

I've solved this by building from source myself using:
bun --bun run build-qdrant --base '/subpath1/subpath2/dashboard/'
bun --bun run build
This then uses './' path for assets which seems to work.
Then I can package this and build qdrant from source with updated frontend.

The above works for assets, BUT:

  • Collections page api expects root path and ignores my custom pathing
  • Quickstart run items uses pull subpath where it should be different from assets/dashboard

@fedecompa
Copy link

Of course, I don't understand why the qdrant team hasn't implemented this simple fix yet

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests