[CentOS-devel] ostree as a delivery model

On Fri, Apr 4, 2014 at 11:42 PM, Les Mikesell <lesmikesell at gmail.com> 
wrote:
> 
> No, I don't see the point.   RPM packages are already a reasonable
> distribution format.  Why not use them as is?   

For one thing, you pay the cost of dependency resolution, downloading 
the entire repo metadata (in the case of Fedora, it's 18MB) per client.

It doesn't make sense to have a cluster of 1000 HPC nodes that you want 
to be identical each run through a satisfiability solver.  Or down to 
embedded devices - think cash registers.

Furthermore, the "pure replication" OSTree model enforces that the 
trees are *identical*.  It's fully atomic - if you pull the power, you 
either have the old system or the new system.  Achieving this on top of 
the traditional package model requires significant re-engineering 
around how the installation and things like %post work.

This doesn't mean that the traditional yum/apt-get model is bad - but I 
think the rpm-ostree model also makes sense for some use cases.  

It's going to get a lot more interesting once rpm-ostree supports 
package installation on top, then you're close to the best of both 
worlds.  (This requires the significant re-engineering mentioned above).

> That's not at all what I had in mind.  I'd like to see something where
> you just install a suitable set of packages on your own machine and
> run some program that publishes the list of package/versions you have
> installed.    And the matching client takes that list and feeds it to
> yum.   With repos that retain the packages as long as any published
> list references the package version - preferably with DNS round-robin
> instead of mirrorlists, so local proxy caches work sanely.   Season
> with something to diff/patch local modifications into configs and you
> should have reproducible machines.

I see.  Hmm...but can you track multiple lists?  Probably not, you'd 
get into a conflict mess.

Repositories of course are already package sets - things like comps 
groups (or metapackages) are the "list" aspect.

There's also Software Collections and Docker which allow parallel 
installation.

I understand your idea, but it feels like the above technologies 
overlap with it substantially.

> If yum/rpm aren't good enough to maintain machines they should be
> fixed, not forked.  

I wouldn't call ostree itself a fork of anything.

>  You just need something to get to the point where
> yum works and the ability to track versions and deletions.

I'd say it works today! It has a known quantity of strengths and 
weaknesses. "yum history" does track versions and deletions.  The hard 
part is addressing the weaknesses without breaking it =)

Now, rpm-ostree when it supports package installation on top will 
definitely compete with traditional package tools like yum, that's 
true. But the trajectory in Fedora was already towards dnf which uses 
new libraries like libsolv, hawkey, and librepo, that rpm-ostree will 
use as well.