Response to smithj´s post regarding update schemes

smithj stated that my appliance update proposal rests on the assumption that configuration data can be easily separated from the operating system. This is true and I believe it is doable.

First, let me define what I mean by configuration. We do not have to treat all files in /etc as configuration data. For example, if my appliance ships with samba functionality, but it does not allow configuration of samba by the end user, then for all intents and purposes, from my appliance´s perspective, /etc/samba/smb.conf is not a configuration file. Configuration data corresponds only to settings that the ISV allows the end user to change. (This should be a very limited set by the way. If I had a hundred dials on my microwave oven, I´d never figure out how to use it. The same goes for TiVO--the limited number of user-configurable options works.)

The only configuration that an end user should be performing on an appliance is through the appliance web interface. Since the ISV has full control over all configuration data, it can choose to put it all in a database on a separate partition, which achieves the separation of configuration from the operating system.

smithj´s example of the end user needing to write a cron script is not realistic because most appliance users should not need to know what cron is. However, suppose that the ISV implemented scheduling capability based on cron and needed to configure cron dynamically. Then the ISV-provided program will need to store this configuration in its database for easy queryability, and then write a file out to /etc/cron.d/. These are things the program should do regardless. The only extra step that needs to be taken in the Amazon EC2 world is to redo the write out to /etc/cron.d/ on every reboot, which isn´t very hard. (Note that Amazon EC2´s root file system is not read-only, but you can think of it as a read-only operating system partition with a read-write tmpfs partition layered on top with UnionFS.)

In this world where the ISV manages all configurable data, why not maintain it in a separate location from the operating system and make upgrades as easy as swapping the OS image?

Two additional points to smithj:
- merges are nice in theory but bad in practice because in the event of a merge failure neither the end user nor the ISV has a tool to rectify it.
- you are not the target audience of an ISV. ;)