You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Rohit Yadav <bh...@apache.org> on 2013/02/05 13:24:26 UTC
Building SystemVM template appliance
Just wanted to share some wip, based on the way we can build devcloud
and basebox appliance, I've added a template systemvm appliance which
can be built using veewee and currently has VMDK disk image format.
It's based on Debian b4-i386, has 256MB ram and 2GB HDD. The built
vbox disk can be exported as ova, raw disk image, qcow2 etc.
I've put it under tools/appliance. Maybe we should move our appliance
building code which is in tools/devcloud/src to tools/appliance? Pl.
feel free to hack on it, update the README and scripts.
We now just need to port the patches/systemvm/debian/buildsystemvm.sh
to tools/appliance/definitions/systemvmtemplate/base.sh and add
cleanup code.
- Install [RVM](https://rvm.io/rvm/install)
- Setup paths: export PATH=~/.rvm/bin:$PATH
- Install Ruby 1.9.3, if it installed some other version: rvm install 1.9.3
cd tools/appliance
veewee vbox list
(Modify scripts in definitions/systemvmtemplate/ as per needs)
veewee vbox build 'systemvmtemplate'
veewee vbox up 'systemvmtemplate' # start the box
Regards.
Re: Building SystemVM template appliance
Posted by Rohit Yadav <bh...@apache.org>.
>
> Mind reviewing ebe738e (on master) to make sure I interpreted what came
> from Veewee (and what did not) correctly?
Thanks Chip!
>
> -chip
Re: Building SystemVM template appliance
Posted by Chiradeep Vittal <Ch...@citrix.com>.
LGTM. Thanks!
On 2/11/13 6:49 PM, "Chip Childers" <ch...@sungard.com> wrote:
>On Fri, Feb 08, 2013 at 10:19:43AM -0500, Chip Childers wrote:
>> On Thu, Feb 07, 2013 at 07:10:48PM -0800, Chiradeep Vittal wrote:
>> > Thanks Chip. I added some shell scripts in the systemvmtemplate
>>directory
>> > -- not sure if you want to add the header to each or leave it to the
>> > LICENSE file
>>
>> Yeah, all of that needs to be sorted out. We don't want LICENSE files
>> floating around in the lower level folders.
>>
>> Like I said, I'll carve out some time to help sort through this for all
>> of the Veewee stuff as best I can. Probably next week.
>>
>> -chip
>
>Chiradeep and Rohit,
>
>Mind reviewing ebe738e (on master) to make sure I interpreted what came
>from Veewee (and what did not) correctly?
>
>-chip
Re: Building SystemVM template appliance
Posted by Chip Childers <ch...@sungard.com>.
On Fri, Feb 08, 2013 at 10:19:43AM -0500, Chip Childers wrote:
> On Thu, Feb 07, 2013 at 07:10:48PM -0800, Chiradeep Vittal wrote:
> > Thanks Chip. I added some shell scripts in the systemvmtemplate directory
> > -- not sure if you want to add the header to each or leave it to the
> > LICENSE file
>
> Yeah, all of that needs to be sorted out. We don't want LICENSE files
> floating around in the lower level folders.
>
> Like I said, I'll carve out some time to help sort through this for all
> of the Veewee stuff as best I can. Probably next week.
>
> -chip
Chiradeep and Rohit,
Mind reviewing ebe738e (on master) to make sure I interpreted what came
from Veewee (and what did not) correctly?
-chip
Re: Building SystemVM template appliance
Posted by Chip Childers <ch...@sungard.com>.
On Thu, Feb 07, 2013 at 07:10:48PM -0800, Chiradeep Vittal wrote:
> Thanks Chip. I added some shell scripts in the systemvmtemplate directory
> -- not sure if you want to add the header to each or leave it to the
> LICENSE file
Yeah, all of that needs to be sorted out. We don't want LICENSE files
floating around in the lower level folders.
Like I said, I'll carve out some time to help sort through this for all
of the Veewee stuff as best I can. Probably next week.
-chip
Re: Building SystemVM template appliance
Posted by Chiradeep Vittal <Ch...@citrix.com>.
Thanks Chip. I added some shell scripts in the systemvmtemplate directory
-- not sure if you want to add the header to each or leave it to the
LICENSE file
On 2/7/13 12:58 PM, "Chip Childers" <ch...@sungard.com> wrote:
>On Wed, Feb 06, 2013 at 06:47:28PM -0800, Chiradeep Vittal wrote:
>> It is confusing -- gaah.
>> I could be persuaded that it could be licensed as Apache. But IANAL and
>>we
>> went through the legal wringer already on this in Aug/Sep.
>>
>
>IMO, the best thing to do is to reference them as MIT licensed.
>
>On 2/5/13 6:49 PM, "Rohit Yadav" <bh...@apache.org> wrote:
>> I'm not sure it applies, I did not copy them, veewee generates the
>> definitions for you which are like stubs and you modify the
>> definitions as per your needs. MIT should be compatible with APL?
>> Besides, we're not including veewee in our codebase, they are just
>> config files for veewee.
>
>Since they come from the Veewee project initially, I think that we
>should treat them like the system VM config files that we sorted through
>for 4.0.0. Luckily they are from an MIT licensed project. IMO, we
>document it as licensed under MIT, and from the Veewee project, in the
>source code legal docs.
>
>> This is not something new, we've veewee definitions in
>> tools/devcloud/src/deps/boxes for devcloud etc. If this is an issue,
>> we need to fix it there as well.
>
>I think we do need to do that, and I'll take credit for not having them
>properly attributed way back when.
>
>In fact, I'll take care of all of the Veewee config files in one shot. I
>just created CLOUDSTACK-1198.
>
>-chip
Re: Building SystemVM template appliance
Posted by Chip Childers <ch...@sungard.com>.
On Wed, Feb 06, 2013 at 06:47:28PM -0800, Chiradeep Vittal wrote:
> It is confusing -- gaah.
> I could be persuaded that it could be licensed as Apache. But IANAL and we
> went through the legal wringer already on this in Aug/Sep.
>
IMO, the best thing to do is to reference them as MIT licensed.
On 2/5/13 6:49 PM, "Rohit Yadav" <bh...@apache.org> wrote:
> I'm not sure it applies, I did not copy them, veewee generates the
> definitions for you which are like stubs and you modify the
> definitions as per your needs. MIT should be compatible with APL?
> Besides, we're not including veewee in our codebase, they are just
> config files for veewee.
Since they come from the Veewee project initially, I think that we
should treat them like the system VM config files that we sorted through
for 4.0.0. Luckily they are from an MIT licensed project. IMO, we
document it as licensed under MIT, and from the Veewee project, in the
source code legal docs.
> This is not something new, we've veewee definitions in
> tools/devcloud/src/deps/boxes for devcloud etc. If this is an issue,
> we need to fix it there as well.
I think we do need to do that, and I'll take credit for not having them
properly attributed way back when.
In fact, I'll take care of all of the Veewee config files in one shot. I
just created CLOUDSTACK-1198.
-chip
Re: Building SystemVM template appliance
Posted by Rohit Yadav <bh...@apache.org>.
On Thu, Feb 7, 2013 at 8:17 AM, Chiradeep Vittal
<Ch...@citrix.com> wrote:
> It is confusing -- gaah.
> I could be persuaded that it could be licensed as Apache. But IANAL and we
> went through the legal wringer already on this in Aug/Sep.
>
> To build the actual systemvm, I would call another helper script in post
> install: cloudstack.sh which replicates the packages() function in
> buildsystemvm.sh
Yes veewee calls base.sh which is the postinstallation script that
runs when the basic box (the vm) is created.
So, you customize the vm in definitions.rb and works on the
postinstallation scripts (they are, base.sh which is the first post
install scripts, cleanup.sh which can be used to do some house
cleaning, before zero.sh is called which fills the remaining disk
image with zeroes so, when we export the vmdk image as ova, we get
max. compression, i.e. small size).
>
> To perform the overrides of default config files, it seems we would need
> the puppet provisioner in vagrant?
No for the systemvm template all you need is veewee, while you can
configure vagrant and/or puppet, it's not required.
Just configuring stuff we want to install and setup inside the vm in
base.sh would work.
Regards.
>
>
> On 2/5/13 6:49 PM, "Rohit Yadav" <bh...@apache.org> wrote:
>
>>I'm not sure it applies, I did not copy them, veewee generates the
>>definitions for you which are like stubs and you modify the
>>definitions as per your needs. MIT should be compatible with APL?
>>Besides, we're not including veewee in our codebase, they are just
>>config files for veewee.
>>
>>This is not something new, we've veewee definitions in
>>tools/devcloud/src/deps/boxes for devcloud etc. If this is an issue,
>>we need to fix it there as well.
>>
>>Regards.
>>
>>On Wed, Feb 6, 2013 at 5:24 AM, Chiradeep Vittal
>><Ch...@citrix.com> wrote:
>>> What I meant was to
>>> - retain the MIT license and not change the license
>>> - maintain in our repo.
>>> - optionally recognize the provenance (either in NOTICE or in the
>>> directory)
>>>
>>> On 2/5/13 1:44 PM, "Chip Childers" <ch...@sungard.com> wrote:
>>>
>>>>On Tue, Feb 5, 2013 at 2:34 PM, Chiradeep Vittal
>>>><Ch...@citrix.com> wrote:
>>>>> Rohit,
>>>>> I see that you have followed the code from
>>>>>
>>>>>https://github.com/jedi4ever/veewee/tree/master/templates/Debian-7.0-b4
>>>>>-i
>>>>>38
>>>>> 6-netboot
>>>>>
>>>>>
>>>>> Since that code is under MIT license:
>>>>> https://github.com/jedi4ever/veewee/blob/master/License
>>>>>
>>>>>
>>>>> I think we should not check it in or reproduce the MIT license.
>>>>
>>>>Just to be clear, by "reproduce", are you suggesting that we include
>>>>the legal docs for this? (assuming that we want to keep it in the
>>>>repo, which I'm personally a +1 on)
>>>>
>>>>> On 2/5/13 4:24 AM, "Rohit Yadav" <bh...@apache.org> wrote:
>>>>>
>>>>>>Just wanted to share some wip, based on the way we can build devcloud
>>>>>>and basebox appliance, I've added a template systemvm appliance which
>>>>>>can be built using veewee and currently has VMDK disk image format.
>>>>>>It's based on Debian b4-i386, has 256MB ram and 2GB HDD. The built
>>>>>>vbox disk can be exported as ova, raw disk image, qcow2 etc.
>>>>>>I've put it under tools/appliance. Maybe we should move our appliance
>>>>>>building code which is in tools/devcloud/src to tools/appliance? Pl.
>>>>>>feel free to hack on it, update the README and scripts.
>>>>>>
>>>>>>We now just need to port the patches/systemvm/debian/buildsystemvm.sh
>>>>>>to tools/appliance/definitions/systemvmtemplate/base.sh and add
>>>>>>cleanup code.
>>>>>>
>>>>>> - Install [RVM](https://rvm.io/rvm/install)
>>>>>> - Setup paths: export PATH=~/.rvm/bin:$PATH
>>>>>> - Install Ruby 1.9.3, if it installed some other version: rvm install
>>>>>>1.9.3
>>>>>>
>>>>>>cd tools/appliance
>>>>>>veewee vbox list
>>>>>>(Modify scripts in definitions/systemvmtemplate/ as per needs)
>>>>>>veewee vbox build 'systemvmtemplate'
>>>>>>veewee vbox up 'systemvmtemplate' # start the box
>>>>>>
>>>>>>Regards.
>>>>>
>>>>>
>>>
>
Re: Building SystemVM template appliance
Posted by Rohit Yadav <bh...@apache.org>.
On Wed, Feb 20, 2013 at 4:31 AM, Chandan Purushothama
<Ch...@citrix.com> wrote:
> Hello Rohit,
>
> Should the procedure of Building the SystemVM template appliance be tested?
Sure.
>Or Should the templates produced at the end be tested for their functionality?
This is more important. I've opened and assigned myself an issue on
this, but you're welcome to help:
https://issues.apache.org/jira/browse/CLOUDSTACK-1340
>I referred to your blog and found information pertaining to challenges that you faced during building the template but didn't find information pertaining to procedure.
So, we just used veewee to do the building and then used couple of
other tools to export the final image to various formats. But
procedure to what exactly, building systemvms, or how to diy systemvm?
For building systemvms, you read the README.md file in
tools/appliance, you just need to setup a bunch of dependencies and
call ./build.sh for automatic building and export, or just:
veewee vbox build 'systemvmtemplate'
veewee vbox halt 'systemvmtemplate'
And export the appliance manually via vboxmanage, vbox manager. qemu-img etc.
>May I know the location where I can find documentation pertaining to the procedure and what needs to be tested as a QA effort?
tools/appliance/README.md
Wiki, I'll set one up soon. For QA effort, we just need to test that
all the exported formats work fine on their respective hypervisor, a
basic zone deployment and running vm, network/router life cycles
should be enough for starters.
Regards.
>
> Thank you,
> Chandan.
>
> -----Original Message-----
> From: rohityadav89@gmail.com [mailto:rohityadav89@gmail.com] On Behalf Of Rohit Yadav
> Sent: Tuesday, February 19, 2013 2:31 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: Building SystemVM template appliance
>
> On Tue, Feb 19, 2013 at 8:23 AM, Chiradeep Vittal <Ch...@citrix.com> wrote:
>> Hi Rohit
>>
>>>>
>>>> Are the format conversions automated?
>>>
>>>They are now! The file name format is:
>>>$appliance-$build_date-$branch-hyperv.$format
>>>Format conversion and archiving is automated on a large instance with
>>>export formats:
>>>ova -> vmware
>>>vhd -> xen
>>>qcow2 -> kvm
>>>vhd -> hyperv
>>>
>>>Build job:
>>>http://jenkins.cloudstack.org/view/All/job/build-systemvm-master
>>>
>>>But I'm yet to try one of xen or kvm templates. The bugs would be
>>>mostly fixable in postinstall.sh
>>>
>>>For exporting xen images from raw image, I had to build xen (for a
>>>library) and vhd-util from blktap2/tools. Will post a blog on that
>>>exercise.
>>
>> I used to use a patch from the Xen ML to enable vhd-util to do
>> conversions, but IIRC this has been merged into master. If others
>> (outside of the build server) want to use vhd-util what are their options?
>>
>>>
>>>I've fixed the partition as regular one with different partitions for
>>>/var, /opt, /usr, /tmp, /boot, /home, please see the partitions sizes,
>>>advise if we want to change them: (syntax: min. size, priority, max.
>>>size)
>>>https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=c
>>>ommi t;h=ab63a433ecbf60e18ad6cbcb0353c61fa432bcdc
>>
>> Looks good. Glad to see swap space. Have dealt with a few OOMs when
>> the system vm was FC8 and did not have swap.
>>
>>>
>>>Chiradeep, we can copy stuff inside the appliance using veewee vbox
>>>ssh <command> or scping before we halt using veewee vbox halt
>>><machine>. How do you want to use the config.dat,
>>
>> We should not need config.dat now that the debconf-set-selections
>> trick is used.
>
> First automated build (the whole rvm non-interactive non-login shell issue took me a lot of time to figure out, the bug at jenkins was that $HOME was not defined for rvm):
> http://jenkins.cloudstack.org/job/build-systemvm-master/47/console
>
> Archived appliances:
> http://people.apache.org/~bhaisaab/systemvm
>
> Blog:
> http://rohityadav.in/logs/building-systemvms/
>
> Now, all we need to do is test them against real hosts and fix any post installation scripts, network conf.
>
> Regards.
>
>>
>>
Re: Building SystemVM template appliance
Posted by Chiradeep Vittal <Ch...@citrix.com>.
Chandan,
To build the template, you need to check out the git source [master] and
cd tools/appliance/definitions/
veewee vbox build 'systemvmtemplate'
Requirements are documented in tools/appliance/definitions/README.md
However the systemvm template is by no means ready. We still have to
actually run it on XS/KVM/VMWare environments and verify that it works
with CS
On 2/19/13 3:01 PM, "Chandan Purushothama"
<Ch...@citrix.com> wrote:
>Hello Rohit,
>
>Should the procedure of Building the SystemVM template appliance be
>tested? Or Should the templates produced at the end be tested for their
>functionality? I referred to your blog and found information pertaining
>to challenges that you faced during building the template but didn't find
>information pertaining to procedure. May I know the location where I can
>find documentation pertaining to the procedure and what needs to be
>tested as a QA effort?
>
>Thank you,
>Chandan.
>
>-----Original Message-----
>From: rohityadav89@gmail.com [mailto:rohityadav89@gmail.com] On Behalf Of
>Rohit Yadav
>Sent: Tuesday, February 19, 2013 2:31 AM
>To: cloudstack-dev@incubator.apache.org
>Subject: Re: Building SystemVM template appliance
>
>On Tue, Feb 19, 2013 at 8:23 AM, Chiradeep Vittal
><Ch...@citrix.com> wrote:
>> Hi Rohit
>>
>>>>
>>>> Are the format conversions automated?
>>>
>>>They are now! The file name format is:
>>>$appliance-$build_date-$branch-hyperv.$format
>>>Format conversion and archiving is automated on a large instance with
>>>export formats:
>>>ova -> vmware
>>>vhd -> xen
>>>qcow2 -> kvm
>>>vhd -> hyperv
>>>
>>>Build job:
>>>http://jenkins.cloudstack.org/view/All/job/build-systemvm-master
>>>
>>>But I'm yet to try one of xen or kvm templates. The bugs would be
>>>mostly fixable in postinstall.sh
>>>
>>>For exporting xen images from raw image, I had to build xen (for a
>>>library) and vhd-util from blktap2/tools. Will post a blog on that
>>>exercise.
>>
>> I used to use a patch from the Xen ML to enable vhd-util to do
>> conversions, but IIRC this has been merged into master. If others
>> (outside of the build server) want to use vhd-util what are their
>>options?
>>
>>>
>>>I've fixed the partition as regular one with different partitions for
>>>/var, /opt, /usr, /tmp, /boot, /home, please see the partitions sizes,
>>>advise if we want to change them: (syntax: min. size, priority, max.
>>>size)
>>>https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=c
>>>ommi t;h=ab63a433ecbf60e18ad6cbcb0353c61fa432bcdc
>>
>> Looks good. Glad to see swap space. Have dealt with a few OOMs when
>> the system vm was FC8 and did not have swap.
>>
>>>
>>>Chiradeep, we can copy stuff inside the appliance using veewee vbox
>>>ssh <command> or scping before we halt using veewee vbox halt
>>><machine>. How do you want to use the config.dat,
>>
>> We should not need config.dat now that the debconf-set-selections
>> trick is used.
>
>First automated build (the whole rvm non-interactive non-login shell
>issue took me a lot of time to figure out, the bug at jenkins was that
>$HOME was not defined for rvm):
>http://jenkins.cloudstack.org/job/build-systemvm-master/47/console
>
>Archived appliances:
>http://people.apache.org/~bhaisaab/systemvm
>
>Blog:
>http://rohityadav.in/logs/building-systemvms/
>
>Now, all we need to do is test them against real hosts and fix any post
>installation scripts, network conf.
>
>Regards.
>
>>
>>
RE: Building SystemVM template appliance
Posted by Chandan Purushothama <Ch...@citrix.com>.
Hello Rohit,
Should the procedure of Building the SystemVM template appliance be tested? Or Should the templates produced at the end be tested for their functionality? I referred to your blog and found information pertaining to challenges that you faced during building the template but didn't find information pertaining to procedure. May I know the location where I can find documentation pertaining to the procedure and what needs to be tested as a QA effort?
Thank you,
Chandan.
-----Original Message-----
From: rohityadav89@gmail.com [mailto:rohityadav89@gmail.com] On Behalf Of Rohit Yadav
Sent: Tuesday, February 19, 2013 2:31 AM
To: cloudstack-dev@incubator.apache.org
Subject: Re: Building SystemVM template appliance
On Tue, Feb 19, 2013 at 8:23 AM, Chiradeep Vittal <Ch...@citrix.com> wrote:
> Hi Rohit
>
>>>
>>> Are the format conversions automated?
>>
>>They are now! The file name format is:
>>$appliance-$build_date-$branch-hyperv.$format
>>Format conversion and archiving is automated on a large instance with
>>export formats:
>>ova -> vmware
>>vhd -> xen
>>qcow2 -> kvm
>>vhd -> hyperv
>>
>>Build job:
>>http://jenkins.cloudstack.org/view/All/job/build-systemvm-master
>>
>>But I'm yet to try one of xen or kvm templates. The bugs would be
>>mostly fixable in postinstall.sh
>>
>>For exporting xen images from raw image, I had to build xen (for a
>>library) and vhd-util from blktap2/tools. Will post a blog on that
>>exercise.
>
> I used to use a patch from the Xen ML to enable vhd-util to do
> conversions, but IIRC this has been merged into master. If others
> (outside of the build server) want to use vhd-util what are their options?
>
>>
>>I've fixed the partition as regular one with different partitions for
>>/var, /opt, /usr, /tmp, /boot, /home, please see the partitions sizes,
>>advise if we want to change them: (syntax: min. size, priority, max.
>>size)
>>https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=c
>>ommi t;h=ab63a433ecbf60e18ad6cbcb0353c61fa432bcdc
>
> Looks good. Glad to see swap space. Have dealt with a few OOMs when
> the system vm was FC8 and did not have swap.
>
>>
>>Chiradeep, we can copy stuff inside the appliance using veewee vbox
>>ssh <command> or scping before we halt using veewee vbox halt
>><machine>. How do you want to use the config.dat,
>
> We should not need config.dat now that the debconf-set-selections
> trick is used.
First automated build (the whole rvm non-interactive non-login shell issue took me a lot of time to figure out, the bug at jenkins was that $HOME was not defined for rvm):
http://jenkins.cloudstack.org/job/build-systemvm-master/47/console
Archived appliances:
http://people.apache.org/~bhaisaab/systemvm
Blog:
http://rohityadav.in/logs/building-systemvms/
Now, all we need to do is test them against real hosts and fix any post installation scripts, network conf.
Regards.
>
>
Re: Building SystemVM template appliance
Posted by Rohit Yadav <bh...@apache.org>.
On Tue, Feb 19, 2013 at 8:23 AM, Chiradeep Vittal
<Ch...@citrix.com> wrote:
> Hi Rohit
>
>>>
>>> Are the format conversions automated?
>>
>>They are now! The file name format is:
>>$appliance-$build_date-$branch-hyperv.$format
>>Format conversion and archiving is automated on a large instance with
>>export formats:
>>ova -> vmware
>>vhd -> xen
>>qcow2 -> kvm
>>vhd -> hyperv
>>
>>Build job:
>>http://jenkins.cloudstack.org/view/All/job/build-systemvm-master
>>
>>But I'm yet to try one of xen or kvm templates. The bugs would be
>>mostly fixable in postinstall.sh
>>
>>For exporting xen images from raw image, I had to build xen (for a
>>library) and vhd-util from blktap2/tools. Will post a blog on that
>>exercise.
>
> I used to use a patch from the Xen ML to enable vhd-util to do
> conversions, but IIRC this has been merged into master. If others (outside
> of the build server) want to use vhd-util what are their options?
>
>>
>>I've fixed the partition as regular one with different partitions for
>>/var, /opt, /usr, /tmp, /boot, /home, please see the partitions sizes,
>>advise if we want to change them: (syntax: min. size, priority, max.
>>size)
>>https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commi
>>t;h=ab63a433ecbf60e18ad6cbcb0353c61fa432bcdc
>
> Looks good. Glad to see swap space. Have dealt with a few OOMs when the
> system vm was FC8 and did not have swap.
>
>>
>>Chiradeep, we can copy stuff inside the appliance using veewee vbox
>>ssh <command> or scping before we halt using veewee vbox halt
>><machine>. How do you want to use the config.dat,
>
> We should not need config.dat now that the debconf-set-selections trick is
> used.
First automated build (the whole rvm non-interactive non-login shell
issue took me a lot of time to figure out, the bug at jenkins was that
$HOME was not defined for rvm):
http://jenkins.cloudstack.org/job/build-systemvm-master/47/console
Archived appliances:
http://people.apache.org/~bhaisaab/systemvm
Blog:
http://rohityadav.in/logs/building-systemvms/
Now, all we need to do is test them against real hosts and fix any
post installation scripts, network conf.
Regards.
>
>
Re: Building SystemVM template appliance
Posted by Chiradeep Vittal <Ch...@citrix.com>.
Hi Rohit
>>
>> Are the format conversions automated?
>
>They are now! The file name format is:
>$appliance-$build_date-$branch-hyperv.$format
>Format conversion and archiving is automated on a large instance with
>export formats:
>ova -> vmware
>vhd -> xen
>qcow2 -> kvm
>vhd -> hyperv
>
>Build job:
>http://jenkins.cloudstack.org/view/All/job/build-systemvm-master
>
>But I'm yet to try one of xen or kvm templates. The bugs would be
>mostly fixable in postinstall.sh
>
>For exporting xen images from raw image, I had to build xen (for a
>library) and vhd-util from blktap2/tools. Will post a blog on that
>exercise.
I used to use a patch from the Xen ML to enable vhd-util to do
conversions, but IIRC this has been merged into master. If others (outside
of the build server) want to use vhd-util what are their options?
>
>I've fixed the partition as regular one with different partitions for
>/var, /opt, /usr, /tmp, /boot, /home, please see the partitions sizes,
>advise if we want to change them: (syntax: min. size, priority, max.
>size)
>https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commi
>t;h=ab63a433ecbf60e18ad6cbcb0353c61fa432bcdc
Looks good. Glad to see swap space. Have dealt with a few OOMs when the
system vm was FC8 and did not have swap.
>
>Chiradeep, we can copy stuff inside the appliance using veewee vbox
>ssh <command> or scping before we halt using veewee vbox halt
><machine>. How do you want to use the config.dat,
We should not need config.dat now that the debconf-set-selections trick is
used.
Re: Building SystemVM template appliance
Posted by Rohit Yadav <bh...@apache.org>.
On Fri, Feb 15, 2013 at 12:40 AM, Chiradeep Vittal
<Ch...@citrix.com> wrote:
>
>>
>>To update, I'm able to build a systemvm appliance with vbox and able
>>to convert the disk image to vmdk, hyper-v vhd, qcow2 and ova
>>(vmware), but I've not tested them. Next week, I'll take help from
>>Prasanna to setup a jenkins job on j.c.o. I cannot do it on b.a.o, as
>>I need to test it first, fix the building process and it would need a
>>linux host that can run vbox. The total build time takes about ~25
>>mins on my laptop if internet speed is good enough.
>
> 7 minutes here. I recommend you set up an apt caching proxy. I suspect
> that is done
> in preseed.cfg
>
> Are the format conversions automated?
They are now! The file name format is:
$appliance-$build_date-$branch-hyperv.$format
Format conversion and archiving is automated on a large instance with
export formats:
ova -> vmware
vhd -> xen
qcow2 -> kvm
vhd -> hyperv
Build job: http://jenkins.cloudstack.org/view/All/job/build-systemvm-master
But I'm yet to try one of xen or kvm templates. The bugs would be
mostly fixable in postinstall.sh
For exporting xen images from raw image, I had to build xen (for a
library) and vhd-util from blktap2/tools. Will post a blog on that
exercise.
I've fixed the partition as regular one with different partitions for
/var, /opt, /usr, /tmp, /boot, /home, please see the partitions sizes,
advise if we want to change them: (syntax: min. size, priority, max.
size)
https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=ab63a433ecbf60e18ad6cbcb0353c61fa432bcdc
Chiradeep, we can copy stuff inside the appliance using veewee vbox
ssh <command> or scping before we halt using veewee vbox halt
<machine>. How do you want to use the config.dat, I can copy it inside
using these commands. For the signature FIXME, I can append the md5
checksums.
Regards.
>
Re: Building SystemVM template appliance
Posted by Chiradeep Vittal <Ch...@citrix.com>.
>
>To update, I'm able to build a systemvm appliance with vbox and able
>to convert the disk image to vmdk, hyper-v vhd, qcow2 and ova
>(vmware), but I've not tested them. Next week, I'll take help from
>Prasanna to setup a jenkins job on j.c.o. I cannot do it on b.a.o, as
>I need to test it first, fix the building process and it would need a
>linux host that can run vbox. The total build time takes about ~25
>mins on my laptop if internet speed is good enough.
7 minutes here. I recommend you set up an apt caching proxy. I suspect
that is done
in preseed.cfg
Are the format conversions automated?
Re: Building SystemVM template appliance
Posted by Rohit Yadav <bh...@apache.org>.
Hi Chiradeep,
>>Okay this is the issue :) I'll fix in preseed.cfg so we'll have only
>>one root partition (and maybe a small swap but not required I think?)
>>like the present systemvm which too has only one / partition, unless
>>you want a different scheme.
>
> Actually prefer different partitions for securing against local attacks.
> The CIS
> Benchmark [http://benchmarks.cisecurity.org/downloads/benchmarks/]
> recommends the following:
> "Minimally, the following conditions should must exist:
> * user writable directories (i.e /tmp) should have their own partitions to
> prevent hardlink attacks
> * /var and /opt should should not share a partition with the system root
> '/'"
Sure, I can do that.
>
>
>>
>>>
>>> I've left a few FIXME in cloudstack-packages.sh, please take a look.
>>
>>Except for the signature creator I fixed other ones. How do you
>>propose we create the signature, use latest git SHA?
>
> Currently it is the md5 of the patches/systemvm/debian/config and
> patches/systemvm/debian/vpn tar gzip.
Cool thanks.
To update, I'm able to build a systemvm appliance with vbox and able
to convert the disk image to vmdk, hyper-v vhd, qcow2 and ova
(vmware), but I've not tested them. Next week, I'll take help from
Prasanna to setup a jenkins job on j.c.o. I cannot do it on b.a.o, as
I need to test it first, fix the building process and it would need a
linux host that can run vbox. The total build time takes about ~25
mins on my laptop if internet speed is good enough.
Regards.
>
>>
>>Regards.
>>
>>>
>>> --
>>> Chiradeep
>>>
>
Re: FW: Building SystemVM template appliance
Posted by Rohit Yadav <bh...@apache.org>.
On Wed, Feb 13, 2013 at 5:21 PM, Donal Lafferty
<do...@citrix.com> wrote:
> Hi Rohit,
>
> I wanted to ask a question out of band, because I don't want to confuse this thread's discussion.
>
> Are you talking about a veewee script that will build all the systemVMs, or just the one used for devcloud?
Just the scripts for building systemvm in tools/appliance
The code that builds devcloud (xenbox) and basebox (base os vagrant
box) was last tested many weeks ago, the work was mostly done by James
who may want to fix 'em up maybe, folks on last irc meeting were also
asking for that. I'll probably look at them, fix them later.
Regards.
>
>
> DL
>
>
>> -----Original Message-----
>> From: rohityadav89@gmail.com [mailto:rohityadav89@gmail.com] On Behalf
>> Of Rohit Yadav
>> Sent: 12 February 2013 13:00
>> To: Chiradeep Vittal
>> Cc: Chip Childers; cloudstack-dev@incubator.apache.org; Sheng Yang
>> Subject: Re: Building SystemVM template appliance
>>
>> >>
>> >>> It still builds with the hostname as 'ahha' -- I can't figure out why.
>> >>We can enforce hostname in one of the postinstall scripts, I found
>> >>some reference of ahha in config.dat
>> >
>> > Figured it out: the dhcp server in vbox hands out the dns server of
>> > the host (in my case my corporate dns server). Dhclient reverse looks
>> > up
>> > 10.0.2.15 (the address of the vm) and gets a valid response from the
>> > corporate dns server. Annoyingly this is used to name the volume group
>> > during partitioning. The only foolproof way may be to write a custom
>> > partman recipe in preseed.cfg.
>>
>> Okay this is the issue :) I'll fix in preseed.cfg so we'll have only one root
>> partition (and maybe a small swap but not required I think?) like the present
>> systemvm which too has only one / partition, unless you want a different
>> scheme.
>>
>> > You can change the ip of the vm using
>> > :vm_options in veewee but veewee's http server is hardcoded to
>> > 10.0.2.2 so nothing else works.
>> >
>> >>
>> >>> What is left:
>> >>> Openswan requires interactive input to install. Previously we had a
>> >>> pre-baked config.dat that fed into pkg-configure to supply canned
>> >>> responses. Somehow this needs to be copied into the root directory
>> >>> (postinstall_files in definition.rb will try to execute it).
>>
>> We can embed the data in one of the scripts itself or add a new one so it
>> could copy itself, will fix this.
>>
>> >>scp to suitable path inside systemvmtemplate on port 7222? (See
>> >>definitions.rb for ssh port details). Install ssh server in
>> >>postinstall script if not installed (I think it is), or just attach
>> >>the payload in yet another postinstall script and let it run.
>> >
>> > Well veewee doesn't let you write custom scripts that execute on the host?
>> > Anyway, I figured we can use debconf-set-selections to avoid this problem.
>> > As far as copying the custom scripts goes, perhaps we can wget from
>> > git-wip-us.apache.org repo ?
>>
>> Cool, I saw you already made change.
>>
>> > I've left a few FIXME in cloudstack-packages.sh, please take a look.
>>
>> Except for the signature creator I fixed other ones. How do you propose we
>> create the signature, use latest git SHA?
>>
>> Regards.
>>
>> >
>> > --
>> > Chiradeep
>> >
Re: Building SystemVM template appliance
Posted by Chiradeep Vittal <Ch...@citrix.com>.
>> Figured it out: the dhcp server in vbox hands out the dns server of the
>> host (in my case my corporate dns server). Dhclient reverse looks up
>> 10.0.2.15 (the address of the vm) and gets a valid response from the
>> corporate dns server. Annoyingly this is used to name the volume group
>> during partitioning. The only foolproof way may be to write a custom
>> partman recipe in preseed.cfg.
>
>Okay this is the issue :) I'll fix in preseed.cfg so we'll have only
>one root partition (and maybe a small swap but not required I think?)
>like the present systemvm which too has only one / partition, unless
>you want a different scheme.
Actually prefer different partitions for securing against local attacks.
The CIS
Benchmark [http://benchmarks.cisecurity.org/downloads/benchmarks/]
recommends the following:
"Minimally, the following conditions should must exist:
* user writable directories (i.e /tmp) should have their own partitions to
prevent hardlink attacks
* /var and /opt should should not share a partition with the system root
'/'"
>
>>
>> I've left a few FIXME in cloudstack-packages.sh, please take a look.
>
>Except for the signature creator I fixed other ones. How do you
>propose we create the signature, use latest git SHA?
Currently it is the md5 of the patches/systemvm/debian/config and
patches/systemvm/debian/vpn tar gzip.
>
>Regards.
>
>>
>> --
>> Chiradeep
>>
Re: Building SystemVM template appliance
Posted by Rohit Yadav <bh...@apache.org>.
>>
>>> It still builds with the hostname as 'ahha' -- I can't figure out why.
>>We can enforce hostname in one of the postinstall scripts, I found
>>some reference of ahha in config.dat
>
> Figured it out: the dhcp server in vbox hands out the dns server of the
> host (in my case my corporate dns server). Dhclient reverse looks up
> 10.0.2.15 (the address of the vm) and gets a valid response from the
> corporate dns server. Annoyingly this is used to name the volume group
> during partitioning. The only foolproof way may be to write a custom
> partman recipe in preseed.cfg.
Okay this is the issue :) I'll fix in preseed.cfg so we'll have only
one root partition (and maybe a small swap but not required I think?)
like the present systemvm which too has only one / partition, unless
you want a different scheme.
> You can change the ip of the vm using
> :vm_options in veewee but veewee's http server is hardcoded to 10.0.2.2 so
> nothing else works.
>
>>
>>> What is left:
>>> Openswan requires interactive input to install. Previously we had a
>>> pre-baked config.dat that fed into pkg-configure to supply canned
>>> responses. Somehow this needs to be copied into the root directory
>>> (postinstall_files in definition.rb will try to execute it).
We can embed the data in one of the scripts itself or add a new one so
it could copy itself, will fix this.
>>scp to suitable path inside systemvmtemplate on port 7222? (See
>>definitions.rb for ssh port details). Install ssh server in
>>postinstall script if not installed (I think it is), or just attach
>>the payload in yet another postinstall script and let it run.
>
> Well veewee doesn't let you write custom scripts that execute on the host?
> Anyway, I figured we can use debconf-set-selections to avoid this problem.
> As far as copying the custom scripts goes, perhaps we can wget from
> git-wip-us.apache.org repo ?
Cool, I saw you already made change.
> I've left a few FIXME in cloudstack-packages.sh, please take a look.
Except for the signature creator I fixed other ones. How do you
propose we create the signature, use latest git SHA?
Regards.
>
> --
> Chiradeep
>
Re: Building SystemVM template appliance
Posted by Chiradeep Vittal <Ch...@citrix.com>.
On 2/7/13 7:27 PM, "Rohit Yadav" <bh...@apache.org> wrote:
>On Fri, Feb 8, 2013 at 8:46 AM, Chiradeep Vittal
><Ch...@citrix.com> wrote:
>> I undid your fix :) to leave it modular.
>
>:) I made it thinking would be easier to hack only one postinstall.sh
>script. Pl. also backport to 4.1 (CLOUDSTACK-1066's fix version is
>4.1, though in cfg files we use version 4.2?) so we are in sync.
Not sure about this. Are you proposing this for 4.1? Should be OK I guess.
>
>> It still builds with the hostname as 'ahha' -- I can't figure out why.
>We can enforce hostname in one of the postinstall scripts, I found
>some reference of ahha in config.dat
Figured it out: the dhcp server in vbox hands out the dns server of the
host (in my case my corporate dns server). Dhclient reverse looks up
10.0.2.15 (the address of the vm) and gets a valid response from the
corporate dns server. Annoyingly this is used to name the volume group
during partitioning. The only foolproof way may be to write a custom
partman recipe in preseed.cfg. You can change the ip of the vm using
:vm_options in veewee but veewee's http server is hardcoded to 10.0.2.2 so
nothing else works.
>
>> What is left:
>> Openswan requires interactive input to install. Previously we had a
>> pre-baked config.dat that fed into pkg-configure to supply canned
>> responses. Somehow this needs to be copied into the root directory
>> (postinstall_files in definition.rb will try to execute it).
>
>scp to suitable path inside systemvmtemplate on port 7222? (See
>definitions.rb for ssh port details). Install ssh server in
>postinstall script if not installed (I think it is), or just attach
>the payload in yet another postinstall script and let it run.
Well veewee doesn't let you write custom scripts that execute on the host?
Anyway, I figured we can use debconf-set-selections to avoid this problem.
As far as copying the custom scripts goes, perhaps we can wget from
git-wip-us.apache.org repo ?
I've left a few FIXME in cloudstack-packages.sh, please take a look.
--
Chiradeep
Re: Building SystemVM template appliance
Posted by Rohit Yadav <bh...@apache.org>.
On Fri, Feb 8, 2013 at 8:46 AM, Chiradeep Vittal
<Ch...@citrix.com> wrote:
> I undid your fix :) to leave it modular.
:) I made it thinking would be easier to hack only one postinstall.sh
script. Pl. also backport to 4.1 (CLOUDSTACK-1066's fix version is
4.1, though in cfg files we use version 4.2?) so we are in sync.
> It still builds with the hostname as 'ahha' -- I can't figure out why.
We can enforce hostname in one of the postinstall scripts, I found
some reference of ahha in config.dat
> What is left:
> Openswan requires interactive input to install. Previously we had a
> pre-baked config.dat that fed into pkg-configure to supply canned
> responses. Somehow this needs to be copied into the root directory
> (postinstall_files in definition.rb will try to execute it).
scp to suitable path inside systemvmtemplate on port 7222? (See
definitions.rb for ssh port details). Install ssh server in
postinstall script if not installed (I think it is), or just attach
the payload in yet another postinstall script and let it run.
Regards.
> One idea is to serve it from the http server that veewee runs to serve the
> pressed.cfg file
> Another idea is to make it a self-extracting shell file using [1]
>
> Also all the custom config files in patches/systemvm/debian/config needs
> to be copied into the vm. Again one can make a self-extracting shell file
> or use the http server
>
> Finally, I suspect netinst makes the base system far more bulky than it
> needs to be. Some packages need to be trimmed after everything is
> installed, apt-get clean needs to run and perhaps some locale data and man
> pages need to be nuked.
>
>
> On 2/7/13 4:22 AM, "Rohit Yadav" <bh...@apache.org> wrote:
>
>>Okay so I did few fixes, now there is only one postinstall.sh script
>>which needs to be configured and one can simply port methods from the
>>old script and it would run. One only required veewee and no other
>>tool to build it, nor it packages any other dependency.
>>
>>Commit:
>>https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commi
>>t;h=04d51c9e4dfccafcd54cd6581434c0db16ef8f85
>>
>>Now, someone with more experience with systemvm template needs to
>>finish the postinstall.sh script with up-to-date packages. I'm done
>>with basic definitions and code; building may take a lot of time, make
>>sure you're good internet connection, it uses NAT to install stuff
>>while running on vbox.
>>
>>Regards.
>>
>>On Thu, Feb 7, 2013 at 8:17 AM, Chiradeep Vittal
>><Ch...@citrix.com> wrote:
>>> It is confusing -- gaah.
>>> I could be persuaded that it could be licensed as Apache. But IANAL and
>>>we
>>> went through the legal wringer already on this in Aug/Sep.
>>>
>>> To build the actual systemvm, I would call another helper script in post
>>> install: cloudstack.sh which replicates the packages() function in
>>> buildsystemvm.sh
>>>
>>> To perform the overrides of default config files, it seems we would need
>>> the puppet provisioner in vagrant?
>>>
>>>
>>> On 2/5/13 6:49 PM, "Rohit Yadav" <bh...@apache.org> wrote:
>>>
>>>>I'm not sure it applies, I did not copy them, veewee generates the
>>>>definitions for you which are like stubs and you modify the
>>>>definitions as per your needs. MIT should be compatible with APL?
>>>>Besides, we're not including veewee in our codebase, they are just
>>>>config files for veewee.
>>>>
>>>>This is not something new, we've veewee definitions in
>>>>tools/devcloud/src/deps/boxes for devcloud etc. If this is an issue,
>>>>we need to fix it there as well.
>>>>
>>>>Regards.
>>>>
>>>>On Wed, Feb 6, 2013 at 5:24 AM, Chiradeep Vittal
>>>><Ch...@citrix.com> wrote:
>>>>> What I meant was to
>>>>> - retain the MIT license and not change the license
>>>>> - maintain in our repo.
>>>>> - optionally recognize the provenance (either in NOTICE or in the
>>>>> directory)
>>>>>
>>>>> On 2/5/13 1:44 PM, "Chip Childers" <ch...@sungard.com> wrote:
>>>>>
>>>>>>On Tue, Feb 5, 2013 at 2:34 PM, Chiradeep Vittal
>>>>>><Ch...@citrix.com> wrote:
>>>>>>> Rohit,
>>>>>>> I see that you have followed the code from
>>>>>>>
>>>>>>>https://github.com/jedi4ever/veewee/tree/master/templates/Debian-7.0-
>>>>>>>b4
>>>>>>>-i
>>>>>>>38
>>>>>>> 6-netboot
>>>>>>>
>>>>>>>
>>>>>>> Since that code is under MIT license:
>>>>>>> https://github.com/jedi4ever/veewee/blob/master/License
>>>>>>>
>>>>>>>
>>>>>>> I think we should not check it in or reproduce the MIT license.
>>>>>>
>>>>>>Just to be clear, by "reproduce", are you suggesting that we include
>>>>>>the legal docs for this? (assuming that we want to keep it in the
>>>>>>repo, which I'm personally a +1 on)
>>>>>>
>>>>>>> On 2/5/13 4:24 AM, "Rohit Yadav" <bh...@apache.org> wrote:
>>>>>>>
>>>>>>>>Just wanted to share some wip, based on the way we can build
>>>>>>>>devcloud
>>>>>>>>and basebox appliance, I've added a template systemvm appliance
>>>>>>>>which
>>>>>>>>can be built using veewee and currently has VMDK disk image format.
>>>>>>>>It's based on Debian b4-i386, has 256MB ram and 2GB HDD. The built
>>>>>>>>vbox disk can be exported as ova, raw disk image, qcow2 etc.
>>>>>>>>I've put it under tools/appliance. Maybe we should move our
>>>>>>>>appliance
>>>>>>>>building code which is in tools/devcloud/src to tools/appliance? Pl.
>>>>>>>>feel free to hack on it, update the README and scripts.
>>>>>>>>
>>>>>>>>We now just need to port the
>>>>>>>>patches/systemvm/debian/buildsystemvm.sh
>>>>>>>>to tools/appliance/definitions/systemvmtemplate/base.sh and add
>>>>>>>>cleanup code.
>>>>>>>>
>>>>>>>> - Install [RVM](https://rvm.io/rvm/install)
>>>>>>>> - Setup paths: export PATH=~/.rvm/bin:$PATH
>>>>>>>> - Install Ruby 1.9.3, if it installed some other version: rvm
>>>>>>>>install
>>>>>>>>1.9.3
>>>>>>>>
>>>>>>>>cd tools/appliance
>>>>>>>>veewee vbox list
>>>>>>>>(Modify scripts in definitions/systemvmtemplate/ as per needs)
>>>>>>>>veewee vbox build 'systemvmtemplate'
>>>>>>>>veewee vbox up 'systemvmtemplate' # start the box
>>>>>>>>
>>>>>>>>Regards.
>>>>>>>
>>>>>>>
>>>>>
>>>
>
Re: Building SystemVM template appliance
Posted by Chiradeep Vittal <Ch...@citrix.com>.
I undid your fix :) to leave it modular.
It still builds with the hostname as 'ahha' -- I can't figure out why.
What is left:
Openswan requires interactive input to install. Previously we had a
pre-baked config.dat that fed into pkg-configure to supply canned
responses. Somehow this needs to be copied into the root directory
(postinstall_files in definition.rb will try to execute it).
One idea is to serve it from the http server that veewee runs to serve the
pressed.cfg file
Another idea is to make it a self-extracting shell file using [1]
Also all the custom config files in patches/systemvm/debian/config needs
to be copied into the vm. Again one can make a self-extracting shell file
or use the http server
Finally, I suspect netinst makes the base system far more bulky than it
needs to be. Some packages need to be trimmed after everything is
installed, apt-get clean needs to run and perhaps some locale data and man
pages need to be nuked.
On 2/7/13 4:22 AM, "Rohit Yadav" <bh...@apache.org> wrote:
>Okay so I did few fixes, now there is only one postinstall.sh script
>which needs to be configured and one can simply port methods from the
>old script and it would run. One only required veewee and no other
>tool to build it, nor it packages any other dependency.
>
>Commit:
>https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commi
>t;h=04d51c9e4dfccafcd54cd6581434c0db16ef8f85
>
>Now, someone with more experience with systemvm template needs to
>finish the postinstall.sh script with up-to-date packages. I'm done
>with basic definitions and code; building may take a lot of time, make
>sure you're good internet connection, it uses NAT to install stuff
>while running on vbox.
>
>Regards.
>
>On Thu, Feb 7, 2013 at 8:17 AM, Chiradeep Vittal
><Ch...@citrix.com> wrote:
>> It is confusing -- gaah.
>> I could be persuaded that it could be licensed as Apache. But IANAL and
>>we
>> went through the legal wringer already on this in Aug/Sep.
>>
>> To build the actual systemvm, I would call another helper script in post
>> install: cloudstack.sh which replicates the packages() function in
>> buildsystemvm.sh
>>
>> To perform the overrides of default config files, it seems we would need
>> the puppet provisioner in vagrant?
>>
>>
>> On 2/5/13 6:49 PM, "Rohit Yadav" <bh...@apache.org> wrote:
>>
>>>I'm not sure it applies, I did not copy them, veewee generates the
>>>definitions for you which are like stubs and you modify the
>>>definitions as per your needs. MIT should be compatible with APL?
>>>Besides, we're not including veewee in our codebase, they are just
>>>config files for veewee.
>>>
>>>This is not something new, we've veewee definitions in
>>>tools/devcloud/src/deps/boxes for devcloud etc. If this is an issue,
>>>we need to fix it there as well.
>>>
>>>Regards.
>>>
>>>On Wed, Feb 6, 2013 at 5:24 AM, Chiradeep Vittal
>>><Ch...@citrix.com> wrote:
>>>> What I meant was to
>>>> - retain the MIT license and not change the license
>>>> - maintain in our repo.
>>>> - optionally recognize the provenance (either in NOTICE or in the
>>>> directory)
>>>>
>>>> On 2/5/13 1:44 PM, "Chip Childers" <ch...@sungard.com> wrote:
>>>>
>>>>>On Tue, Feb 5, 2013 at 2:34 PM, Chiradeep Vittal
>>>>><Ch...@citrix.com> wrote:
>>>>>> Rohit,
>>>>>> I see that you have followed the code from
>>>>>>
>>>>>>https://github.com/jedi4ever/veewee/tree/master/templates/Debian-7.0-
>>>>>>b4
>>>>>>-i
>>>>>>38
>>>>>> 6-netboot
>>>>>>
>>>>>>
>>>>>> Since that code is under MIT license:
>>>>>> https://github.com/jedi4ever/veewee/blob/master/License
>>>>>>
>>>>>>
>>>>>> I think we should not check it in or reproduce the MIT license.
>>>>>
>>>>>Just to be clear, by "reproduce", are you suggesting that we include
>>>>>the legal docs for this? (assuming that we want to keep it in the
>>>>>repo, which I'm personally a +1 on)
>>>>>
>>>>>> On 2/5/13 4:24 AM, "Rohit Yadav" <bh...@apache.org> wrote:
>>>>>>
>>>>>>>Just wanted to share some wip, based on the way we can build
>>>>>>>devcloud
>>>>>>>and basebox appliance, I've added a template systemvm appliance
>>>>>>>which
>>>>>>>can be built using veewee and currently has VMDK disk image format.
>>>>>>>It's based on Debian b4-i386, has 256MB ram and 2GB HDD. The built
>>>>>>>vbox disk can be exported as ova, raw disk image, qcow2 etc.
>>>>>>>I've put it under tools/appliance. Maybe we should move our
>>>>>>>appliance
>>>>>>>building code which is in tools/devcloud/src to tools/appliance? Pl.
>>>>>>>feel free to hack on it, update the README and scripts.
>>>>>>>
>>>>>>>We now just need to port the
>>>>>>>patches/systemvm/debian/buildsystemvm.sh
>>>>>>>to tools/appliance/definitions/systemvmtemplate/base.sh and add
>>>>>>>cleanup code.
>>>>>>>
>>>>>>> - Install [RVM](https://rvm.io/rvm/install)
>>>>>>> - Setup paths: export PATH=~/.rvm/bin:$PATH
>>>>>>> - Install Ruby 1.9.3, if it installed some other version: rvm
>>>>>>>install
>>>>>>>1.9.3
>>>>>>>
>>>>>>>cd tools/appliance
>>>>>>>veewee vbox list
>>>>>>>(Modify scripts in definitions/systemvmtemplate/ as per needs)
>>>>>>>veewee vbox build 'systemvmtemplate'
>>>>>>>veewee vbox up 'systemvmtemplate' # start the box
>>>>>>>
>>>>>>>Regards.
>>>>>>
>>>>>>
>>>>
>>
Re: Building SystemVM template appliance
Posted by Rohit Yadav <bh...@apache.org>.
Okay so I did few fixes, now there is only one postinstall.sh script
which needs to be configured and one can simply port methods from the
old script and it would run. One only required veewee and no other
tool to build it, nor it packages any other dependency.
Commit: https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=04d51c9e4dfccafcd54cd6581434c0db16ef8f85
Now, someone with more experience with systemvm template needs to
finish the postinstall.sh script with up-to-date packages. I'm done
with basic definitions and code; building may take a lot of time, make
sure you're good internet connection, it uses NAT to install stuff
while running on vbox.
Regards.
On Thu, Feb 7, 2013 at 8:17 AM, Chiradeep Vittal
<Ch...@citrix.com> wrote:
> It is confusing -- gaah.
> I could be persuaded that it could be licensed as Apache. But IANAL and we
> went through the legal wringer already on this in Aug/Sep.
>
> To build the actual systemvm, I would call another helper script in post
> install: cloudstack.sh which replicates the packages() function in
> buildsystemvm.sh
>
> To perform the overrides of default config files, it seems we would need
> the puppet provisioner in vagrant?
>
>
> On 2/5/13 6:49 PM, "Rohit Yadav" <bh...@apache.org> wrote:
>
>>I'm not sure it applies, I did not copy them, veewee generates the
>>definitions for you which are like stubs and you modify the
>>definitions as per your needs. MIT should be compatible with APL?
>>Besides, we're not including veewee in our codebase, they are just
>>config files for veewee.
>>
>>This is not something new, we've veewee definitions in
>>tools/devcloud/src/deps/boxes for devcloud etc. If this is an issue,
>>we need to fix it there as well.
>>
>>Regards.
>>
>>On Wed, Feb 6, 2013 at 5:24 AM, Chiradeep Vittal
>><Ch...@citrix.com> wrote:
>>> What I meant was to
>>> - retain the MIT license and not change the license
>>> - maintain in our repo.
>>> - optionally recognize the provenance (either in NOTICE or in the
>>> directory)
>>>
>>> On 2/5/13 1:44 PM, "Chip Childers" <ch...@sungard.com> wrote:
>>>
>>>>On Tue, Feb 5, 2013 at 2:34 PM, Chiradeep Vittal
>>>><Ch...@citrix.com> wrote:
>>>>> Rohit,
>>>>> I see that you have followed the code from
>>>>>
>>>>>https://github.com/jedi4ever/veewee/tree/master/templates/Debian-7.0-b4
>>>>>-i
>>>>>38
>>>>> 6-netboot
>>>>>
>>>>>
>>>>> Since that code is under MIT license:
>>>>> https://github.com/jedi4ever/veewee/blob/master/License
>>>>>
>>>>>
>>>>> I think we should not check it in or reproduce the MIT license.
>>>>
>>>>Just to be clear, by "reproduce", are you suggesting that we include
>>>>the legal docs for this? (assuming that we want to keep it in the
>>>>repo, which I'm personally a +1 on)
>>>>
>>>>> On 2/5/13 4:24 AM, "Rohit Yadav" <bh...@apache.org> wrote:
>>>>>
>>>>>>Just wanted to share some wip, based on the way we can build devcloud
>>>>>>and basebox appliance, I've added a template systemvm appliance which
>>>>>>can be built using veewee and currently has VMDK disk image format.
>>>>>>It's based on Debian b4-i386, has 256MB ram and 2GB HDD. The built
>>>>>>vbox disk can be exported as ova, raw disk image, qcow2 etc.
>>>>>>I've put it under tools/appliance. Maybe we should move our appliance
>>>>>>building code which is in tools/devcloud/src to tools/appliance? Pl.
>>>>>>feel free to hack on it, update the README and scripts.
>>>>>>
>>>>>>We now just need to port the patches/systemvm/debian/buildsystemvm.sh
>>>>>>to tools/appliance/definitions/systemvmtemplate/base.sh and add
>>>>>>cleanup code.
>>>>>>
>>>>>> - Install [RVM](https://rvm.io/rvm/install)
>>>>>> - Setup paths: export PATH=~/.rvm/bin:$PATH
>>>>>> - Install Ruby 1.9.3, if it installed some other version: rvm install
>>>>>>1.9.3
>>>>>>
>>>>>>cd tools/appliance
>>>>>>veewee vbox list
>>>>>>(Modify scripts in definitions/systemvmtemplate/ as per needs)
>>>>>>veewee vbox build 'systemvmtemplate'
>>>>>>veewee vbox up 'systemvmtemplate' # start the box
>>>>>>
>>>>>>Regards.
>>>>>
>>>>>
>>>
>
Re: Building SystemVM template appliance
Posted by Chiradeep Vittal <Ch...@citrix.com>.
It is confusing -- gaah.
I could be persuaded that it could be licensed as Apache. But IANAL and we
went through the legal wringer already on this in Aug/Sep.
To build the actual systemvm, I would call another helper script in post
install: cloudstack.sh which replicates the packages() function in
buildsystemvm.sh
To perform the overrides of default config files, it seems we would need
the puppet provisioner in vagrant?
On 2/5/13 6:49 PM, "Rohit Yadav" <bh...@apache.org> wrote:
>I'm not sure it applies, I did not copy them, veewee generates the
>definitions for you which are like stubs and you modify the
>definitions as per your needs. MIT should be compatible with APL?
>Besides, we're not including veewee in our codebase, they are just
>config files for veewee.
>
>This is not something new, we've veewee definitions in
>tools/devcloud/src/deps/boxes for devcloud etc. If this is an issue,
>we need to fix it there as well.
>
>Regards.
>
>On Wed, Feb 6, 2013 at 5:24 AM, Chiradeep Vittal
><Ch...@citrix.com> wrote:
>> What I meant was to
>> - retain the MIT license and not change the license
>> - maintain in our repo.
>> - optionally recognize the provenance (either in NOTICE or in the
>> directory)
>>
>> On 2/5/13 1:44 PM, "Chip Childers" <ch...@sungard.com> wrote:
>>
>>>On Tue, Feb 5, 2013 at 2:34 PM, Chiradeep Vittal
>>><Ch...@citrix.com> wrote:
>>>> Rohit,
>>>> I see that you have followed the code from
>>>>
>>>>https://github.com/jedi4ever/veewee/tree/master/templates/Debian-7.0-b4
>>>>-i
>>>>38
>>>> 6-netboot
>>>>
>>>>
>>>> Since that code is under MIT license:
>>>> https://github.com/jedi4ever/veewee/blob/master/License
>>>>
>>>>
>>>> I think we should not check it in or reproduce the MIT license.
>>>
>>>Just to be clear, by "reproduce", are you suggesting that we include
>>>the legal docs for this? (assuming that we want to keep it in the
>>>repo, which I'm personally a +1 on)
>>>
>>>> On 2/5/13 4:24 AM, "Rohit Yadav" <bh...@apache.org> wrote:
>>>>
>>>>>Just wanted to share some wip, based on the way we can build devcloud
>>>>>and basebox appliance, I've added a template systemvm appliance which
>>>>>can be built using veewee and currently has VMDK disk image format.
>>>>>It's based on Debian b4-i386, has 256MB ram and 2GB HDD. The built
>>>>>vbox disk can be exported as ova, raw disk image, qcow2 etc.
>>>>>I've put it under tools/appliance. Maybe we should move our appliance
>>>>>building code which is in tools/devcloud/src to tools/appliance? Pl.
>>>>>feel free to hack on it, update the README and scripts.
>>>>>
>>>>>We now just need to port the patches/systemvm/debian/buildsystemvm.sh
>>>>>to tools/appliance/definitions/systemvmtemplate/base.sh and add
>>>>>cleanup code.
>>>>>
>>>>> - Install [RVM](https://rvm.io/rvm/install)
>>>>> - Setup paths: export PATH=~/.rvm/bin:$PATH
>>>>> - Install Ruby 1.9.3, if it installed some other version: rvm install
>>>>>1.9.3
>>>>>
>>>>>cd tools/appliance
>>>>>veewee vbox list
>>>>>(Modify scripts in definitions/systemvmtemplate/ as per needs)
>>>>>veewee vbox build 'systemvmtemplate'
>>>>>veewee vbox up 'systemvmtemplate' # start the box
>>>>>
>>>>>Regards.
>>>>
>>>>
>>
Re: Building SystemVM template appliance
Posted by Rohit Yadav <bh...@apache.org>.
I'm not sure it applies, I did not copy them, veewee generates the
definitions for you which are like stubs and you modify the
definitions as per your needs. MIT should be compatible with APL?
Besides, we're not including veewee in our codebase, they are just
config files for veewee.
This is not something new, we've veewee definitions in
tools/devcloud/src/deps/boxes for devcloud etc. If this is an issue,
we need to fix it there as well.
Regards.
On Wed, Feb 6, 2013 at 5:24 AM, Chiradeep Vittal
<Ch...@citrix.com> wrote:
> What I meant was to
> - retain the MIT license and not change the license
> - maintain in our repo.
> - optionally recognize the provenance (either in NOTICE or in the
> directory)
>
> On 2/5/13 1:44 PM, "Chip Childers" <ch...@sungard.com> wrote:
>
>>On Tue, Feb 5, 2013 at 2:34 PM, Chiradeep Vittal
>><Ch...@citrix.com> wrote:
>>> Rohit,
>>> I see that you have followed the code from
>>>
>>>https://github.com/jedi4ever/veewee/tree/master/templates/Debian-7.0-b4-i
>>>38
>>> 6-netboot
>>>
>>>
>>> Since that code is under MIT license:
>>> https://github.com/jedi4ever/veewee/blob/master/License
>>>
>>>
>>> I think we should not check it in or reproduce the MIT license.
>>
>>Just to be clear, by "reproduce", are you suggesting that we include
>>the legal docs for this? (assuming that we want to keep it in the
>>repo, which I'm personally a +1 on)
>>
>>> On 2/5/13 4:24 AM, "Rohit Yadav" <bh...@apache.org> wrote:
>>>
>>>>Just wanted to share some wip, based on the way we can build devcloud
>>>>and basebox appliance, I've added a template systemvm appliance which
>>>>can be built using veewee and currently has VMDK disk image format.
>>>>It's based on Debian b4-i386, has 256MB ram and 2GB HDD. The built
>>>>vbox disk can be exported as ova, raw disk image, qcow2 etc.
>>>>I've put it under tools/appliance. Maybe we should move our appliance
>>>>building code which is in tools/devcloud/src to tools/appliance? Pl.
>>>>feel free to hack on it, update the README and scripts.
>>>>
>>>>We now just need to port the patches/systemvm/debian/buildsystemvm.sh
>>>>to tools/appliance/definitions/systemvmtemplate/base.sh and add
>>>>cleanup code.
>>>>
>>>> - Install [RVM](https://rvm.io/rvm/install)
>>>> - Setup paths: export PATH=~/.rvm/bin:$PATH
>>>> - Install Ruby 1.9.3, if it installed some other version: rvm install
>>>>1.9.3
>>>>
>>>>cd tools/appliance
>>>>veewee vbox list
>>>>(Modify scripts in definitions/systemvmtemplate/ as per needs)
>>>>veewee vbox build 'systemvmtemplate'
>>>>veewee vbox up 'systemvmtemplate' # start the box
>>>>
>>>>Regards.
>>>
>>>
>
Re: Building SystemVM template appliance
Posted by Chiradeep Vittal <Ch...@citrix.com>.
What I meant was to
- retain the MIT license and not change the license
- maintain in our repo.
- optionally recognize the provenance (either in NOTICE or in the
directory)
On 2/5/13 1:44 PM, "Chip Childers" <ch...@sungard.com> wrote:
>On Tue, Feb 5, 2013 at 2:34 PM, Chiradeep Vittal
><Ch...@citrix.com> wrote:
>> Rohit,
>> I see that you have followed the code from
>>
>>https://github.com/jedi4ever/veewee/tree/master/templates/Debian-7.0-b4-i
>>38
>> 6-netboot
>>
>>
>> Since that code is under MIT license:
>> https://github.com/jedi4ever/veewee/blob/master/License
>>
>>
>> I think we should not check it in or reproduce the MIT license.
>
>Just to be clear, by "reproduce", are you suggesting that we include
>the legal docs for this? (assuming that we want to keep it in the
>repo, which I'm personally a +1 on)
>
>> On 2/5/13 4:24 AM, "Rohit Yadav" <bh...@apache.org> wrote:
>>
>>>Just wanted to share some wip, based on the way we can build devcloud
>>>and basebox appliance, I've added a template systemvm appliance which
>>>can be built using veewee and currently has VMDK disk image format.
>>>It's based on Debian b4-i386, has 256MB ram and 2GB HDD. The built
>>>vbox disk can be exported as ova, raw disk image, qcow2 etc.
>>>I've put it under tools/appliance. Maybe we should move our appliance
>>>building code which is in tools/devcloud/src to tools/appliance? Pl.
>>>feel free to hack on it, update the README and scripts.
>>>
>>>We now just need to port the patches/systemvm/debian/buildsystemvm.sh
>>>to tools/appliance/definitions/systemvmtemplate/base.sh and add
>>>cleanup code.
>>>
>>> - Install [RVM](https://rvm.io/rvm/install)
>>> - Setup paths: export PATH=~/.rvm/bin:$PATH
>>> - Install Ruby 1.9.3, if it installed some other version: rvm install
>>>1.9.3
>>>
>>>cd tools/appliance
>>>veewee vbox list
>>>(Modify scripts in definitions/systemvmtemplate/ as per needs)
>>>veewee vbox build 'systemvmtemplate'
>>>veewee vbox up 'systemvmtemplate' # start the box
>>>
>>>Regards.
>>
>>
Re: Building SystemVM template appliance
Posted by Chip Childers <ch...@sungard.com>.
On Tue, Feb 5, 2013 at 2:34 PM, Chiradeep Vittal
<Ch...@citrix.com> wrote:
> Rohit,
> I see that you have followed the code from
> https://github.com/jedi4ever/veewee/tree/master/templates/Debian-7.0-b4-i38
> 6-netboot
>
>
> Since that code is under MIT license:
> https://github.com/jedi4ever/veewee/blob/master/License
>
>
> I think we should not check it in or reproduce the MIT license.
Just to be clear, by "reproduce", are you suggesting that we include
the legal docs for this? (assuming that we want to keep it in the
repo, which I'm personally a +1 on)
> On 2/5/13 4:24 AM, "Rohit Yadav" <bh...@apache.org> wrote:
>
>>Just wanted to share some wip, based on the way we can build devcloud
>>and basebox appliance, I've added a template systemvm appliance which
>>can be built using veewee and currently has VMDK disk image format.
>>It's based on Debian b4-i386, has 256MB ram and 2GB HDD. The built
>>vbox disk can be exported as ova, raw disk image, qcow2 etc.
>>I've put it under tools/appliance. Maybe we should move our appliance
>>building code which is in tools/devcloud/src to tools/appliance? Pl.
>>feel free to hack on it, update the README and scripts.
>>
>>We now just need to port the patches/systemvm/debian/buildsystemvm.sh
>>to tools/appliance/definitions/systemvmtemplate/base.sh and add
>>cleanup code.
>>
>> - Install [RVM](https://rvm.io/rvm/install)
>> - Setup paths: export PATH=~/.rvm/bin:$PATH
>> - Install Ruby 1.9.3, if it installed some other version: rvm install
>>1.9.3
>>
>>cd tools/appliance
>>veewee vbox list
>>(Modify scripts in definitions/systemvmtemplate/ as per needs)
>>veewee vbox build 'systemvmtemplate'
>>veewee vbox up 'systemvmtemplate' # start the box
>>
>>Regards.
>
>
Re: Building SystemVM template appliance
Posted by Chiradeep Vittal <Ch...@citrix.com>.
Rohit,
I see that you have followed the code from
https://github.com/jedi4ever/veewee/tree/master/templates/Debian-7.0-b4-i38
6-netboot
Since that code is under MIT license:
https://github.com/jedi4ever/veewee/blob/master/License
I think we should not check it in or reproduce the MIT license.
On 2/5/13 4:24 AM, "Rohit Yadav" <bh...@apache.org> wrote:
>Just wanted to share some wip, based on the way we can build devcloud
>and basebox appliance, I've added a template systemvm appliance which
>can be built using veewee and currently has VMDK disk image format.
>It's based on Debian b4-i386, has 256MB ram and 2GB HDD. The built
>vbox disk can be exported as ova, raw disk image, qcow2 etc.
>I've put it under tools/appliance. Maybe we should move our appliance
>building code which is in tools/devcloud/src to tools/appliance? Pl.
>feel free to hack on it, update the README and scripts.
>
>We now just need to port the patches/systemvm/debian/buildsystemvm.sh
>to tools/appliance/definitions/systemvmtemplate/base.sh and add
>cleanup code.
>
> - Install [RVM](https://rvm.io/rvm/install)
> - Setup paths: export PATH=~/.rvm/bin:$PATH
> - Install Ruby 1.9.3, if it installed some other version: rvm install
>1.9.3
>
>cd tools/appliance
>veewee vbox list
>(Modify scripts in definitions/systemvmtemplate/ as per needs)
>veewee vbox build 'systemvmtemplate'
>veewee vbox up 'systemvmtemplate' # start the box
>
>Regards.