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.