[CentOS-devel] ostree as a delivery model

Thu Apr 10 22:24:00 UTC 2014
Jaime Melis <jmelis at opennebula.org>

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). We don't exactly do this kind of things ourselves (the
OpenNebula team) very frequently but it's something that will definitely
benefit the cloud consumers.

> The commits can also be GPG signed.

Even better :)

> 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.
> 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. When you have a cloud service
composed of multiple roles, it is quite important that the nodes are exact
replicas, in order to be able to certify an application and to guarantee
that an upgrade will work. So actually what I want to prevent is the VM

> _______________________________________________
> CentOS-devel mailing list
> CentOS-devel at centos.org
> http://lists.centos.org/mailman/listinfo/centos-devel

Jaime Melis
Project Engineer
OpenNebula - Flexible Enterprise Cloud Made Simple
www.OpenNebula.org | jmelis at opennebula.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20140411/9b19ae0b/attachment-0005.html>