F22 System Wide Change: RpmOstree - Server side composes and atomic upgrades

Colin Walters walters at verbum.org
Fri Jan 16 01:49:49 UTC 2015


Hi Kevin,

On Thu, Jan 15, 2015, at 05:20 PM, Kevin Kofler wrote:
>
> * customize your installation by adding/removing packages (and if it were
>   not prevented, the customizations would not persist across updates),

First of course, while that's accurate for the rpm-ostree technology
today, the Fedora Atomic Host pairs rpm-ostree with Docker, which
allows fully dynamic application installation.

It's also possible to use privileged containers to affect the host.

For the rpm-ostree side itself, a prototype of layered packages has existed for some time in
https://github.com/cgwalters/atomic-pkglayer
and will be much easier when rpm-ostree's libhif port lands.

> * update individual packages,
> * get new updates (including security fixes) as soon as they hit the
>   mirrors, without waiting for a new OS tree compose (every extra step in
>   the process unavoidably introduces a delay),
> * get individual packages from updates-testing or directly from Koji,
> * use packages from third-party repositories, unless they respin the entire
>   OS tree for you,

Note that an interesting aspect of rpm-ostree is it allows switching between
branches.  There is presently an updates-testing repository (same branch name)
for Fedora Atomic 21.

> * save bandwidth by downloading the packages that changed, or even only the
>   deltas of the actual change (delta RPMs),

With OSTree's "archive-z2" mode, it's one HTTP request per file changed.  In
some cases, this is equally or more efficient than even delta RPMs (if you look
at CPU and storage consumption).  Say for a package update where just one
translation file changed.  In some cases it's just OK, and in some
cases (e.g. boost-devel's over 9000 header files) it's catastrophically bad.   We
have "static deltas" in the works which will be a very significant improvement.

> etc.
> You gain… nothing!

Upgrades are atomic (press control-C when you want) and you can always
roll back to the previous tree.

Bear in mind that a dynamic Workstation scenario as you appear to
have primarily in mind is about the last targeted use case.  Beyond
the Atomic Host for Docker scenario, I am aiming for the tools to
be used in scenarios where you want to replicate an absolutely identical
software state across many nodes.  In that model, it's not Fedora
assembling the trees, it's the downstream user.


More information about the devel mailing list