On Thu, Jul 5, 2012 at 2:35 PM, Chiradeep Vittal <chiradeep.vit...@citrix.com> wrote: > Ah, Wido puts it much better. David's email kind of alarmed me.
What did I say that alarmed you?? :) If it makes you feel better your email alarms me :) > > > On 7/5/12 7:24 AM, "Wido den Hollander" <w...@widodh.nl> wrote: > [snip] > >> >>I agree. In essence the System VM's are more (talking KVM-wise!) than a >>Debian installation with the Java agent running in them. > > In the future, there may be even be multiple system vm templates. T > >> >>Right now you have to download this weird qcow2 from the CS website, but >>that should be different I think: >> >>You set up CloudStack, configure your zone and then it will ask you to >>provide the System VM template. >> >>We can still provide a System VM template we build from scratch and put >>the image online somewhere, but users also have the freedom to upload >>their own. > > +1. A default systemvm template is very important. In fact for regression > tests, smoke tests etc, this would be used. > Also, most *users* of cloudstack would have very little idea on how to > roll their own systemvm. So the issue with a default systemVM is that Apache CloudStack can't distribute it. (unless we move to a BSD). Or at least - in their current form, Apache CloudStack can't distribute the systemVMs. Soooo what do we do? > > >> >>In the repository we should only keep what we really need. When building >>RPM's and Deb's we build the proper packages for Debian and Fedora which >>you can install and depend on everything you need. >> >>Those packages can install the correct init scripts which are needed for >>starting everything from the first time. >> >>These init script will mount the second disk in the System VM and >>retrieve all the relevant configuration from there. >> >>We should start with actually building .debs and .rpms for the System >>VM's and not have these scripts just floating around and magically >>finding their way into the System VM's. > > +1. Although this could take a long time and could gate the 4.0 release if > made a prerequisite. While .debs and .rpms are not necessarily mandates - what would we ship? We essentially can't ship a linux-based VM. > >> >>The scripts inside the repository will probably comply with the Apache >>License, although that's for KVM, I'm not sure about Xen. > > There's very little xen-specific stuff inside the vm. Some of it may > relate to xen-tools. That can be removed AFAIK, since it actually hinders > the xenserver upgrade process.
