cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Khosrow Moossavi <kmooss...@cloudops.com>
Subject Re: Potential backward incompatibility problem in building SystemVM
Date Mon, 19 Feb 2018 19:38:08 GMT
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.yadav@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 <kmoossavi@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.yadav@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 <kmoossavi@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.yadav@shapeblue.com
> > www.shapeblue.com<http://www.shapeblue.com>
> > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> > @shapeblue
> >
> >
> >
> >
>
> rohit.yadav@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message