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 x320USA: 1-888-404-6268 x320Mobile: 514-409-6898 www.intello.com <http://www.intello.com/>* -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20140408/da0de2ec/attachment-0007.html>