Fedora Atomic and Docker Host Image [was Re: Docker Host Image: Requirements?]

[Colin Walters]

On Tue, Mar 11, 2014 at 9:33 AM, James Slagle <jslagle at 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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/cloud/attachments/20140311/1483b409/attachment.html>