On Thu, Apr 10, 2014 at 10:39 AM, Jaime Melis <jmelis at opennebula.org> wrote: > > First of all, by using ostree we can certify a specific CentOS > OpenNebula deployment, 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. The commits can also be GPG signed. > and it also delivers a very flexible way of upgrading the > frontend/worker nodes. Right. > > The other issue is that we've seen a growing number of people using > not only single VMs but multi-tiered services composed of multiple > VMs. Handling upgrades and certifying applications to work with those > VMs is a bit challenging, since all the images can be installed > differently or can have different versions of the rpm packages. Well, if the nodes are deployed using rpm-ostree in its current form, then they are immutable, so there's no ability for each VM to drift. Now, the question is, do you need the ability to have some different package versions per node? Then it's more complicated - you can generate *multiple* trees which share storage (both on the compose server and on clients). An example is, from: http://rpm-ostree.cloud.fedoraproject.org/composeui/#/ You can be running the "fedora-atomic/rawhide/x86_64/buildmaster/base/core" tree, and do: ostree admin switch fedora-atomic/rawhide/x86_64/buildmaster/server/docker-io Which does an atomic swap to that tree. This shows that OSTree is a *lot* more flexible than traditional image based systems where clients systems normally have no choice at all.