-
Notifications
You must be signed in to change notification settings - Fork 102
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
Topology awareness: CSI Controller creates volumes in its own location #42
Comments
Looks like we need to release a new version of the driver for Kubernetes 1.14 where |
I have another issue down the line which might share a root cause. When trying to use the CSI driver on a 1.14 cluster with
I suspect this might be related, because the call to create the |
@bascht could you please try the new deploy YAML at #43 ? @thcyron please correct me if I'm mistaken, but doesn't the k8s builtin node manager create the |
@costela Looking good: the corresponding storage class is created:
And after applying my test Yaml - all volumes bound:
all neat in their respective locations: @costela Thanks a bunch for the quick update! <3 Should I keep this issue open for the followup? |
@bascht nice to hear! |
This is a followup of my comment in #11. I can reproduce the behaviour with
hetznercloud/hcloud-csi-driver:1.1.4
on Kubernetes v1.14.3.The CSI controller is deployed on a node located in
fsn1
:I used the following config to create 3 deployments of 1 pod each in
fsn1
,nbg1
andhel1
:Only
fsn1
will actually start:Checking for example the hel1 pod:
Checking via the hcloud cli shows the volumes in
fsn1
:And it looks like we are already on to something – if I check the csi-provisioner log, I found
the server could not find the requested resource (get csinodeinfos.csi.storage.k8s.io k8s-infrastructure-web-1
:Without into digging the code I am not sure what triggers the error, do you have any hints how I could debug this any further?
The text was updated successfully, but these errors were encountered: