You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Chip Childers <ch...@sungard.com> on 2012/08/14 15:20:41 UTC
[ASFCS40] [DISCUSS] System VM strategy
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.
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.
We also have floated the idea of enabling anyone to create a valid
system VM image, by defining the interface and operational
requirements (perhaps also by providing puppet configuration
manifests). I really like this idea, and some of the work required to
make that a possibility might be required to deal with ASF
restrictions, so options like that should be on the table as well.
Thoughts? Comments? (even solutions would be good... ;-) )
-chip
RE: [ASFCS40] [DISCUSS] System VM strategy
Posted by Alex Huang <Al...@citrix.com>.
>
> We also have floated the idea of enabling anyone to create a valid system
> VM image, by defining the interface and operational requirements (perhaps
> also by providing puppet configuration manifests). I really like this idea, and
> some of the work required to make that a possibility might be required to
> deal with ASF restrictions, so options like that should be on the table as well.
>
> Thoughts? Comments? (even solutions would be good... ;-) )
I am firmly in this camp. I believe this is what CloudStack is created to do but really have not done a very good job of to this date. Obviously, we can't do it by 4.0 but I believe we should do the following.
1. Define the current functions provided by CloudStack as Services. So that would be Virtual Routing Service, Template Service (SSVM), and Console Proxy Service. There will be more to come but that's for later.
2. Define that a service can be launch in three manners:
a. As a process auto-launched by the management server in a dev environment
b. As a process launched by the administrator
c. As a process running inside a Service VM (read current system vm) launched by cloud stack.
3. When the service completes boot process, it self-registers with a service directory (provided by cloudstack)
4. CloudStack can only utilize functions related to a service if the Service Directory has a service registered to use it. (In case c, cloudstack can decide at that time to auto-scale or let the admin scale the service vms. In cases a and b, there's no scaling).
5. The template for the Service VM will have the following properties
a. Should contain generic scripts to let it download and provision the service it is meant to deploy with from cloudstack.
b. Should be any linux based OS (too restrictive?)
c. may not be part of the deployment.
d. Can be put onto CS after CS starts by the administrator.
This has the following benefits.
- Decouple the VM OS from the Services provided.
- Allow others to add more services to CloudStack without need to understand the CloudStack code.
- Allow the VM OS to be deployed outside of the normal distribution as to not conflict with the licensing.
Please comment.
--Alex
Re: [ASFCS40] [DISCUSS] System VM strategy
Posted by David Nalley <da...@gnsa.us>.
On Mon, Aug 20, 2012 at 5:55 PM, Wido den Hollander <wi...@widodh.nl> wrote:
>
>
> On 08/20/2012 11:32 PM, Chiradeep Vittal wrote:
>>
>>
>>
>> On 8/14/12 10:33 PM, "Chiradeep Vittal" <Ch...@citrix.com>
>> wrote:
>>
>>>
>>>
>>> On 8/14/12 6:20 AM, "Chip Childers" <ch...@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?
>
> I can't find the thread where this was discussed in.
>
> 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
>
>>
>> --
>> Chiradeep
>>
>
Have we asked whether the project can distribute systemVMs? I was
under the impression we couldn't until the conversations at OSCON. Now
I think it might be possible.
But naturally we can't distribute prohibited items in our source release.
--David
Re: [ASFCS40] [DISCUSS] System VM strategy
Posted by Wido den Hollander <wi...@widodh.nl>.
On 08/21/2012 12:03 AM, Chiradeep Vittal wrote:
>
>
> On 8/20/12 2:55 PM, "Wido den Hollander" <wi...@widodh.nl> wrote:
>
>>
>>
>> On 08/20/2012 11:32 PM, Chiradeep Vittal wrote:
>>>
>>>
>>> On 8/14/12 10:33 PM, "Chiradeep Vittal" <Ch...@citrix.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On 8/14/12 6:20 AM, "Chip Childers" <ch...@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
Re: [ASFCS40] [DISCUSS] System VM strategy
Posted by Chiradeep Vittal <Ch...@citrix.com>.
On 8/20/12 2:55 PM, "Wido den Hollander" <wi...@widodh.nl> wrote:
>
>
>On 08/20/2012 11:32 PM, Chiradeep Vittal wrote:
>>
>>
>> On 8/14/12 10:33 PM, "Chiradeep Vittal" <Ch...@citrix.com>
>> wrote:
>>
>>>
>>>
>>> On 8/14/12 6:20 AM, "Chip Childers" <ch...@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?
Chiradeep
Re: [ASFCS40] [DISCUSS] System VM strategy
Posted by Wido den Hollander <wi...@widodh.nl>.
On 08/20/2012 11:32 PM, Chiradeep Vittal wrote:
>
>
> On 8/14/12 10:33 PM, "Chiradeep Vittal" <Ch...@citrix.com>
> wrote:
>
>>
>>
>> On 8/14/12 6:20 AM, "Chip Childers" <ch...@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?
I can't find the thread where this was discussed in.
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
>
> --
> Chiradeep
>
Re: [ASFCS40] [DISCUSS] System VM strategy
Posted by Chiradeep Vittal <Ch...@citrix.com>.
On 8/14/12 10:33 PM, "Chiradeep Vittal" <Ch...@citrix.com>
wrote:
>
>
>On 8/14/12 6:20 AM, "Chip Childers" <ch...@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.
--
Chiradeep
Re: [ASFCS40] [DISCUSS] System VM strategy
Posted by Chiradeep Vittal <Ch...@citrix.com>.
On 8/14/12 6:20 AM, "Chip Childers" <ch...@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.