democratic-csi / democratic-csi

csi storage for container orchestration systems
MIT License
878 stars 77 forks source link

Status code received from server: 502 (Bad Gateway); malformed header: missing HTTP content-type #306

Closed loeken closed 1 year ago

loeken commented 1 year ago

i am not sure whats wrong i am getting a 502 from my truenas ( TrueNAS-12.0-U8 )

im using democratic-csi version 13.5 ( via helm chart )

I guess this is the responsible section:

      driver:
        config:
          driver: freenas-iscsi
          instance_id:
          logLevel: debug
          httpConnection:
            protocol: http
            host: 10.0.4.115
            port: 80
            username: root
            password: REDACTED
            allowInsecure: true
            apiVersion: 2

these are the errors im seeing:

I0710 21:57:04.254867       1 feature_gate.go:245] feature gates: &{map[]}
I0710 21:57:04.254903       1 csi-provisioner.go:139] Version: v3.1.0
I0710 21:57:04.254910       1 csi-provisioner.go:162] Building kube configs for running in cluster...
I0710 21:57:04.255315       1 connection.go:154] Connecting to unix:///csi-data/csi.sock
I0710 21:57:04.255730       1 common.go:111] Probing CSI driver for readiness
I0710 21:57:04.255737       1 connection.go:183] GRPC call: /csi.v1.Identity/Probe
I0710 21:57:04.255740       1 connection.go:184] GRPC request: {}
I0710 21:57:04.477763       1 connection.go:186] GRPC response: {}
I0710 21:57:04.477823       1 connection.go:187] GRPC error: rpc error: code = Unavailable desc = unexpected HTTP status code received from server: 502 (Bad Gateway); malformed header: missing HTTP content-type
E0710 21:57:04.477847       1 csi-provisioner.go:197] CSI driver probe failed: rpc error: code = Unavailable desc = unexpected HTTP status code received from server: 502 (Bad Gateway); malformed header: missing HTTP content-type

i also attempted to set:

controller:
  driver:
    logLevel: debug

but i dont really understand whats wrong, i can login with that root user, as its root i think it should have the permissions to interact with the api. Any tips how to improve debugs/troubleshoot this is appreciated

travisghansen commented 1 year ago

If you get the logs from the csi-driver container in the pod it will provide better info. I’ve seen this before in the issues but don’t recall exactly what the situation was.

loeken commented 1 year ago

you're a LEGEND

the logs in the csi-driver were pointing at ssh being the problem not the http/api, turns out i havent had ssh autostarting.

thank you sir