<div dir="ltr">Thanks for the further explanations Colin.<div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">


</div>Can you describe a bit more what you mean by certify?  Does that mean<br>
for example running a validated set of packages and versions?  If so<br>
then yes, OSTree allows you to say "we certify commit <sha256>" which<br>
refers to a full filesystem tree, which was generated from a set of<br>
packages.<br></blockquote><div><br></div><div>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.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The commits can also be GPG signed.<br></blockquote><div><br></div><div>Even better :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Well, if the nodes are deployed using rpm-ostree in its current form,<br>


then they are immutable, so there's no ability for each VM to drift.<br>
Now, the question is, do you need the ability to have some different<br>
package versions per node?  Then it's more complicated - you can<br>
generate *multiple* trees which share storage (both on the compose<br>
server and on clients).<br>
<br>
An example is, from:<br>
<a href="http://rpm-ostree.cloud.fedoraproject.org/composeui/#/" target="_blank">http://rpm-ostree.cloud.fedoraproject.org/composeui/#/</a><br>
<br>
You can be running the<br>
"fedora-atomic/rawhide/x86_64/buildmaster/base/core" tree, and do:<br>
<br>
ostree admin switch<br>
fedora-atomic/rawhide/x86_64/buildmaster/server/docker-io<br>
<br>
Which does an atomic swap to that tree.  This shows that OSTree is a<br>
*lot* more flexible than traditional image based systems where clients<br>
systems normally have no choice at all.<br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div>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 drift.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
<br>
<br>
_______________________________________________<br>
CentOS-devel mailing list<br>
<a href="mailto:CentOS-devel@centos.org">CentOS-devel@centos.org</a><br>
<a href="http://lists.centos.org/mailman/listinfo/centos-devel" target="_blank">http://lists.centos.org/mailman/listinfo/centos-devel</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><div>Jaime Melis<br>Project Engineer<br>OpenNebula - Flexible Enterprise Cloud Made Simple<br><a href="http://www.OpenNebula.org" target="_blank">www.OpenNebula.org</a> | <a href="mailto:jmelis@opennebula.org" target="_blank">jmelis@opennebula.org</a></div>

</div>
</div></div>