[CentOS-devel] ostree as a delivery model

Tue Apr 8 10:20:47 UTC 2014
George Dunlap <dunlapg at umich.edu>

On Mon, Apr 7, 2014 at 10:34 PM, Les Mikesell <lesmikesell at gmail.com> wrote:
> On Mon, Apr 7, 2014 at 4:25 PM, Stephen John Smoogen <smooge at gmail.com> wrote:
>> ... or I can get out of computers and
>> go into something more glacial paced like farming (which I have been very
>> tempted to do every 2-3 emails from Lennart P.). That is it and I am done
>> here unless there is something CentOS related.
> We aren't going to agree on anything here, but you obviously aren't
> following modern farming techniques where you find that not only are
> the practices from a few years ago obsolete but that they will
> probably give you cancer.   At least that hasn't happened yet with
> software obsolescence.

But coming back down from the ivory tower, it looks like the main
advantages put forward for ostree are:
1. Easy to switch between many different setups
2. "Atomic" updates: entire tree is changed on reboot, not piecemeal
as the RPMs are installed
3. A new tree is always an exact clone of the one in the repo (unlike
packages, which may diverge)
4. Doesn't need to re-calculate dependencies on every single host.

Adding in versioning or "list of packages" to yum may make some kinds
of deployment easier, but to make it achieve any of the things listed
above would not be so much "fixing" or "improving" yum / rpm as making
it into a different beast altogether; likely many people would not
want to use the new beast, and you'd have a fork anyway.

So the question is whether these are worth the cost of having Yet Another Tool.

#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

#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.

#3 is also probably an advantage: particularly if you're reporting a
bug and you want the developer to be able to reproduce your problem.

#4 isn't a killer advantage, but if it means smaller footprint and
faster deployment, it probably is an advantage.

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.