TurnKey Linux's take on Ubuntu appliance development: KISS

[Andreas Heck]

Hi Alon,

I experimented with a package based approach for building appliances in
the last months and I also did some work on other related topics like
backup and web-based administration. Unfortunately I discovered your
project only about two weeks ago. You did a great job and considering
all the infrastructure and the huge number of appliances you already
have the only right thing is to work together and not duplicate any
efforts.

I'm thinking on how I can contribute best since I discovered your
project and therefore I'm very glad we're having this discussion.

Am Montag, den 07.12.2009, 11:12 +0200 schrieb Alon Swartz:
> What this means is that Debian packages were never designed for
> system-level integration. They're meant to be building blocks for a
> system administrator who then glues them together to integrate a
> production solution. An appliance is all about removing that last step.
> We're not competing with or displacing packages. We're just gluing them
> together to give the user a better starting point. The means selecting
> the components, configuring / integrating them to work together to
> provide the desired solution, and last but not least, testing the final
> result as a single unit.
>
> There's no elegant way to do that with packages / meta-packages
> precisely because they're not designed for this sort of thing. For
> example, according to the Debian Policy Manual a package is not allowed
> to edit configuration files of other packages.

There is no question that packages that create appliances and therefore
do integration of other packages are a very similar but still a
different concept than the "normal" software packages Debian uses for
ages. This means that if you use packages for packaging appliances you
cannot apply the same standards as you apply to normal packages (like
the Debian policy manual e.g.). This is also something I'm not perfectly
happy with, of course.

Nevertheless I still think it is a good idea to use packages for this
job. The only problem with packages I found so far apart from doing
things you wouldn't do in other packages is that you most often need to
seed your debconf database before you can install the metapackage that
creates the appliance by pulling in the right dependencies and
integrating them with the help of its maintainer scripts.

For the moment I solved this problem by putting a seed file into the
same directory of the repository as the metapackage and using a very
small wrapper script around apt-get to do the actual installation which
takes care of downloading and applying the seed file before the actual
installation takes place. Of course you might be more invasive and put
the file into the package and maybe even patch dpkg to recognize it or
use another wrapper the pulls the seed from the package.

To tell appliance packages from "normal" packages I just made them
provide a virtual package named "appliance".

I first came up with the idea when creating a GUI for vmbuilder. I did
some tab where you can select the packages that should be installed on
your new virtual machine and I thought it would be great if one could
just select an appliance from a list of appliances known to the system
as easily and make vmbuilder create it.

If you want to do stuff like that you come into a situation where you
reinvent some kind of a package system very quickly. This is because you
need to have some kind of repository where you can get a list of
available appliances from and you also need to be able to pull in the
integration code that creates the appliance on top of an existing
default installation of Ubuntu. And maybe you even want to turn your
appliance into a "normal" server again or turn it into a completely
different type of appliance.

This makes other interesting use cases possible, too. So you could just
put some appliances on the Ubuntu server CD and allow the user to select
one if he wishes this server to be an appliance in fashion very similar
to tasksel. It would also allow to take a virtual server as you can get
it for about 10€ per month and turn it into an appliance. We could even
create a nice looking GUI program where you select an appliance from a
list, provide your credentials, and the program than transforms your
cheap virtual your server into the appliance you wish.

Another point that makes packages seem very interesting to me is
updating. If you have an appliance and someone makes a bugfix to the
integration code you could use TKLpatch to apply it but as far as I
understand it you would still have to do that manually. With Debian
packages you could this automatically and with the normal update
procedures although you could get into troubles with conflicting
user-changed configurations with both approaches.


Best regards,

Andreas