This repository has been archived by the owner on Nov 9, 2020. It is now read-only.
[Tenancy] Volume attach/detach should handle inflight membership change of VM to tenant #1045
Comments
pshahzeb
pushed a commit
that referenced
this issue
Mar 21, 2017
1. Update the detach disk flow to detach a disk irrespective of tenant and privilege. Update the attach disk flow to allow unique named volumes to be attached to a VM to ensure no edge cases exists of duplicate entries of disks attached to a VM 2. Send empty list as output to docker volume ls command to forcefully make docker print emtpy list and not the cached volume names 3. Minor print to indicate negative test case and avoid CI output confusion Fixes #990 #1045
pshahzeb
pushed a commit
that referenced
this issue
Mar 21, 2017
1. Update the detach disk flow to detach a disk irrespective of tenant and privilege. 2. Send empty list as output to docker volume ls command to forcefully make docker print emtpy list and not the cached volume names 3. Minor print to indicate negative test case and avoid CI output confusion Fixes #990 #1045
pshahzeb
pushed a commit
that referenced
this issue
Mar 30, 2017
1. Disallowing tenant-vm membership change when volumes are mounted and in use by VMs 2. Send empty list as output to docker volume ls command to forcefully make docker print emtpy list and not the cached volume names 3. Minor print to indicate negative test case and avoid CI output confusion Fixes #990 #1045
pshahzeb
pushed a commit
that referenced
this issue
Mar 31, 2017
* Handling tenancy related edge cases 1. Disallowing tenant-vm membership change when volumes are mounted and in use by VMs 2. Send empty list as output to docker volume ls command to forcefully make docker print emtpy list and not the cached volume names 3. Minor print to indicate negative test case and avoid CI output confusion Fixes #990 #1045
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Change of membership(which tenant a VM belongs to) after a volume as been attached but before detach makes the volume detach logic fail. The reason being tenant not found (if tenant is deleted and even default tenant doesn't exist) or vmdk not found if tenant is changed(vmdk is now searched in new tenant uuid directory).
The fix is to only match datastore path and vmdk name and ignore tenant name against the volumes that has been attached to the VM to allow smooth detach.
There can be a theoretical corner case where volumes of same name exist across 2 (or may be more) tenants, and while a container is running and say vol1 from tenant 1 is attached; and admin moves the VM from tenant 1 to tenant 2 and tries to mount vol1 from tenant 2 to the same container.
In this case, the above detach logic will fail.
To avoid this we restrict the attach to allow unique volume names to be mounted. This means, in the above example, the second mount (vol1 from tenant 2) will fail; of course with appropriate message.
The text was updated successfully, but these errors were encountered: