Hi guys, Forgive me for skipping the philosophical debate ;-) If I understand correctly ostree, it would help us in OpenNebula (and mainly the OpenNebula users) with a couple of challenges that arise somewhat frequently. The main advantage I see this solves, or at least helps greatly with, is certification of both physical and virtual platforms. First of all, by using ostree we can certify a specific CentOS OpenNebula deployment, and it also delivers a very flexible way of upgrading the frontend/worker nodes. The other issue is that we've seen a growing number of people using not only single VMs but multi-tiered services composed of multiple VMs. Handling upgrades and certifying applications to work with those VMs is a bit challenging, since all the images can be installed differently or can have different versions of the rpm packages. However with ostree I can imagine how it would be a very useful tool for service developers when developing/deploying/upgrading these environments. cheers, Jaime On Tue, Apr 8, 2014 at 4:07 PM, Mike Schmidt <mike.schmidt at intello.com>wrote: > I'm not going to get into the philosophical debate here, here's my totally > pragmatic viewpoint: > > Coming from an environment where we install hundreds of I'd guess you > could call them appliances, running centos5, I'd say at first glance > os-tree would provide a stable way to handle updates in the field (when we > switch to centos7 later this year), where we update both the os and our own > code, as well as all the supporting cast (bind, apache, etc) without too > much risk. And anyway, it fedora is anything to go by, centos7 will boot > much faster than centos5, which we are using currently. > > At the moment, we still use yum update, but it's not always safe, and we > end up with a variety of versions in the field. > > Oh, and, while I sympathize with many other sysadmins, what's one more > tool, if I don't have to write it myself and it does what I don' t have > today? I have at least three people full-time involved in keeping our sites > up to date; if I could just move one of them to other tasks, I win. > > > > On Tue, Apr 8, 2014 at 9:10 AM, Colin Walters <walters at verbum.org> wrote: > >> Hi George, >> >> On Tue, Apr 8, 2014 at 6:20 AM, George Dunlap <dunlapg at umich.edu> wrote: >> > >> > But coming back down from the ivory tower, >> >> Thanks for steering us back on track =) >> >> > So the question is whether these are worth the cost of having Yet >> > Another Tool. >> >> Right, that is a good way to put it. There's no question that >> rpm-ostree is another tool. However I do want to strongly emphasize >> something that's implicit in the "rpm-ostree" name: I see the ostree >> technology as joining an ecosystem, not as entirely replacing things. >> >> Concretely, on every rpm-ostree generated tree, "rpm -qa" works. Which >> if you think about it is a Big Deal - there's an incredible amount of >> tooling built up around RPM in this way. A simple example is: How do >> you report a bug? Well, Bugzilla only knows about RPMs. >> >> And more strongly than that, the rpm-ostree server side compose tooling >> *enforces* that you only put RPM-based content in there. >> >> (The OSTree side is just dumb filesystem replication, you could easily >> ship >> trees generated with a hybrid of RPM + say pip or bundler. I'd rather >> fix >> the RPM side to be capable of what people want from pip myself) >> >> > #1 may not be a killer feature for sysadmins in particular; they are >> > likely to figure out one setup and use it on their production systems. >> > It would probably be very much a feature for people who *develop* >> > these "images" however; and anything which makes it so that >> > development >> >> Right. "ostree admin switch" is not that interesting - yet. It does >> demonstrate that client systems *can* have choice of software, unlike >> many image based upgrade systems out there. But it will be far, far >> more interesting when rpm-ostree supports package installation on top, >> then it'll act like a rebase operation. >> >> > #2 is probably somewhat of an advantage; particularly if it means that >> > you can also atomically switch back to the previous version if it >> > turns out you've screwed something up. >> >> Exactly! You can, you always have two complete "trees" (kernel + >> /usr), that manifest as two bootloader entries. There is even now >> "rpm-ostree rollback": >> >> https://github.com/cgwalters/rpm-ostree/commit/441313f9ef4dca7f6e1c683dccc35043ea9c29ad >> > Whether these outweigh the disadvantage of having Yet Another Tool, I >> > can't really tell; but the ostree idea certainly seems to have merit, >> > and is at least worth considering. >> >> Thanks for the feedback! >> >> If anyone has a chance to try composing trees with rpm-ostree and runs >> into trouble, please don't hesitate to file github issues, or you can >> follow up here, or mail me directly if you prefer. >> >> >> >> _______________________________________________ >> CentOS-devel mailing list >> CentOS-devel at centos.org >> http://lists.centos.org/mailman/listinfo/centos-devel >> > > > > -- > > *Mike SCHMIDT * > > *CTO Intello Technologies Inc.**mike.schmidt at intello.com > <mike.schmidt at intello.com>* > > > > *Canada: 1-888-404-6261 x320 <1-888-404-6261%20x320> USA: 1-888-404-6268 > x320 <1-888-404-6268%20x320> Mobile: 514-409-6898 <514-409-6898> > www.intello.com <http://www.intello.com/>* > > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > > -- Jaime Melis Project Engineer OpenNebula - Flexible Enterprise Cloud Made Simple www.OpenNebula.org | jmelis at opennebula.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20140410/89d459a7/attachment-0007.html>