Fair enough. I modified our Jenkins job to differentiate between versions. I might open a PR to emphasis this in README, to prevent further confusion.
Thanks On Mon, Feb 19, 2018 at 4:35 AM, Rohit Yadav <rohit.ya...@shapeblue.com> wrote: > 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 > > > >
