On Tue, Mar 11, 2014 at 04:14:33PM +0000, Colin Walters wrote: > On Tue, Mar 11, 2014 at 9:33 AM, James Slagle <jslagle@xxxxxxxxxx> 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 How is it incompatible with packaging? The read only root support that already exists in Fedora today is what would be used. Do you specifically mean running yum update|install at runtime? Sure, that wouldn't work. But we'd still be in fact using packages to build the images themselves. I think it's fair to say it's incompatible with applying package updates via rpm/yum at runtime. > 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 All sounds good to me :). > > 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. How do the images get built? Can you use existing image building tools, or it something ostree specific? > > 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. Sure, that makes complete sense. I was trying to draw the parallel about how something like ostree might be used in TripleO specifically. And, that if you aren't in some fashion using support that exists in Heat/Nova to initiate your upgrades, then I don't really feel like that's "TripleO" at that point. I fully expect people to have many different solutions for how they upgrade, not all will be TripleO. -- -- James Slagle -- _______________________________________________ cloud mailing list cloud@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
