Man page for snappy

[Mark Shuttleworth]

On 31/08/15 22:02, Bill Merriam wrote:
> I tried "snappy help", I didn't think to try "snappy --help".

Good catch, we should make "snappy help" do the same thing as "snappy
--help" I bet you're not the only person to prefer that syntax!


> Part of my confusion was the snappy command is either used on a desktop
> to build snappy apps, or, as was my case, on a snappy appliance to
> install apps.

Yes. We're working on a new tool, called "snapcraft" that would be the
main way to build snaps, leaving snappy as the package-manager for
install and update and remove, effectively.


> I was thinking I was going to use the BBB to build snappy apps but I
> think I have that wrong.  I now think I am supposed to use a desktop
> system to build my app.  To distribute an appliance I would think I
> would want to move snappy and my app from the SDHC card to the eMMC on
> the BBB.

Today, it's a slightly awkward binary choice between "desktop" and
"snappy". If you install a desktop you get the nice property that
everything is easy and comfortable for development, but you don't have
the crisp transactional semantics of snappy. If you choose snappy, you
get transactionality and other nice properties, but it's uncomfortable
at the command line.

We're working to give you the best of both worlds in a single
experience, so you can hack away comfortably in a familiar desktop-like
space, but make snaps for transactional installation and removal.

Your description of having a "desktop" system but distributing a
"snappy" eMMC is about right.

> I have asked no questions so far.  I will ask one.  Should I build a
> "native snappy app" or build a docker image for it?

They are two different tools, with respective strengths and weaknesses.
Both are very relevant for modern applications.

Docker has the great strength of bringing a complete filesystem with the
application. If you dig into a docker image, you'll see it includes
(often by reference) a full filesystem, usually but not necessarily
Ubuntu. That means that you can decouple the OS of the device from the
OS of the app completely; if you have a CentOS app you can make a Docker
image of it and run it on Ubuntu. That's fantastically useful in many
cases. It has the downside of resulting in duplication of the entire OS
any time you have many apps with different OS layers, and requiring a
management strategy for the OS layer inside each Docker container. That
strategy might be as simple as "ignore the problem" or it might be complex.

Typically we would recommend Docker if you are building a large-scale
server farm for running big distributed fast-moving apps, where there
are few direct "users" other than the developers themselves. Docker
works really well with things like Mesos in that sense.

Docker works less well where you want to have a couple of apps that
"collaborate around the hardware". For example, say you want to have a
wifi AP and run a few apps on it. If those apps all need to share bits
of the hardware, it's much more convenient to think of them as "apps on
the same OS" rather than "VMs on the same machine".

Snappy has the great strength of loosely coupling the apps to a shared
OS filesystem. The loose coupling means you can upgrade the OS
filesystem separately from the app, without having to rebuild anything.
You can manage the OS filesystem separately from the apps.

Snappy uses the same kernel containment primitives as Docker but sets
things up differently to allow for "apps on the same OS" to be
comfortable. It's nice if there is consensus on the OS for the different
apps (since with snappy they don't bring their own OS like in Docker).
When you upgrade the OS in snappy, every app sees the upgrade. The apps
can thus be cleaner and smaller and more focused, and share things more
easily than they can with Docker.

So, in answer to your question, it depends quite substantially on:

 * the nature of the app (is it a big distributed app or a small
single-device app)
 * the nature of the developers (do they all want freedom to use
different OS's)
 * the way it will want to talk to other apps (will it want to share a
camera?)
 * the places it will be deployed ("farms of servers or single devices?")

Hope that's helpful!

> Can I run a VPN like openVPN or Strongswan on snappy?  What should I be
> reading to help me understand these issues?

Yes, this should be eminently doable.

In snappy, we think a lot about avoiding shared responsibilities, or
alternatively, defining lines of responsibility very clearly. Each
participant is definitively responsible for the things they are
responsible for, and they can therefore do whatever they need to do in
that domain without worrying about breaking anybody else. The hard work
there is for things where there is clearly sharing going on, which is
the base OS and the special snaps we call "frameworks" which can export
files or services or other capabilities to snaps.

Networking is an interesting area and I'd be keen to get your feedback
on these thoughts.

There is one and only one networking stack in snappy - there is one
routing table, all snaps share that, so it's by definition a shared
resource. Those are provided by the OS itself, or by framework snaps.

We probably want to have capabilities for snaps that want to monitor or
manipulate that networking stack, for example those which want to watch
or modify the routing table.

We may want to build some VPN capabilities into the core OS itself, if
they are consensually relevant. For example, if OpenVPN or StrongSWAN
are very widely used and interoperable, we may want to just turn those
on for everybody with a standardised way to configure them.

On the other hand, I see a lot of value in letting people package up a
new VPN system and shipping it as a snap framework. That way the system
is extensible for new innovations in VPN technology, or for companies
that sell implementations of VPN technology.

If you have a strong preference one way or the other, let us know!

Mark