Khosrow,
Your argument about the ability to have a given name be used as the final artifact name is not correct for prior 4.11 versions, as that only was a specific case/condition for systemvm template to copy/rename and then use an existing definition, and not with rest of the veewee definitions that existed in the folder. Even if the name of the folder was systemvm64template, you build job may still fail due to the build process and tool/environment changes. Finally, you can always rename the build artifacts. The issue IMO is with your build job and not the current build scripts. The README file already mentions what arguments can be used to build templates but can indeed get some improvements: https://github.com/apache/cloudstack/blob/master/tools/appliance/README.md Both your suggestions are okay with me, you may improve the README or send a PR that modifies the build.sh script to handle exporting appliances to custom name (but as a general option, not specific to systemvmtemplate). - Rohit <https://cloudstack.apache.org> ________________________________ From: Khosrow Moossavi <kmooss...@cloudops.com> Sent: Monday, February 19, 2018 3:07:41 AM To: dev@cloudstack.apache.org Subject: Re: Potential backward incompatibility problem in building SystemVM Daan, Rohit With the new packer build (4.11+) one cannot give "blah" to be the final name of the template. The script will look for a folder called "blah" in appliance folder which does not exist. But in before packer (prior to 4.11) one can give "blah" to be the final name, because the script would copy "definition" to "blah" folder and continue the script. In our own case, for instance, we needed to change the Jenkins script because it was failing with "systemvm64template" as the name on 4.11.0.1. So I guess my point is either 1) we need to change the script to still handle custom name, 2) have this documented somewhere (applicane/README may be) that the only accepted name will be "systemvmtemplate". Minor change either way. On Sat, Feb 17, 2018 at 2:30 PM, Rohit Yadav <rohit.ya...@shapeblue.com> wrote: > Khosrow, > > > The name 'systemvmtemplate' refers to the name of the folder, the build.sh > script now accepts a folder that has the packer definitions such as the > built-in one or any other future packer based templates. The systemvm > template's file name is never used for compatibilities sake, one can choose > whatever name they want and they will be used okay as long as that name is > correctly configured in the global settings. I don't understand the bit > about name/compatbility. > > > Historically, we used to a 32bit template with its definition defined in > systemvmtemplate and then we moved to 64-bit template with introduction of > definitions in systemvm64template folder, and when we did that we added > that constraint to remove and rename folders while are not needed/useful > anymore. > > > Wrt building it's not backward compatible as well, the build process has > been changed from virtualbox+veewee/ruby based to packer+qemu/kvm based so > the old script/jobs are broken as well. > > > - Rohit > > <https://cloudstack.apache.org> > > > > ________________________________ > From: Khosrow Moossavi <kmooss...@cloudops.com> > Sent: Friday, February 16, 2018 5:58:59 PM > To: dev@cloudstack.apache.org > Subject: Potential backward incompatibility problem in building SystemVM > > Hi > > I just noticed that the changes [1] in tools/applince/build.sh may break > backward compatibility > of the building process of systemvmtremplate. > > In the highlighted (and now removed) line, we used to have a predefined > name as "systemvm64template" > and if one still wants to execute "build.sh systemvm64template ..." (or any > other name they > want) the build will break (becauase of the now new if condition). > > Was this intentional to always have a new "systemvmtemplate" as the name or > the new if > condition should be fixed? Super simple to fix anyway. > > if [ "systemvmtemplate" != "${appliance_build_name}" ]; then > > instead of: > > if [ "${appliance}" != "${appliance_build_name}" ]; then > > > [1] > https://github.com/apache/cloudstack/commit/3839239a21fc14a64acc18900ae303 > 961036ef91#diff-68ae31f5f30dae8f541e26b8acbd75eeL247 > > Khosrow Moossavi > CloudOps > > rohit.ya...@shapeblue.com > www.shapeblue.com<http://www.shapeblue.com> > 53 Chandos Place, Covent Garden, London WC2N 4HSUK > @shapeblue > > > > rohit.ya...@shapeblue.com www.shapeblue.com 53 Chandos Place, Covent Garden, London WC2N 4HSUK @shapeblue
