For 2.3.1, the only thing that was changed regarding this issue is that the name in the database is only changed during image capture. I had inadvertently left the calls to _clean_vm_name commented out in trunk and just fixed this. This was done when adding the feature allowing you to specify the VM folder path -- changes not merged into bugfix.
Only changing the image name during image capture isn't a perfect fix. It was done to prevent existing images from breaking on all hosts which already had a copy of the image after the image was copied once on a host controlled by vSphere_SDK.pm. There shouldn't be a problem if all hosts in the environment are controlled by vSphere_SDK.pm. There also shouldn't be any problems for mixed vSphere_SDK.pm/non-vSphere_SDK.pm environments for images captured on hosts controlled by vSphere_SDK.pm. The name will be shortened in the database and image files. There will be problems loading an image on a vCenter host if the following conditions are true: -Mixed vSphere_SDK.pm/non-vSphere_SDK.pm environment with some vCenter hosts -Image captured on host not controlled by vSphere_SDK.pm -Image has long name Although not perfect, I thought this would cause fewer problems than before. A more elaborate solution can be applied. I didn't delve into this for the bugfix release because the problem affects a small number of environments, but I was thinking of having the code get the long name from the database and then check if files with either the long or shortened name exist in the datastore during load. Also, this may be less of an issue for vCenter 5.x. The name limit seems to have been increased to 80 characters. -Andy On Thu, Dec 13, 2012 at 5:46 PM, Aaron Coburn <[email protected]> wrote: > +0 > > (with some reservations noted here: > https://issues.apache.org/jira/browse/VCL-630) > > In 2.3.1 one can capture an image with a long name ($destination_base_name > has more than 29 characters), but it is not possible to load it, since the > name of the vmdk file differs from what is recorded in the database. > > I don't think this is a show-stopper of an issue, but it will cause some > pain for those using vCenter. > > Otherwise, the release looks good. > > > -- > Aaron Coburn > Systems Administrator and Programmer > Academic Technology Services, Amherst College > [email protected]<mailto:[email protected]> > > > > > > > On Dec 13, 2012, at 4:51 PM, Josh Thompson <[email protected]<mailto: > [email protected]>> wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Here's my vote. > > +1 > > On Thursday, December 13, 2012 3:02:08 PM you wrote: > All of the JIRA issues associated with 2.3.1 are now resolved. Here is our > first try at voting to release 2.3.1. > > I created a release artifact based off of the 2.3 bugfixes branch. I > copied > that branch to a tag under the tags area of the repo that is named > release-2.3.1-RC1: > > http://svn.apache.org/repos/asf/vcl/tags/release-2.3.1-RC1/ > > The artifact is an export from that tag with the addition of Dojo Toolkit > version 1.6.1 with a custom VCL profile bundled in the web code. The > artifact, MD5 and SHA1 sums, and my GPG signature of it are available from > my space on people.a.o: > > http://people.apache.org/~jfthomps/apache-VCL-2.3.1-RC1/ > > The list of resolved JIRA issues associated with this release can be found > under 2.3.1 on the Change Log page in the staging area of the CMS: > > http://vcl.staging.apache.org/docs/changelog.html > > Installation instructions are in the INSTALLATION file included in the > artifact and in the staging area of the CMS: > > http://vcl.staging.apache.org/docs/VCL231InstallGuide.html > > I was able to successfully do test installs and upgrades, including image > deploying and capture. > > The directory created by extracting the RC1 artifact is > "apache-VCL-2.3.1-RC1" (after extracting, you may want to rename it to > "apache-VCL-2.3" so you can copy and paste all of the commands in the > installation guide). Licensing information about perl and its required > modules, php and its required modules, and mysql are stated as "system > requirements" according to the information under "System Requirements" on > http://www.apache.org/legal/3party.html. > After we finalize a release vote, the staging part of the CMS will be > published to update the production site. > > Please vote by the end of the day on Tuesday, December 18th to publish this > release (this allows for 3 business days to vote). Please note that anyone > in the VCL community is allowed to vote. > > [ ] +1 yes, release VCL 2.3.1 > [ ] 0 dunno > [ ] -1 no, don't release VCL 2.3.1 (provide reasons if this is your vote) > > 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. > - -- > - ------------------------------- > Josh Thompson > VCL Developer > North Carolina State University > > my GPG/PGP key can be found at pgp.mit.edu<http://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. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.19 (GNU/Linux) > > iEYEARECAAYFAlDKTfIACgkQV/LQcNdtPQNjewCffzBPvHTXyXdp4je4B1ldHYl0 > PWgAnAtzlrnKg4brR2D2/ei4dsZF8Edv > =7hYm > -----END PGP SIGNATURE----- > > >
