Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (athena.apache.org: domain of rohityadav89@gmail.com
 designates 209.85.210.169 as permitted sender)
MIME-Version: 1.0
Sender: rohityadav89@gmail.com
In-Reply-To: <CD39ACBC.72DC%chiradeep.vittal@citrix.com>
References: 
 <CANLSSBW-1e73nfQTnde_ZucVFmeBNVYgFv0=CXkeo6iDPj8iDg@mail.gmail.com>
 <CD39ACBC.72DC%chiradeep.vittal@citrix.com>
From: Rohit Yadav <bhaisaab@apache.org>
Date: Fri, 8 Feb 2013 08:57:21 +0530
Message-ID: 
 <CANLSSBU6igcx6zNSgbAs9RrNOEuwhNDP1XeJ-VTEVKi-miv+sA@mail.gmail.com>
Subject: Re: Building SystemVM template appliance
To: Chiradeep Vittal <Chiradeep.Vittal@citrix.com>
Cc: Chip Childers <chip.childers@sungard.com>,
	"cloudstack-dev@incubator.apache.org" <cloudstack-dev@incubator.apache.org>,
 Sheng Yang <Sheng.Yang@citrix.com>
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Feb 8, 2013 at 8:46 AM, Chiradeep Vittal
<Chiradeep.Vittal@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" <bhaisaab@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
>><Chiradeep.Vittal@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" <bhaisaab@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
>>>><Chiradeep.Vittal@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" <chip.childers@sungard.com> wrote:
>>>>>
>>>>>>On Tue, Feb 5, 2013 at 2:34 PM, Chiradeep Vittal
>>>>>><Chiradeep.Vittal@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" <bhaisaab@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.
>>>>>>>
>>>>>>>
>>>>>
>>>
>