[Beowulf] Docker vs KVM paper by IBM

[Andrew M.A. Cater]

On Wed, Jan 28, 2015 at 02:48:33PM -0500, Joe Landman wrote:
> 
> >
> >You do remember this is the Beowulf list, originally comprised of
> >researchers who decided to be their own sysadmins/hardware vendors/etc in
> >order to get their research done, right?
> >
> >Even in today's mainly post-big-iron age, there are plenty of
> >systems-level CS researchers (like I was not more than 6 months back) who
> >ran their own clusters simply to get their work done. No, I really don't
> >feel like working with my IT staff every time I want to change the
> >toolchain or recompile such-and-such magical cache replacement algorithm
> >into this version of the kernel. Imagine that.  I just want to do it.
> 

This resonates so clearly with me. I spend my life as a sysadmin/software consultant
to experts helping them get free software to work for them. Not fun when you've
got smart people fighting systems that have been provided for them - being in the middle
feels like being the grass pushing round a steamroller wheel :)

But THIS from you, is the key.


> This is in large part what is driving the whole concept.  Its hard enough to
> get updated drivers into specific types of clusters (the IT clusters
> commonly run with RHEL variants) ... imagine trying to replace a system
> level package for something that you need to support your work.  You don't
> need to be negotiating with the IT staff to make this change.
> 

The way (most) distributions work is too inflexible - system administrators
who can't sort stuff out because of paperwork / because it's "just too hard"
is the other part of the equation. 

So you end up with very knowledgeable users and programmers having to build
their own compilers and toolchains in the teeth of sysadmins who don't want
anyone to mess up their "supported systems as required by the service level
agreements" -- a recipe for hurt feelings all around

> FWIW:  this is one of the reasons we built our systems as being entirely PXE
> booted, and "auto configuring" upon startup.  Make it so that if you want
> to/have to make changes you can do it in a completely programmatically
> defined manner.  Make the substrate OS a simple function of the job launch.
> Though Docker will allow us to simplify this even more ... our substrate can
> be that much simpler ...
> 
> ... but this said, the OS/distro should not be an impediment to running
> code.  That Docker emerged and has caught fire is a testament to the fact
> that it generally *is* an impediment, and its sadly rare that you find
> things that just work right, out of the box/tarball without a dependency
> chain from hell to chase.
> 
> Large dependency radii suck. Docker (and VMs) let you contain this.
> 

but at the cost of "swan paddling away under the surface / special snowflake" 
levels of complexiy within the containerisation, potentially. There's no easy
squaring the circle here.

> >
> >I have no doubt there are tons of point-and-click researchers out there
> >who don't want to be sysadmins.  But making such broad strokes on this
> >list is asking for flames.
> 

Given there are only a few regular contributors, this is the corner of the
'Net where I come for extreme specialisation, clear definition clearly expressed
 and expertise,expertise, expertise. It's been this way for me for 20+ years, 
long may it continue. Thanks to all of you :)

Andy