TurnKey Linux's take on Ubuntu appliance development: KISS

[Andreas Heck]

Hi Liraz,

Am Dienstag, den 08.12.2009, 07:07 +0200 schrieb Liraz Siri: 
> We went through a similar stage in our thinking before we launched
> TurnKey Linux, but after working on a few prototype appliances it became
> clear that this approach added a large amount of unessential complexity
> to the development process. You have to think about:
> 
> * interaction between an infinite set of possible starting points and
>   your "appliance"

I don't see much of a problem here. Of course it should be possible to
remove an appliance package and have it restore all files it touched to
the state before it was installed and therefore it should create backups
of all those files before changing it.

And of course it is always best to start with a fresh Ubuntu install. If
an installation is messed up no ordinary package can fix that and so
can't do an appliance package.

> * interactions between incompatible appliance configurations including
>   how to test a combinatorial explosion of possible combinations.

This is a big misunderstanding. I don't want that the user can install
different appliance packages at the same time. Of course you can only
install exactly one package that provides an appliance of any type. I
see no sane way to combine different appliances without having a human
doing the integration and testing it.

> * how to synchronize appliance development with the development of the
>   underlying distribution. You are doing the work of a system
>   administrator, which usually waits until everything is stable to build
>   production systems out of your distribution.

You either wait for your target distributions release or you accept that you
might have to refine some things as the release day comes closer.
But that's the same as with ordinary packages.

> * how to safely update a system-level configuration that may have been
>   changed and tweaked since the user first installed it.

This is a big problem indeed and i don't see a perfect solution to that.
You could warn the user about those changes like normal packages do when
they upgrade their configuration files. But this might still be better than
to provide no upgrade solution at all.

I've read that in one of your forum threads you say that you think the best way to
upgrade is to backup your data and take it over to a new appliance. I totally agree.
Appliances should more or less be throw away software components and the only
thing users should really have to care is their data.

> * what the development cycle for this will look like.

Very similar to your own. Take an installed image and launch it in a hypervisor,
install your package on it, restore the image, refine and rebuild your package
and test again.

> Our conclusion was that the appliance as a package approach
> unnecessarily complicates all aspects of development. Complicated things
> are hard to understand. They're hard to develop, hard to maintain, hard
> to get right. You pay for complexity with reduced productivity, reduced
> reliability and reduced security.
> 
> So instead we decided to do the simplest thing that could possible work.
> In other words KISS - Keep It Simple Stupid.

I'm also all for simplicity. But I think there should be an easy and
reproducible way to build appliances and it would be highly desirable
if this was based on a default installation of Ubuntu server. This DOESN'T
HAVE to be packages necessarily. This should also be possible to do with TKLpatch with
which you are also moving into this direction of reproducible builds or
some other solution. I just think that then you will reinvent some kind of
a repository system and if you did that why not implement other package like
features like reverting this patch and patching the VM to become another kind
of appliance?

Is there a reason you can't base your appliances on a default Ubuntu image
and just pull in your infrastructure software that is common to all your
appliances?

> The appliance as a pre-integrated filesystem image is well proven
> approach followed by TurnKey Linux, SUSE Studio, rPath, JumpBox, and
> many other vendors you'll find in the VMWare Appliance Marketplace. We
> already know the pros and cons. It's simple and it works. Today.

I don't say this doesn't work and it definitely has its place. But I think
it's possible and desirable to allow users to just say
"Hey, I want this virtual/physical machine to be an appliance which does THAT"
and don't force them to download a huge file for every type of appliance
they want to try out. And since there needs to be some kind of "build system"
that creates the appliance images anyway, why not make it serve the users
directly?


Best regards,

Andreas