Subject: Re: [vserver] Roadmap and Future ...
From: Herbert Poetzl <herbert@13thfloor.at>
Date: Fri, 27 Feb 2009 13:48:05 +0100

On Fri, Feb 27, 2009 at 08:36:57AM +0000, Christoph Lukas wrote:
> Hi,

> Am Donnerstag, den 26.02.2009, 22:00 -0500 schrieb John A. Sullivan III:
> > On Fri, 2009-02-27 at 01:35 +0100, Herbert Poetzl wrote:
> > > On Thu, Feb 26, 2009 at 05:07:06PM -0500, John A. Sullivan III wrote:
> > > > On Thu, 2009-02-26 at 20:07 +0000, Ed W wrote:
> > > > > Herbert Poetzl wrote:

> > > > I believe Ed is giving some excellent guidance here.  

> > > > We are very impressed with the technology of the VServer project
> > > > but it does not project a very professional ethos, sometimes
> > > > comes across as a tad bit arrogant, and it's very hard to pick
> > > > up the project from scratch.

> > > okay, I would like to get into details here, especially
> > > the following points:

> > >  - does not project a very professional ethos
> > >  - comes across as a tad bit arrogant
> > >  - very hard to pick up from scratch

> > > could you (all) please elaborate on them, as I do not
> > > fully understand why that would be so ...

> > Ah, you mean I actually have to remember the history that led me to
> > the perception :) The last point is the easiest. We had planned on
> > using Xen for our large new project. On a lark, I took a look at
> > alternatives and stumbled across OpenVZ. That led me to this strange
> > but not very publicized beast named VServer.

> > Under the gun on a major deadline for a huge project already
> > running behind schedule and with funding delayed to hire the needed
> > resources so the team was stretched beyond productivity (sound
> > familiar - at least the last part!), we decided to make a major
> > technology change and pursue VServer because of its remarkably
> > efficient use of resources.

> > The challenge was where to start. Coming from a very different
> > virtualization perspective, I had to learn a new way with new tools.
> > There was a nice overview but how do I dive into the internals
> > and figure out how to adapt it to my environment. Much of the
> > documentation reflects being lost in your own context, i.e., it
> > makes perfect sense to you but not necessarily to someone who isn't
> > already very familiar with either VServer or kernel hacking - i.e.,
> > thinking like a developer and not an end user. Imagine someone
> > who is brand new to VServer and knows very little about kernel
> > internals trying to install on RedHat by going to the RedHat howto:
> > http://linux-vserver.org/Installation_on_Redhat or the Ubuntu howto:
> > http://linux-vserver.org/Installation_on_Ubuntu with statements
> > like: This is NOT COMPLETE -- remove this message when you get it to
> > work!

> We are using vserver as our main development virtualisation platform
> for our small two person software development company here. We are
> using it on our desktop and server systems. While the latter run
> Debian and have original Debian Vserver kernels running. Our desktops
> run Ubuntu which does not ship any Vserver kernel.

> Therefore every now and then when we decide to upgrade our desktops to
> a new ubuntu version I spend some time to adapt the vserver patches to
> a distribution kernel. This usually takes about 1 or 2 days of work
> and I never know if I will succeed or not.

> I know that Herbert votes for 'forget about the ubuntu kernel, take a
> vanilla kernel and patch that one'. 

this 'fact' is often cited out of context and without any
explanation _why_ I vote for that, so here they are:

 1) I haven't seen a distribution yet which 'requires'
    the kernel used/packaged with that distribution
    IIRC, there was a commitment that vanilla (kernel.org)
    kernels will _always_ be working on all major distros
    (and even if not, it's usually just a matter of disabling
    special service xy, if the driver/interface is not there)

 2) distributions have to satisfy a really broad spectrum
    of users, so their kernels tend to include the kitchensink
    which is usually fine for a desktop, but a maintainance
    and performance overhead for a server system
    (personally I advice everybody to custom tailor their
    kernels _once_ to each system/brand and then simply
    'maintain' that config with minimal efford)

 3) Linux-VServer development and testing happens on vanilla
    kernels, we do not have the man power to test for every
    distro around, and distributions tend to introduce subtle
    flaws and bugs when 'adapting' code (think ssl/ssh on
    debian :)

> But this is no real alternative for me for at least two reasons:

> 1) I never know if the Ubuntu system does need some of the ubuntu
>    kernel patches applied to work properly.

well, that is quite simple to test, isn't it?
build a kernel based on your current config, boot it
if everything works fine, start optimizing, if not
you know too

> 2) I don't want to have to care for security updates myself. 

mainline does most security updates faster than any
distribution, but besides that, in this case, you 
not only have to update the kernel, but also need to
update 'your' patch against it, where in the vanilla
case, you 'just' fetch the new patch from us

> My point is:

> I think for an average user it would be necessary to supply
> distribution patchsets; for a new user it would even be necessary to
> supply kernel packages. Although we are very happy with vserver this
> is the only reason I keep thinking about alternatives every now and
> then.

I completely agree that the 'new' user, and the person
interested in Linux-VServer, but not sure if it will
do what s/he want's will benefit from distro kernels
including Linux-VServer, but only if they actually work
out of the box (which seems to be a problem on some
distros, because the maintainer(s) are not really serious
about their job)

> I would agree that this is nothing which could be done by a two 
> person development team for all those distributions around. 
> But a least for ubuntu I could step in and:

> * prepare patches for the distribution kernels (although I am 
>   no kernel developer) but I would need someone to review these 
>   patches

that's a good start, but you also need to find someone
to do the testing, bug collecting and you need to feed
thos packages upstream (i.e. become an ubuntu maintainer)
otherwise folks will get the same thing as they have now
when they simply install a debian kernel

> * maintain the 'Installation on Ubuntu' wiki page

sounds great!

> at least as long as we are using vserver on Ubuntu. :)

of course ....

> And just let me say 'thanks for the great work'!

you're welcome!

thanks,
Herbert

> Cheers,
> Christoph