Re: status of 2.3 release

2012-04-26 Thread Andy Kurth
I agree that an overall naming convention shouldn't be imposed because of one particular provisioning engine. Your idea of having copy/move_virtual_disk return the name of the destination disk sounds like the best approach. I wouldn't have these subroutines edit the image name in the database, in

Re: status of 2.3 release

2012-04-26 Thread Aaron Coburn
Hi, Andy, > Please feel free to make the changes you described in 1 and 2 to trunk. Will do. > Number 3 is a bit trickier. I'm afraid setting a name length limit in > the database will break other things. > > Is the directory name also truncated or left intact? Example: > /vmfs/volumes/datast

Re: status of 2.3 release

2012-04-26 Thread Andy Kurth
Hi Aaron, Please feel free to make the changes you described in 1 and 2 to trunk. Number 3 is a bit trickier. I'm afraid setting a name length limit in the database will break other things. Is the directory name also truncated or left intact? Example: /vmfs/volumes/datastore/vmwarewin2008-myrea

Re: status of 2.3 release

2012-04-25 Thread Aaron Coburn
I looked through the current code for VCL::Module::Provisioning::VMware::vSphere_SDK 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