RFC: Comfy - a CLI framework to bring the Ubuntu cloud feeling to snappy Ubuntu Core

Scott Moser scott.moser at canonical.com
Wed Jan 28 22:13:08 UTC 2015

On Tue, 13 Jan 2015, Alexander Sack wrote:

> Good morning all,
> we have been asked a few times about adding one or another tool to
> ubuntu-core to help you get your job done.
> To avoid making ubuntu-core overly heavy, what we thought we could put
> together a cli tool framework called 'comfy' that would bring the
> comfort and goodness we all learned to love from the default Ubuntu
> cloud install to snappy Ubuntu Core.
> We have looked into that and came up with an annotated diff of the
> packages in our core vs. cloud image as a starting point for a wider
> discussion on our mailing lists.
> The raw diff we used as a starting point to come up with the list
> below is in this paste: http://paste.ubuntu.com/9719652/.
> Please let us know if you feel something is missing or we currently
> have marked with 'Y' shouldn't be in such comfy framework. So here it
> is....

Replying to the top message in the thread, because I'm suggesting
something that might take this in a different way entirely.

I absolutely agree with the motivation behind 'comfy'.  I have a set of
cloud-init user-data that runs on all new instances and gives me some sane
set of tools.

It seems to me that the question:
  what function is comfy?
Is not all together much different from:
  what should be in Ubuntu Server by default.

After selecting this set of packages, we then have to manage to "snappify"
them all, and I don't think we have a magic bullet for that yet.  As
this package list grows, we all think "oh my... another package that we
have to maintain a relocatable build for".

Essentially, we have a *small* set of packages in Ubuntu Core (basically the
minimum we can get by with), and a *huge* set of packages in Ubuntu that
we'd like to magically be able to use whenever we need them.  We also have
a nice way of getting the package and its dependencies in 'apt-get' or

We've assumed that packages have to be re-built to run on top of a snappy
base.  They have to relocate themselves to no longer access files in / but
rather /apps/<app-name>/<version>/.

What if we relocated the *small* set, rather than the *huge* set?

If we could make the set of packages in snappy limit themselves to a small
set of paths, say: /snappy-core/{bin,lib,usr,var}
then we could run applications in a container with '/snappy-core' mounted
in.  The applications would live on the filesystem still under
/apps/<app-name> but whenever they were run, they'd think that
  /apps/app-name/lib was /lib
  /apps/app-name/bin was /bin

Then, creating (and maintaining) the ubuntu-server package set, or any
product you can get to build and install and run on ubuntu, means just
taking a tarball of that environment, and we already create those tarballs
for lxc consumption.

This is not significantly different than coreos's approach
they essentially let you get tools like 'tcpdump' by running a fedora
container that has those nice tools.

The issue with that approach, is that if your run a full container that
has '/lib', then you can't get to your "real /lib".  So you can't run (or
use) any of the programs or libraries that came with snappy.

My suggestion is to move the "real /lib" to /snappy/lib, and then the
container can have access to the entire filesystem without collisions.
When you run 'snappy' that is provided by ubuntu core, you'll pick it up
out of /snappy/bin the loader that loads it will be
/lib64/ld-linux-x86-64.so.2 .

What if, instead of assuming we have to make the *huge* relocate the
*huge* set of packages

More information about the snappy-devel mailing list