Aaron Coburn created VCL-630:
--------------------------------
Summary: currentimage.txt name may conflict with imagerevision
name, causing unnecessary reloads
Key: VCL-630
URL: https://issues.apache.org/jira/browse/VCL-630
Project: VCL
Issue Type: Bug
Components: vcld (backend)
Affects Versions: 2.3
Environment: accessing the first revision of an image on a clustered
(vCenter) VMware host. This only affects images whose name (cleaned of
non-alphanumeric characters) exceeds 29 characters.
Reporter: Aaron Coburn
Assignee: Aaron Coburn
Fix For: 2.4, 2.3.1
A few words to provide some background: when the VCL uses a clustered (vCenter)
VMware host, one cannot simply copy virtual disks as part of the image capture
process; instead, the VM is cloned. This, however, exposed an apparently
undocumented feature of VMware in that virtual disk names exceeding 29
characters are silently truncated. This creates significant problems for the
VCL. The current solution (for 2.3) is to update the image name in the database
after successfully capturing an image. This way, the VCL knows where to find
the virtual disk in the VMware datastore.
The problem with this approach is that this change isn't registered with the
system until after the image has been captured. At this point, however, the
currentimage.txt file has already been written to the disk and if the name
changes ex post facto, then the problem simply re-emerges in a different form
when a user makes a reservation for the image.
Assuming the VM is available and otherwise ready to grant an immediate
reservation, the reclaim.pm:process() subroutine checks the VM name listed in
the currentimage.txt file and finds a conflict in the name listed on the OS and
the name in the database.
An immediate solution for users is to simply make a new revision of the same
image. That second revision will have a shortened name in both currentimage.txt
and the imagerevision table.
There are two ways that this could be correctly solved in the perl code: either
by updating the image name earlier in the provisioning module's capture()
subroutine or by extracting other information from currentimage.txt, such as
imagerevision_id.
While the first approach would be easier to implement, the second approach
seems to be more architecturally sound. That is, rather than relying on a
comparison of two strings, the test would be between two integers, one of which
is the primary key of the database table in question.
Any thoughts on the best way to proceed?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
