You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Khosrow Moossavi <km...@cloudops.com> on 2018/02/16 16:58:59 UTC
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/3839239a21fc14a64acc18900ae303961036ef91#diff-68ae31f5f30dae8f541e26b8acbd75eeL247
Khosrow Moossavi
CloudOps
Re: Potential backward incompatibility problem in building SystemVM
Posted by Khosrow Moossavi <km...@cloudops.com>.
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 <ro...@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 <km...@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 <ro...@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 <km...@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
>
>
>
>
Re: Potential backward incompatibility problem in building
SystemVM
Posted by Rohit Yadav <ro...@shapeblue.com>.
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 <km...@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 <ro...@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 <km...@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
Re: Potential backward incompatibility problem in building SystemVM
Posted by Khosrow Moossavi <km...@cloudops.com>.
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 <ro...@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 <km...@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
> 53 Chandos Place, Covent Garden, London WC2N 4HSUK
> @shapeblue
>
>
>
>
Re: Potential backward incompatibility problem in building
SystemVM
Posted by Rohit Yadav <ro...@shapeblue.com>.
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 <km...@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/3839239a21fc14a64acc18900ae303961036ef91#diff-68ae31f5f30dae8f541e26b8acbd75eeL247
Khosrow Moossavi
CloudOps
rohit.yadav@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London WC2N 4HSUK
@shapeblue
Re: Potential backward incompatibility problem in building SystemVM
Posted by Daan Hoogland <da...@gmail.com>.
Khosrow,
If I read your description correct you want the script to (effectively)
build the systemvm64template if I pass appliance name "bla" on the
commandline. I don't think we want that. What am I missing?
On Fri, Feb 16, 2018 at 5:58 PM, Khosrow Moossavi <km...@cloudops.com>
wrote:
> 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
>
--
Daan