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 > 53 Chandos Place, Covent Garden, London WC2N 4HSUK > @shapeblue > > > >
