[CentOS-devel] ostree as a delivery model

[Colin Walters]

On Sat, Apr 5, 2014 at 12:28 PM, Les Mikesell <lesmikesell at gmail.com> 
wrote:
> 
> If you need that, you are probably already block-replicating.

Right; block replication has its advantages.  There's a lot of projects 
out there for this.  I know of a Fedora/Red Hat project around this a 
long time ago:
https://fedoraproject.org/wiki/StatelessLinux

The more modern version is the ChromiumOS updater, with its A/B 
partition scheme.  It's widely deployed in Google Chromebooks.

But OSTree is much more flexible than traditional block replication 
because:

1) It doesn't require doubling disk usage of the OS (the hardlinks 
deduplicate)
2) Even more crucially, it allows you the freedom to use whatever 
filesystem and block storage you want on each client.

For example, you can install the
"fedora-atomic/rawhide/x86_64/buildmaster/base/core" tree on one 
machine using plain ext4 with a single big /, and another on 
XFS-on-LVM, perhaps with thin provisioning if you like.

You can be confident that any thinp snapshots or whatever that you make 
won't be interfered with by OSTree.

 > But how
 > do you deal with the necessary differences in that case? There is
 > always some ugly overlap in software/system/local configuration that
 > is hard to abstract away.

This is another key point - in OSTree you have a writable /etc and 
/var.  In particular the fact that a 3 way merge is applied to /etc 
helps make the system "feel like" Unix, in contrast to more basic 
block-level systems which are unaware of the semantics of /etc.

> And yet none of them give you the ability to build/test one system,
> then let someone else duplicate it easily and track its tested
> updates.  Which is what pretty much everyone needs to do if they have
> multiple machines, and it would give people with no administration
> experience the ability to have machines with software managed by
> experts, almost for free.

The more I think about your suggestion the more it feels like the 
"staging" model, which is clearly widely used inside individual 
organizations.

Anyways, there's clearly a lot of ways to build, deploy, and manage 
systems =)  I think the rpm-ostree model is a unique middle ground 
between traditional packages on the client and image-based updates - 
not for everyone, but some here might be interested, and I'm happy to 
hear any other feedback!