[CentOS-devel] ostree as a delivery model

Fri Apr 11 00:36:25 UTC 2014
Colin Walters <walters at verbum.org>

On Thu, Apr 10, 2014 at 6:24 PM, Jaime Melis <jmelis at opennebula.org> 
wrote:
> Thanks for the further explanations Colin.
>  
>> Can you describe a bit more what you mean by certify?  Does that mean
>> for example running a validated set of packages and versions?  If so
>> then yes, OSTree allows you to say "we certify commit <sha256>" which
>> refers to a full filesystem tree, which was generated from a set of
>> packages.
> 
> Yes, that's exactly what I meant. That's kind f a great deal, because 
> we can just deliver as you say a full filesystem tree that is 
> guaranteed to work (certified).

Yep, exactly.

> I see, that's quite powerful. I initally meant the  having the exact 
> same package versions in all the nodes, so the ostree workflow would 
> be even simpler than that, if I understood correctly.

Right.  But I suspect you will have multiple trees, even if you want 
the same packageset on every client.  Because it's not just about 
content, but also about *versions*.  In reality, few operating system 
vendors have the luxury of just having exactly one release that 
everyone uses.  Google ChromiumOS is fairly unique in that respect.

CentOS obviously has several major versions, and I'm sure many system 
builders/administrators here also support multiple parallel versions.

This is where the ability of OSTree to switch dynamically back and 
forth between *arbitrary* trees I think is a major advantage over a lot 
of image-based update systems out there.  

The current fedora-atomic trees are all rawhide based, but let's fast 
forward a bit and say OSTree gets more integrated into Fedora release 
engineering, and we have:

fedora-atomic/22/x86_64/buildmaster/server/virthost

Now client systems can do:

ostree admin switch 
fedora-atomic/rawhide/x86_64/buildmaster/server/virthost
                                  ^^^^^^^

This retains the same semantic package set, but with newer versions.  
This would allow people to *try* new versions on staging servers, 
provide feedback, and where it gets really cool is that if something 
goes wrong, you still have the previous tree available to reboot into.  
"rpm-ostree rollback" on the client will undo the switch, and you'll be 
back to the original kernel and userspace versions you had, with total 
safety.  

Note: /var is shared and not rolled back - I think people providing 
operating systems need to clearly communicate when daemons/services 
perform forwards-only data migrations, like databases.