[openstack-dev] [snaps] alternative distribution approach for OpenStack
james.page at ubuntu.com
Fri Jan 6 14:19:59 UTC 2017
I’ve been working with a few folk over the last few months to see if snaps
(see ) might be a good alternative approach to packaging and
distribution of OpenStack.
As OpenStack projects are Python based, producing snaps has been relatively
trivial with the snapcraft python plugin, which supports all of the tooling
that would be used in a deployment from source (pip, constraints etc…).
Thanks goes to Sam Yaple for his work on the Python plugin to support all
of the required features for snapping OpenStack!
The resulting snap for each project is self contained, with all required
dependencies baked into the snap, rather than using system provided
dependencies from the hosting operating system.
This means that the snap is directly aligned with each OpenStack project
from a software component perspective - avoiding the juggling act that
distro’s have to do each cycle to ensure the entire dependency chain for
OpenStack is lined up correctly.
Additionally, we can also include other non-Python dependencies in a snap -
for example the nova-hypervisor snap includes dnsmasq, ipset and
openvswitch tools built from source as part of the snap build process. I’d
envision extending that list to include libvirt (but that was a bit too
much to bite off in the first few cycles or work).
>From an operations perspective, snaps are transactionally applied on
installation, which means that if an upgrade fails, the snap will be rolled
back to the last known good version.
Installs and upgrades are also fast, as the snap internally is a read only
squashfs filesystem which is simply mounted alongside the existing
installed snap, daemons are stopped, pointers switched and daemons
Snaps typically run a confined environment, sandboxed using AppArmor and
Seccomp on Ubuntu. Snapd (the management daemon for snaps) provides a
number of interfaces to allow users to grant snaps permissions to perform
different operations on the host OS - for example network and firewall
control (the full interface list is much longer - see ).
We’ve leveraged (and contributed to) a number of these interfaces to
support the nova-hypervisor snap.
Snap confinement means that snaps don’t (by default) have access to /etc -
instead configuration is supplied in a snap specific location on the
filesystem (take a look in the README of a snap for how that works at a
high level). That location essentially mirrors /etc for the snap, which
should make adoption relatively easy for existing deployment tooling.
Snaps are also by design distro agnostic - so long as snapd has been ported
and the kernel version is sufficient to support the required security
features things should just work (but we’ve not tried that out just yet!).
We’ve snapped a few core components (see ) - enough to produce an
all-in-one install which you can try on Ubuntu 16.04 using snap-test  to
get a flavor of how things will look as this work develops further.
The source for each snap is being developed on OpenStack infra, however the
final build and publication to the snap store is being done on Launchpad
using git repo mirroring and automatic snap building on each change. This
includes arm64 and ppc64el architecture builds.
Updates are only pushed to the edge channel on the snapstore today - we’ll
need to figure out a good channel strategy as things mature to include
great CI/CD as well as concurrent support for multiple OpenStack releases.
Anyway - that’s probably enough words for now!
We’re all hanging out in #openstack-snaps on Freenode IRC so come find us
if you have any questions!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev