UEC prototype appliance [was: Re: moodle appliance update]

[Soren Hansen]

On Mon, Oct 05, 2009 at 05:17:55PM -0500, Dustin Kirkland wrote:
>> What happens to the Gobby document data when the instance is
>> terminated?
> This is unaccounted in the above referenced image.  I planned on
> documenting where the admin could find their gobby data in the
> filesystem, and recommend retrieving that before terminating an
> instance, or using shared storage instead.

a) It's an appliance. It's like a black box, and the only interface
should be through whatever application it provides. E.g. in the case of
a Gobby server, the only interface to the user and/or the owner should
be through the Gobby protocol, and in the case of a Wordpress appliance,
the only access to it should be through a web browser.  The fact that
there even is such a thing as a filesystem somewhere underneath it
should not be exposed to the user in any way.

b) "Terminating an instance" is not necessarily something you control.
Amazon reserves the right to terminate instances at will in a number of
different situations. 

In short: Persistent storage is essential.

> I understand from Thierry that I'm transferring the responsibility of
> constructing the virtual appliance prototype to you.  Is there
> anything you need from me at this point?

Off the top of my head, no.

> 2) I looked at Wordpress, since it's a totally open source stack,
> web-configurable, and well used throughout the Ubuntu world.  I
> decided against this one, due to the frequency of security updates
> necessary to apply to a running, internet-facing Wordpress instance.

It's very late in the process to solve this properly, but I do believe
that some sort automatic upgrade process (based on unattended-upgrades
configured to only pull from the security pocket) needs to be involved
going forward. These appliances will almost inevitable be exposing
services to the network and like to the internet at large, so this
concern is almost universally applicable.

> 3) I worked on Moodle quite a bit next, also because it's totally open
> source, web-configurable.  However, I learned that debconf-critical
> questions on package installation is generally difficult to handle in
> such an appliance.

The idea, back when I first looked into this, was to leverage the web
frontend for Debconf. This is sadly also out of scope by now, since it's
quite rough around the edges and needs a lot of work, all of which needs
to land in the Ubuntu repositories, so it's bound by the release
schedule. This needs another look for Lucid.

> One more comment, as an addendum.  Personally, I'm not a big fan of
> the tarball approach to appliance creation and deployment. 

Nor am I and have never been. The maintenance and storage overhead is
ridiculous.

> I think a smarter approach would consist of testing, certifying, and
> blessing a base UEC Ubuntu image, and providing a suite of appliances
> as basically meta packages, perhaps in a PPA, that install and
> configure whatever packages and services such appliances are defined
> to provide.  I would like to discuss such a concept further on this
> list, and perhaps at UDS as a blueprint.

The approach I was working on involved an (XML based) list of
appliances. You could basically think of an appliance as a 5-tuple:
(base ami id, packages to install, packages to remove, paths to persist
on an EBS volume, a script to run to set the last bits an pieces up). A
special client would be able to list these, start them up (setting up
EBS volumes in the process, and passing the necessary information in
user-data for ec2-init to handle), terminate them, and start them again
using the existing EBS volume. We will likely have a session at UDS
about the experiences with this and where to go from here.

-- 
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/20091006/7d09e99d/attachment.pgp