[CentOS-devel] ostree as a delivery model

Sat Apr 5 16:28:42 UTC 2014
Les Mikesell <lesmikesell at gmail.com>

On Sat, Apr 5, 2014 at 8:29 AM, Colin Walters <walters at verbum.org> 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.

OK, I don't mind my machines doing some work.  But if you didn't,
couldn't you push that part to a server with traditional caching of
query results?  And given that the point is to duplicate an existing
system the dependencies would already be known/solved anyway.

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

Maybe... I can't think of a machine that can do useful work that
couldn't compute its own dependencies, though.

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

If you need that, you are probably already block-replicating.  But how
do you deal with the necessary differences in that case?  There is
always some ugly overlap in software/system/local configuration that
is hard to abstract away.

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

If there is no need to learn a new and complex configuration tool,
anyone could produce the lists - so there would almost certainly be
one created for most useful configurations.

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

And yet none of them give you the ability to build/test one system,
then let someone else duplicate it easily and track its tested
updates.  Which is what pretty much everyone needs to do if they have
multiple machines, and it would give people with no administration
experience the ability to have machines with software managed by
experts, almost for free.

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

Well, if it doesn't use the same command structure and repositories to
install software I call it a fork.   Unless it is going to become the
only way to install software.

>>  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 =)

I doesn't work for me - now.

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

Yes,  Fedora always seems to start with the idea that everything that
anyone already knows how to use is wrong and needs to be replaced.
But I don't see the point of having a new abstraction that you have to
know in order to build a system and then reproduce it - which is
essentially just repeating the same thing.  I'd like to see something
that lets you build/test organically with traditional commands, then
publish the configuration in a way that can be re-used on top of
existing distribution infrastructure.  In fact I've always thought
that that should have been the goal of package management from the
time computers became cheap enough that someone might own two of them.
 And it should be particularly obvious to people working with version
control at the source level that you would want the same ability to
duplicate and track someone else's revision exactly for the binaries
too.   But instead, there are many arcane abstractions that try to
make it possible but that always involve leaning different concepts
and building different infrastructure to make it work, and crazy
things like making your own mirror of a repository just to control the
versions available to yum - for every state you'd want to reproduce.
 Stuff that no one would do to make one simple, working copy of
someone else's known-good system.

   Les Mikesell
     lesmikesell at gmail.com