[CentOS-devel] ostree as a delivery model

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

On Fri, Apr 4, 2014 at 6:28 PM, Colin Walters <walters at verbum.org> wrote:
> >
>> - and be able to follow the updates after they have been
>> installed/blessed on the master.
> Right.
>>  This looks close, but not quite...
>> I think there should be a list of repositories that maintain the
>> packages in all the referenced versions,
> I'm not quite sure what you're suggesting here.  There are two kinds of
> repositories: yum and ostree.  When you say "maintain the packages" are
> you talking about "treecompose", i.e committing a set of RPM packages
> to an OSTree repository?

No, I don't see the point.   RPM packages are already a reasonable
distribution format.  Why not use them as is?   The missing part is
just the inability of yum to reproduce a known working set of package
versions on its own.

>>  and the main part would just
>> be a version-controlled package list and maybe some diffs/patches to
>> configurations.
> Right, that's what
> https://github.com/cgwalters/fedora-atomic/blob/master/products.json
> boils down to - it's a list of trees, each of which are composed of a
> set of packages.
> https://github.com/cgwalters/fedora-atomic/commit/cb3b741616b5d11a00950e8f616c03f998bd474d
> is a sample commit that added rpm-ostree to the trees shipped on each
> client.
> Another example is that if I decided tmux was awesome and everyone
> should have it, I could push:
> diff --git a/products.json b/products.json
> index ed99ccd..41133e9 100644
> --- a/products.json
> +++ b/products.json
> @@ -23,7 +23,8 @@
>      "packages": ["kernel", "rpm-ostree", "generic-release", "lvm2",
>     "btrfs-progs", "e2fsprogs", "xfsprogs",
> -        "rpm-ostree-public-gpg-key", "gnupg2"],
> +        "rpm-ostree-public-gpg-key", "gnupg2",
> +        "tmux"],
>      "postprocess": ["remove-root-password"],
> Conversely, I could remove it later, and it would disappear from the
> trees, and then vanish when client machines ran "rpm-ostree upgrade".
> This is a huge difference from traditional package management per
> client, where packages normally linger on unless explicitly removed.

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.

If yum/rpm aren't good enough to maintain machines they should be
fixed, not forked.   You just need something to get to the point where
yum works and the ability to track versions and deletions.

   Les Mikesell
     lesmikesell at gmail.com