Hi All I’ve been working with a few folk over the last few months to see if snaps (see [0]) 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 restarted. 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 [3]). 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 [1]) - enough to produce an all-in-one install which you can try on Ubuntu 16.04 using snap-test [2] 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! Cheers James [0] http://snapcraft.io [1] https://github.com/search?q=org%3Aopenstack+snap [2] https://github.com/openstack-snaps/snap-test [3] http://snapcraft.io/docs/reference/interfaces
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
