[
https://issues.apache.org/jira/browse/VCL-630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13460459#comment-13460459
]
Aaron Peeler commented on VCL-630:
----------------------------------
I vote using the imagerevision_id. There are other areas where imagerevision_id
would be best, such as in the healthcheck.pm, etc. I would also recommend to
redo _getcurrentimage or create a new getcurrentimage routine that's not
dependent on the Datastructure. I've almost started reworking that routine
related to the healthcheck code.
> 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
