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

Volume won't attach because iqn is in an ACL that already exists #154

Open
csallen1204 opened this issue Jan 23, 2020 · 2 comments
Open

Comments

@csallen1204
Copy link

We are using the HPE Left Hand driver and Ember will usually create an ACL on the SAN before mounting to a Kubernetes node to provide access. But it an ACL already exists in the SAN, we'll get this error:

Warning FailedAttachVolume 7s (x6 over 23s) attachdetach-controller AttachVolume.Attach failed for volume "pvc-cd070b5c-e658-45db-92db-2a1dfdfeded6" : rpc error: code = Unknown desc = Exception calling application: Error (HTTP 500) OPERATION_FAILED - The operation failed: The server 'kube17.foo.com' cannot be created because Initiator Node Name 'iqn.2019-12.com.foo.kube17:8692d516cc3' is already in server 'kube17'.

It says it's a warning, but the mount attempt comes to a halt after this happens. Would it be possible to use the existing ACL if the create attempt failed?

@csallen1204
Copy link
Author

Clarification: This seems to only happen when there is another ACL that has the same iqn but a different name i.e. the hostname instead of the fqdn

@Akrog
Copy link
Member

Akrog commented Jan 23, 2020

I think the best solution is to change the "server" name in the LeftHand array from kube17 to kube17.foo.com.

The alternative would be to report a bug in the Cinder project saying what happens and wait and see if someone fixes it (unlikely given the bug) or fix it yourself, then wait until it gets merged in Cinder, and then do a rebuild of Ember-CSI to pick up the new code with the fix.

Looking at the driver code for this we would have to:

  • Parse the response to check if the error is caused by the "server" already existing.
  • Get the "server" name that has the IQN assigned.
  • Query the backend for the "server" information with the parsed server name.

Since this try, fail, retry cycle would happen every time we do an attachment we could use an in-memory dictionary to cache the values for following queries.

Would you be able to rename the "server" in the backend to the node's FQDN?

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

2 participants