Hi George,

On Tue, Apr 8, 2014 at 6:20 AM, George Dunlap <dunlapg@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@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel