On Tue, Mar 11, 2014 at 9:33 AM, James Slagle &lt;jslagle@redhat.com&gt; wrote:<br>
<blockquote type="cite"><div class="plaintext" style="white-space: pre-wrap;">
There are 2 image upgrade paths being pursued by TripleO. In both cases, the
end goal is to have your instances running with a read-only root partition
and your stateful data you need preserved mounted on a separate partition.</div></blockquote><div><br></div><div>Such a model is incompatible with packaging. &nbsp;In contrast, I think it's very important</div><div>to note that with OSTree your /etc and /var work (mostly) as they always have.</div><div><br></div><div>In fact, /etc is better since you now have "ostree admin config-diff", which</div><div>I always wanted from Unix myself.</div><div><br></div><blockquote type="cite"><div class="plaintext" style="white-space: pre-wrap;">The first upgrade path is updating your image id's in your heat template and
then doing a "heat stack-update" on a deployed TripleO stack. Heat sees that
you're requesting a new image, and triggers a Nova rebuild[1]. After the
reboot, the ephemeral partition is preserved for your stateful data.</div></blockquote><div><br></div><div>Right, this model makes a lot of sense in a cloud world. &nbsp;Configure stuff in /etc</div><div>via external templates or configuration management, and just drop out the</div><div>OS and redeploy the configuration.</div><div><br></div><blockquote type="cite"><div class="plaintext" style="white-space: pre-wrap;">The second path is for upgrades where you don't want to have to reboot, or
rebuild the whole instance to pick up a small change. You update the image id
in the heat template (somewhere, probably not the same spot as for the case
above). os-refresh-config, which actually runs every 5 minutes in the instance,
sees the Heat metadata change. It then operates on that change, by pulling down
the new image from glance, cracking it open, remounting root as rw, then
rsyncing the changes to the root partition, remounting root as ro, etc. </div></blockquote><div><br></div><div>OSTree is somewhat like this except:</div><div><br></div><div>0) It is fully atomic</div><div>1) We're not live-mutating your running filesystem (which can easily break things)</div><div>2) It knows about stuff like /boot and /etc and how to manage them</div><div>3) The updates work over plain HTTP, can be GPG signed, etc. just like packages</div><div><br></div><blockquote type="cite"><div class="plaintext" style="white-space: pre-wrap;">For ostree, I believe you can host the ostree repositories via http?  I'm
probably reaching here, but I suppose it might be possible for Nova to have a
rebuild implementation that used ostree, or even some type of glance backend or
"image type" that used ostree. </div></blockquote><div><br></div><div>There is the concept of a "repository" for OSTree - and it would really work best</div><div>when placed in an object store like Swift. &nbsp;I've been meaning to prototype out</div><div>an OSTree-Swift backend. &nbsp;But you can just use any static</div><div>webserver with whatever Unix file backend you want.</div><div><br></div><div>Then you have operating system images which have a particular version of a tree</div><div>stored in Glance.</div><div><br></div><blockquote type="cite"><div class="plaintext" style="white-space: pre-wrap;"> and not really using TripleO at that point, since
you wouldn't be using OpenStack services directly to do the upgrades.</div></blockquote><br><div>Bare metal upgrades without cloud infrastructure are absolutely a key use</div><div>case for OSTree.</div><div><br></div><div>It is designed for the same use cases as traditional packages - and more particularly</div><div>to *complement* traditional packages by fixing some of their weaknesses like</div><div>the lack of atomic updates.</div><div><br></div>