cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wido den Hollander <>
Subject Re: [ASFCS40] [DISCUSS] System VM strategy
Date Mon, 20 Aug 2012 22:09:37 GMT

On 08/21/2012 12:03 AM, Chiradeep Vittal wrote:
> On 8/20/12 2:55 PM, "Wido den Hollander" <> wrote:
>> On 08/20/2012 11:32 PM, Chiradeep Vittal wrote:
>>> On 8/14/12 10:33 PM, "Chiradeep Vittal" <>
>>> wrote:
>>>> On 8/14/12 6:20 AM, "Chip Childers" <> wrote:
>>>>> I'm trying to kick off conversation with this thread...
>>>>> I know that people have been looking at the System VM licensing and
>>>>> distribution issues from various angles, but I'm not sure we came to
>>>>> consensus on how to deal with the system VMs overall.
>>>>> AFAIK, we have two outstanding issues:
>>>>> 1 - We have a bunch of configuration / code in the patches folder of
>>>>> our source tree that *may* have licensing issues.
>>>> IANAL, but config files that do not have license text already should
>>>> not
>>>> have any issue?
>>>> Especially since there is no other way to configure the software?
>>>> About half the config files are original work (not derived), the rest
>>>> can
>>>> be supplied as patch files to the originals.
>>>> Not sure that supplying patches is any different from distributing
>>>> modified config files though.
>>>>> 2 - We need to initiate a request to ASF Legal for permission to
>>>>> distribute a system VM template (including the GPL OS and software)
>>>> >from ASF infrastructure, OR figure out how the community can
>>>>> distribute valid system VMs outside of ASF.
>>>> Wido has some good suggestions here:
>>>> 1. Host convenience binaries on say Sourceforge
>>>> 2. Supply the build script so that folks can build it themselves.
>>> Following up from the IRC discussion:
>>> 1. Regarding license of configuration files, I have raised an issue with
>>> Legal:
>>> 2. Regarding the iptables deb for fixing dhcp behavior for Ubuntu VMs, I
>>> have a proposal:
>>>      A. Since the system vm cannot be distributed, we will have to host
>>> it
>>> as a convenience binary somewhere. This hosted version can certainly
>>> have
>>> the DHCP fix
>>>      B. For those who want to build the system vm from scratch, they will
>>> not get the DHCP/iptables fix but are welcome to install the fix as a
>>> post-build procedure.
>> If they build the System VM from Ubuntu 12.04 they should have the DHCP
>> fix already?
> Probably, but not sure. Debian Wheezy should have it.
>> I can't find the thread where this was discussed in.
> See for example:
> ml
>> I still think we should make it easier for users to create a System VM.
>> Like I already said ( ), we should generate a couple
>> of DEB (or RPM) packages which you can install and turn your clean
>> install into a System VM. Something I want to take a look at post-4.0
>> Wido
> Where would the deb/rpm be? Distributed by Apache? Convenience repository?
> How would we version it or make changes in response to bug reports?

The packages can actually be build from the source while building 
CloudStack itself.

The source from the System VM will still be in the repository, a System 
VM does:
* Install the Agent with the NfsSecondaryResource instead of libvirt
* Install Apache and configure
* Change some sysctl settings

All those things can be done by deb files.

You'd end up with "cloud-systemvm" which depends on everything.

A bug report can be filed against the component "systemvm" and we can 
fix those in the repository.

Whenever the next release comes out the packages will contain those fixes.

The problem regarding the binary releases still remain.

I'm the co-owner of a dutch hosting company and I'd be more then willing 
to offer infrastructure to host an Debian mirror.

Might be going off-topic here, but a Debian repository would be really 
useful anyway:

deb 4.0 main

By adding that mirror people can do:
$ apt-get install cloud-agent

But for the system VM it would be:
$ apt-get install cloud-systemvm

The package would be served from the same repository build from the 
source repository during the debian packages build.


View raw message