EFS can't be mounted in 0.6.0

[mhrabovcin]

Trying to mount EFS volume by its name doesn't work in 0.6.0. Mounting works with version built manually before this commit - c68e7d7

[kasisnu]

Some more debugging info:

[root@ip-10-0-0-4 ~]# ./rexray version
REX-Ray
-------
Binary: /root/rexray
SemVer: 0.6.0
OsArch: Linux-x86_64
Branch: v0.6.0
Commit: 429cfdf7272cebc5911b2865128ad37a6da5a203
Formed: Fri, 21 Oct 2016 02:06:45 UTC

libStorage
----------
SemVer: 0.3.1
OsArch: Linux-x86_64
Branch: v0.6.0
Commit: a3a561a1b94bb8b7efb4ae998540c457deb39692
Formed: Fri, 21 Oct 2016 02:05:09 UTC

[root@ip-10-0-0-4 ~]# ./rexray volume ls
ID           Name       Status     Size
fs-53ad791a  wutututut  available  6144


[root@ip-10-0-0-4 ~]# ./rexray volume mount wutututut --service efs
FATA[0000] no volumes found

[root@ip-10-0-0-4 ~]# ./rexray volume mount fs-53ad791a --service efs
FATA[0000] no volumes found

With http response logging enabled, we've confirmed volumes are being returned by the libstorage client

e=objectivefs storageDriver=libstorage time=1477475869228 txCR=1477475869 txID=80697ee2-949c-4749-7d12-85b797132905
DEBU[0000] xli localdevices success                      host=tcp://127.0.0.1:7979 instanceID=efs=subnet-1a1b9753 integrationDriver=docker osDriver=linux server=zest-braid-na servic
e=objectivefs storageDriver=libstorage time=1477475869228 txCR=1477475869 txID=80697ee2-949c-4749-7d12-85b797132905
INFO[0000]
INFO[0000]     -------------------------- HTTP RESPONSE (CLIENT) -------------------------
INFO[0000]     HTTP/1.1 200 OK
INFO[0000]     Content-Length: 109
INFO[0000]     Content-Type: application/json
INFO[0000]     Date: Wed, 26 Oct 2016 09:57:49 GMT
INFO[0000]     Libstorage-Servername: zest-braid-na
INFO[0000]
INFO[0000]     {
INFO[0000]       "fs-53ad791a": {
INFO[0000]         "name": "wutututut",
INFO[0000]         "size": 6144,
INFO[0000]         "id": "fs-53ad791a",
INFO[0000]         "type": ""
INFO[0000]       }
INFO[0000]     }
FATA[0000] no volumes found```

[akutz]

Hi @mhrabovcin and @kasisnu,

I am looking at this today. Thanks!

[akutz]

Hi @mhrabovcin / @kasisnu (cc @cduchesne),

Okay, so the issue is a "protection" I added to the RR mount command. It asserts a volume should be attached prior to being mounted. Obviously I need to reexamine that assertion for NFS providers.

However, I'm running into an additional issue. I'm now attempting to attach the EFS volume and getting an error about an invalid security ID.

According to the EFS driver docs if no security groups are specified the default VPC should be used. So shouldn't things work without an explicit security group list?

[akutz]

Okay guys, I have it working. It will require an update to REX-Ray if I want to continue to use a volume's attached status to determine whether or not it can be mounted. Currently the volume query to match volume names/IDs for mutative ops does not request attachment data. For EBS it was always sent regardless, so I didn't encounter the bug. I updated the RR code on an EC2 instance and it works with EFS just fine now.

Showing as Attached

[root@ip-172-31-25-144 rexray]$ rexray -l error volume ls --service efs
ID           Name    Status    Size
fs-03ec16aa  builds  attached  6144

Mounting

[root@ip-172-31-25-144 rexray]$ rexray -l error volume mount builds --service efs
ID           Name    Status    Size  Path
fs-03ec16aa  builds  attached  6144  /var/lib/rexray/volumes/builds/data

[akutz]

So what does everyone think -- should we continue to determine if a volume can be mounted/unmounted/attached/detached/etc. based on whether it is attached already or not? And if so, should we just go ahead and always return attachment data par for the course? Meaning the RR CLI will always send the attachments=true flag?