[jira] [Commented] (VCL-630) currentimage.txt name may conflict with imagerevision name, causing unnecessary reloads

["Aaron Peeler (JIRA)" <ji...@apache.org>]

    [ 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