On Thu, Apr 10, 2014 at 6:24 PM, Jaime Melis jmelis@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.