I looked through the current code for 

For the most part, all of the code I submitted for the vCenter module has been 
integrated into vSphere_SDK class.

There are three exceptions, which I didn't see in the current code:

1. in the move_virtual_disk subroutine, you use the MoveVirtualDisk vSphere 
method. This works fine on esx hosts, but in the context of a vCenter, it will 
return a "not implemented" fault. I liked how this was handled in the 
copy_virtual_disk subroutine: first try the method that makes sense and then 
fall back to using the full 'CloneVM' approach if the first method doesn't 
work. The way I had implemented this, move_virtual_disk just uses the 
copy_virtual_disk method and then deletes the source files upon successful 
completion. I can add that code if you would like.

2. in the copy_file_to and copy_file_from subroutines, I needed to add a loop 
because the VIExt::http_put_file and VIExt::http_get_file functions 
periodically fail. That is, if copy_file_to fails, the code sleeps for a few 
seconds and tries again, up to a maximum of a few tries. From what I can tell, 
this sort of looping doesn't exist when prepare_vmx() is called. I can wrap 
that in a Module::code_loop_timeout subroutine, if you would like.

3. When vCenter clones a VM with the CloneVM method, it will silently truncate 
long vm names. This isn't necessarily a problem as long as that new name finds 
its way into the database; otherwise, however, when VMX files are generated, 
the vmdk file pointers will reference incorrect locations. I had solved this by 
enforcing a maximum length in the web code (i.e. the vcl.image.name table). 
There are pros and cons to this, though a better approach may be to retrieve 
the actual name of the vmdk file after a clone operation is performed. This 
would require having the copy_virtual_disk and move_virtual_disk to return 
values other than just 1 (or, those methods could update the database 
themselves). I am not sure which approach you would prefer. I am also unsure of 
the best way to update the database with this information: would I simply call 
database_execute(...) and then call $self->data->refresh()? Or is there other 
code that handles this type of operation? Please advise.


On Apr 25, 2012, at 10:28 AM, Josh Thompson wrote:

> Hash: SHA1
> I think we targeted April to get a release out.  The number of JIRA issues we 
> have left is starting to go down a fair amount.  I'm almost finished with the 
> frontend.  How's the backend?  Are there other things we'd like to do for 
> this 
> release such as scripting the install as much as possible?  I don't think 
> we'll be done by the end of April, but I think the first week of May would be 
> possible.
> Aaron C., Jim, and David - Have you tested your provisioning modules with 
> recent code from subversion?  If not, do you think you can do that in the 
> next 
> week or two?
> Josh
> - -- 
> - -------------------------------
> Josh Thompson
> VCL Developer
> North Carolina State University
> my GPG/PGP key can be found at pgp.mit.edu
> 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.
> Version: GnuPG v2.0.17 (GNU/Linux)
> KJIAn1mxEVtuZ64KEG0I4AwosUo3qT2P
> =InjJ

Reply via email to