[CentOS-devel] ostree as a delivery model

Tue Apr 8 13:09:48 UTC 2014
Les Mikesell <lesmikesell at gmail.com>

On Tue, Apr 8, 2014 at 5:20 AM, George Dunlap <dunlapg at umich.edu> wrote:
>
> But coming back down from the ivory tower, it looks like the main
> advantages put forward for ostree are:

Is it fair to enumerate pros without mentioning any cons?

> 1. Easy to switch between many different setups

How easy?  Does this require learning another configuration language
and a staging box to build the image?  Do you need to keep a master
for every variation?    Is there a way to quantify the hard/easy
evaluation, say in terms of how much training it would take before
trusting someone to do it in a production setting?

> 2. "Atomic" updates: entire tree is changed on reboot, not piecemeal
> as the RPMs are installed

So, a reboot for every little change?  Now we might as well throw
clonezilla into the comparison (which I often use for initial
rollouts, but generally not updates).

> 3. A new tree is always an exact clone of the one in the repo (unlike
> packages, which may diverge)

So, some sort of post processing might be needed for the things that
can't be exact clones.

> 4. Doesn't need to re-calculate dependencies on every single host.

Seems minor compared to the downtime of a reboot.  And it might be
possible to make yum accept a list of already depsolved packages if
anyone really cared.

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

But it wouldn't need to be 'new' or break anything it already does.

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

So add in the con of needing to maintain the disk space of the new/old copies.

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

My servers take forever to reboot - if you have to do it for every
update it is not going to be faster in the long run.   And, you'll
need some sort of scheduling manager to control the rollout so not too
many instances are down at once - which will probably be different
than anything you already have.  In a VM environment things might be
different.

-- 
  Les Mikesell
    lesmikesell at gmail.com