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

[Scott Moser]

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

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
  https://coreos.com/docs/cluster-management/debugging/install-debugging-tools/
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