Use shared lock on disks for dependent VMs #178
Conversation
bennyz
force-pushed
the
concurrent-transfer-template
branch
from
b78fb50
to
dcd3b39
Compare
bennyz
force-pushed
the
concurrent-transfer-template
branch
2 times, most recently
from
9f07f39
to
7b42770
Compare
The check to see if a template image is being used is pretty complicated, extract it to a method, isTemplateBeingUsed(). Signed-off-by: Benny Zlotnik <bzlotnik@redhat.com>
bennyz
force-pushed
the
concurrent-transfer-template
branch
from
7b42770
to
945fe00
Compare
|
/ost |
bennyz
force-pushed
the
concurrent-transfer-template
branch
from
945fe00
to
724c9e1
Compare
|
/ost |
bennyz
changed the title
|
seems to be failing |
@michalskrivanek |
|
in 945fe00 so now it's good! |
ahadas
changed the title
|
|
||
| if (!Guid.isNullOrEmpty(getParameters().getImageId()) || | ||
| getDiskImage() != null && | ||
| !isThinTemplate(getDiskImage())) { |
There was a problem hiding this comment.
so now if we download a disk of a vm that is set with thin-provisioning, we won't lock the vm? something is suspicious here
There was a problem hiding this comment.
yeah... it's probably not needed
| if (getDiskImage() != null) { | ||
|
|
||
| // If the disk is a thin template overlay we only lock with a shared lock | ||
| if (getDiskImage() != null && !isThinTemplate(getDiskImage())) { |
There was a problem hiding this comment.
what's the reason for not locking cloned disks also with shared locks?
There was a problem hiding this comment.
cloned disks have a different id, no? they should be affected by this
There was a problem hiding this comment.
yes, we generate a different ID from them but regardless of this issue - if all we care of is that the disk is not removed or moved or converted (and such) then we don't have to create an exclusive lock for the disks at all
another way to think about it is to say exclusive locks = write locks and shared locks = read locks (although it's not always true with our engine locks) so if all we do when downloading a disk is read them, then a shared lock seems be more appropriate
There was a problem hiding this comment.
ah ok, I thought the comment was about an issue... I definitely agree there is no reason to use an exclusive lock here
There was a problem hiding this comment.
actually, there is one reason - this command is used for upload too :)
bennyz
force-pushed
the
concurrent-transfer-template
branch
2 times, most recently
from
6607a2a
to
b5f9d38
Compare
| if (!Guid.isNullOrEmpty(getParameters().getImageId()) && getDiskImage() != null) { | ||
|
|
||
| if (!Guid.isNullOrEmpty(getParameters().getImageId()) || | ||
| getDiskImage() != null) { |
There was a problem hiding this comment.
do we need this change? (we have to check getDiskImage() != null, otherwise we'll get NPE in the following line)
There was a problem hiding this comment.
nope, leftover from previous change
When downloading a disk that is an overlay of a template, take only a shared lock on the disk and skip the locked disk validation, this would allow downloading disks of thin VMs without failing on the disk being locked. Bug-Url: Bug-Url: https://bugzilla.redhat.com/1879391 Signed-off-by: Benny Zlotnik <bzlotnik@redhat.com>
bennyz
force-pushed
the
concurrent-transfer-template
branch
from
b5f9d38
to
4c3ab00
Compare
|
/ost |
When downloading a disk that is an overlay of a template, take only a shared lock on the disk and skip the locked disk validation, this would allow downloading disks of thin VMs without failing on the disk being locked