Re: Why the complex layout for the operating system?

[Colin Walters <walters verbum org>]

On Fri, 2013-06-14 at 19:18 +0200, Giovanni Campagna wrote:
> I just saw https://live.gnome.org/OSTree/DeploymentModel2, 

Glad you are looking at this!  I have been struggling with maintaining
what I see as the core ostree advantage of being independent
of the filesystem layout/block storage, while still preserving atomic
upgrades.

> and I
> noticed that despite the new deployment model, there is still a lot of
> complexity.

Oh yes =/

> Now, ostree is no longer meant to be parallel installed with existing
> distributions

That's true for *gnome-ostree*...currently.  First, there are still some
people who want to run bleeding edge GNOME on bare metal.  If someone
showed up and said they'd maintain the kernel and graphics stack and
stand up automated filesystem test suites and stuff to be sure we're not
shipping garbage that will corrupt people's rootfs, it'd be very
interesting to reconsider baremetal deployments.

But even more importantly, for me personally, I need to be able to run
RHEL6 for years to come.  For multiple reasons:

1) My day job involves RHEL6.  People pay for subscriptions to it.  I
   need to be able to test and fix it, and virtualization helps a lot, 
   but if I want to debug a virt-manager issue, all of a sudden I'm
   doing nested virt, and that sucks.
2) The gnome-ostree build system itself is targeted for RHEL6 as
   a build host, because that's what the GNOME servers run.  It's just
   easier if I can boot RHEL6 and test it directly.  Theoretically
   I could do builds inside a VM, but the gnome-ostree testsuite
   uses virtualization.

Now one thing I haven't mentioned here is a side project I've been
working on, which is sliding ostree underneath yum/rpm in Fedora.  I got
it to the point of booting:

http://fedorapeople.org/cgit/walters/public_git/fedora-ostree.git
http://people.gnome.org/~walters/Screenshot-gnome-ostree%20Virtual%20Machine-1.png

So basically I could run RHEL6 as a base system, and then install Fedora
19 or whatever inside /ostree/deploy/fedora.  There's *lots* to do to
make that work sanely; like changing yum to do yum --installroot and
create a new FS tree, then commit that into the local repo, instead
of mutating the running fs.  But it boots.

And that's a very compelling vision for me, where RHEL6 is the last
operating system I use that installs into the "real /"; I can
boot it when I need to, or I can boot Fedora, or I can (eventually)
boot gnome-ostree on baremetal.

>  (only virtual machines are supported), so there is space
> for a simpler solution if we control the root filesystem.

Given the above, I hope you understand the rationale behind the design.

There's one other problem with your proposal: I don't see how all of
those symbolic links can be swapped atomically.

The "OSTree 2.0" model not only allows swapping between previous/current
atomically, it allows atomic swaps between *arbitrary lists* of
deployments.  For example, suppose you want to keep the last 5
deployments instead of just the previous one.  That's now easy and
still atomic.