[CentOS-devel] ostree as a delivery model

Tue Apr 8 13:10:58 UTC 2014
Colin Walters <walters at verbum.org>

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 
 trees generated with a hybrid of RPM + say pip or bundler.  I'd rather 
 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":
> 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.