On Tue, Mar 11, 2014 at 9:33 AM, James Slagle <jslagle(a)redhat.com>
wrote:
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.
Such a model is incompatible with packaging. In contrast, I think it's
very important
to note that with OSTree your /etc and /var work (mostly) as they
always have.
In fact, /etc is better since you now have "ostree admin config-diff",
which
I always wanted from Unix myself.
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.
Right, this model makes a lot of sense in a cloud world. Configure
stuff in /etc
via external templates or configuration management, and just drop out
the
OS and redeploy the configuration.
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.
OSTree is somewhat like this except:
0) It is fully atomic
1) We're not live-mutating your running filesystem (which can easily
break things)
2) It knows about stuff like /boot and /etc and how to manage them
3) The updates work over plain HTTP, can be GPG signed, etc. just like
packages
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.
There is the concept of a "repository" for OSTree - and it would really
work best
when placed in an object store like Swift. I've been meaning to
prototype out
an OSTree-Swift backend. But you can just use any static
webserver with whatever Unix file backend you want.
Then you have operating system images which have a particular version
of a tree
stored in Glance.
and not really using TripleO at that point, since
you wouldn't be using OpenStack services directly to do the upgrades.
Bare metal upgrades without cloud infrastructure are absolutely a key
use
case for OSTree.
It is designed for the same use cases as traditional packages - and
more particularly
to *complement* traditional packages by fixing some of their weaknesses
like
the lack of atomic updates.