I can work on this one. My thoughts to proceed, first convert OS.pm:sub get_currentimage_txt_contents to return a hash of the contents of currentimage.txt then update anything that currently depends on it which I think is only OS.pm:sub get_current_image_name
Update get_current_image_name to return optional values, imageid, imagerevision_id, imagename, etc. The default would be imagerevision_id. Then in update any provisioning modules node_status routine to start using $self->os->get_current_image_name() based on the desired return value, then node_status or other routines can then compare what is loaded vs what is requested. and lastest remove the old utils::_getcurrentimage routine This would allow for changes in the name like shorter and less strict naming of the internal imagenames. Thoughts or comments before I proceed? Aaron P. On Fri, Sep 21, 2012 at 11:07 AM, Aaron Peeler (JIRA) <[email protected]> wrote: > > [ > https://issues.apache.org/jira/browse/VCL-630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13460545#comment-13460545 > ] > > Aaron Peeler commented on VCL-630: > ---------------------------------- > > follow-up - there is a get_currentimage_txt_contents in the OS.pm module > already. I think the best path would be to create a > OS::get_currentimage_imagerevision_id routine which parses the contents and > returns the imagerevisionid on the loaded node. Then update the provisioning > module's node_status routines to use this instead. > >> 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 -- Aaron Peeler Program Manager Virtual Computing Lab NC State University All electronic mail messages in connection with State business which are sent to or received by this account are subject to the NC Public Records Law and may be disclosed to third parties.
