On 08/21/2012 12:03 AM, Chiradeep Vittal wrote:
On 8/20/12 2:55 PM, "Wido den Hollander" <w...@widodh.nl> wrote:
On 08/20/2012 11:32 PM, Chiradeep Vittal wrote:
On 8/14/12 10:33 PM, "Chiradeep Vittal" <chiradeep.vit...@citrix.com>
wrote:
On 8/14/12 6:20 AM, "Chip Childers" <chip.child...@sungard.com> 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 a
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:
http://goo.gl/EuUoQ
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: https://issues.apache.org/jira/browse/LEGAL-146
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:
http://www.mail-archive.com/cloudstack-dev@incubator.apache.org/msg03011.ht
ml
I still think we should make it easier for users to create a System VM.
Like I already said ( http://goo.gl/EuUoQ ), 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 http://debian.cloudstack.com/debian 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.
Wido