TurnKey Linux's take on Ubuntu appliance development: KISS

[Soren Hansen]

On Mon, Dec 07, 2009 at 11:12:04AM +0200, Alon Swartz wrote:
>> Could you elaborate on this a little bit? Lots of different ideas
>> have been tossed back and forth on various mailing lists, IRC and
>> other fora, so I'm not completely sure what you mean Debian packages
>> were not designed for.
> 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.

I disagree. There's nothing in the deb file format, nor the Debian
Policy that prevents this. It simply defines a very strict set of rules
for how it can be accomplished. I completely acknowledge, that there's a
/tradition/ in Debian for treating packages as platform building blocks
that the administrator is supposed to integrate with each other to form
a complete solution of some sort. I would love nothing more than to see
this change in Ubuntu. We've made some progress on the mail server
front, but I see no reason not to extend this much further.

> 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.

Indeed. That is exactly why we would add customisations to the packages
themselves, or extend packages to offer an interface for other packages
to change their configuration (like, e.g. postfix does it with
postconf). 

> Just to clear up any potential confusion, tklpatch isn't intended to
> patch packages or package contents. It's intended to patch the
> appliance by for example installing additional packages, changing the
> configuration of an existing package, installing adhoc scripts to
> /usr/local, etc.

I see.
 
> We love packages, but an appliance is a higher-level concept and it's
> important to understand that.

I realise that appliances are a higher-level concept. I just don't
(yet?) see why that necessarily means that appliance-related
customisations cannot live in the packages instead of being applied
out-of-band.

> For example, let's compare the LAMP stack with the MySQL appliance.
[...]
> LAMP stack and the MySQL appliance have very similar components, but
> different usage scenarios and hence - different configurations.

I don't see any reason why we couldn't ship both options in the mysql
package. We could default to the current default and add a low priority
debconf question asking which type you prefer and preseed that for the
appliances. That way, all logic pertaining to mysql is contained in the
mysql source package, but exposed to other entities for tweaking.

It takes a bit getting used to, but realising that /we/ (in the most
inclusive sence) control the /entire/ software stack. We don't need to
pursuade or argue with anyone but ourselves to make a change such as
this.

> If you try to do this sort of thing with packages you are going to
> either fail or be forced to add a tremendous amount of unnecessary
> complexity at the package level.

Just because you extend the package to support these two options,
doesn't mean that you have to extend it to support all sorts of odd
variants in between these two extremes. It doesn't have to be any more
complicated than what I outlined above.

Anything you have to patch out-of-band in an Ubuntu package for it to be
useful, I would consider a bug. Within reason, of course.

> Whenever a package is not supported in Ubuntu or worse, doesn't even
> exist as a Debian package, that makes it much more difficult to create
> and maintain appliances.

Definitely. For anything to be even considered an "official" Ubuntu
appliance, it would have to consist only of software available as
packages in the repository. It is the only way we can reasonably support
anything.

> We don't have the resources to package all of this software ourselves
> in our own repositories, so we've done that only for very popular
> software packages such as Joomla.

I would love to see a Joomla package in Ubuntu. In fact, I would love to
see any and all the software you've appliancified as packages in Ubuntu.
I think appliances should be a convenient way to deploy certain software
stacks, not the /only/ way to deploy it.

Have you usually found the dependencies of your software to be met, or
do you usually have to install extra Perl, PHP, or Python modules to
meet the needs of the software you're turning into an appliance?

-- 
Soren Hansen                 | 
Lead virtualisation engineer | Ubuntu Server Team
Canonical Ltd.               | http://www.ubuntu.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20091214/60e7172a/attachment.pgp