LWN: Comments on "Ubuntu Core and Snappy"

Ubuntu Core and Snappy

jspaleta — Mon, 02 Feb 2015 18:55:44 +0000

I think you have to look at the business model being spun up around the snappy transaction mechanism to understand why they aren't integrating this with apt at all, yet.

I think the business side of the house wants to control the app and system update pipeline directly and that influenced the technical choice to go off the reservation entirely and evolve away from deb based click packages without an integration point into apt for the new transactional stuff.

Canonical hasn't talked directly about the business model around snappy yet, it but there are hints in a lot of communications around snappy that snappy update transactions are going to be tied strongly to Canonical control deployment infrastructure.

For example, you might not be allowed to host your own local snappy repository for internal use without working contractually with Canonical to purchase a closed satellite appliance/image...bringing their build and deployment infrastructure into your network. Reference:
https://lists.ubuntu.com/archives/snappy-app-devel/2014-D...

The only code i've seen so far for snappy is the client side code. I've yet to find code or documentation which would help someone spin up a local snappy backend to serve up snaps that is not tied to Canonical's build system. Please if someone can point me to more information with regard to the snappy backend (not the client tool) that'd be great.

I'll be interesting to see if apt/dpkg will be made part of the core "snappy" images or if they will be left out entirely to avoid the complexity of users using traditional packages on a snappy system.

It will also be interesting to see how the juju charm writers handle the bifurcation of Ubuntu into a snap based and deb based "app" install mechanisms. Charms right now tend to hardwire apt mechanisms for application install. Will charms have to be duplicated and re-written for snap based Ubuntu images separate from apt based Ubuntu installs in the cloud?

-jef

Ubuntu Core and Snappy

dlang — Mon, 02 Feb 2015 18:36:24 +0000

The fact that they are not .deb updates, but are instead (roughly) filesystem snapshot diffs greatly reduces their value.

It means that you must install everything from their base image (no ability to harden/strip the system), and that anything that you install that's not part of that base image can't be maintained this way.

The idea of having two root partitions and switch between them for major updates is a good one. It is something that people should be doing a lot more than they are. But it doesn't require throwing out existing maintenance tools to accomplish.

Ubuntu Core and Snappy

rahulsundaram — Mon, 02 Feb 2015 15:59:14 +0000

Right but note that presence of rpm-ostree with plans to enable RPM style updates on a OSTree based system.

Ubuntu Core and Snappy

n8willis — Mon, 02 Feb 2015 15:45:49 +0000

replacing apt to do it rather than making it an option within normal apt updates.

Those working on the project would perhaps better address the details of this issue, but the snappy updates are not .Deb packages, so they would not be managed by Apt. AIUI, they're file-based diffs, akin to the filesystem-level changes you would see in OS Tree or other mechanisms.

Nate

Ubuntu Core and Snappy

dlang — Fri, 30 Jan 2015 06:32:02 +0000

I've used the dual root approach for major upgrades (but not every update) for several years, and it's saved me a lot of hassle. I build my bare metal systems with two small root partitions and a large var partition (and it's possible to preserve the contents of var so you can roll back with a little scripting to move /var/* to /var/oldvar)

I copied the concept from the way that Tivo does updates to it's DVRs.

The problem is that you have to reboot to switch between the two root images (and the software on them), so doing it for every patch seems like overkill in all but the most paranoid environments. And those paranoid environments should have redundant systems so that you can take one copy out of service, upgrade it and put it back in service (failing over to it if you have active/passive instead of N+m redundancy). Then if the new system fails you just switch back to the system that was working before the failover. This has the advantage that you have the failed system available to investigate and figure out what went wrong (including memory contents and system state that are lost if you reboot to another partition)

Great idea, I am disappointed that he's replacing apt to do it rather than making it an option within normal apt updates.

Ubuntu Core and Snappy

walters — Thu, 29 Jan 2015 15:35:48 +0000

For Project Atomic hosts, the actual OS content tends to be around 700-800MB. Though of course this varies significantly based on the input package set. If golang wasn't statically linked it'd be a lot smaller - the 5 Kubernetes binaries weigh in at 50MB alone.

Your 8.5GB number appears to be the default cloud image disk size, but if you use the Anaconda installer, you can choose any partition layout you want. This is a major technological difference between rpm-ostree and snappy; rpm-ostree is fully block layer independent, so it supports plain ext4/xfs, those on LVM, BTRFS, those on LUKS, etc.