rpm-ostree is the hybrid image/package system that provides transactional upgrades on Atomic Host. Here are some highlights from version v2017.4, as well as from earlier versions this year.
Deployment operations are now cumulative
Previously, if you wanted to both install a package and upgrade, you would have to do:
# rpm-ostree upgrade
# reboot
# rpm-ostree install foo
# reboot
Not very efficient. This was changed in v2017.2 so that operations became cumulative, thus only requiring one reboot:
# rpm-ostree upgrade
# rpm-ostree install foo
# reboot
This is much better, but it’s still causing rpm-ostree to create an intermediate deployment that soon after gets overwritten. In v2017.4, we can finally do these operations in a single step:
# rpm-ostree upgrade --install foo
# reboot
Of course, the same --install
and --uninstall
switches
are available on the deploy
and rebase
commands.
There is work underway to further improve on this and directly update the booted deployment, so that rebooting is no longer needed.
RPMs can now be directly installed
Previously, if you wanted to overlay a specific RPM file,
you’d have to shove it into a repo and place that repo in
/etc/yum.repos.d
. With v2017.4, rpm-ostree is now able to
install it directly:
# rpm-ostree install ltrace.rpm
# rpm-ostree status
State: idle
Deployments:
fedora-atomic:fedora-atomic/25/x86_64/docker-host
Version: 25.89 (2017-03-26 21:04:50)
BaseCommit: 6a71adb06bc296c19839e951c38dc0b71ee5d7...
OSName: fedora-atomic
LocalPackages: ltrace-0.7.91-20.fc25.x86_64
* fedora-atomic:fedora-atomic/25/x86_64/docker-host
Version: 25.89 (2017-03-26 21:04:50)
BaseCommit: 6a71adb06bc296c19839e951c38dc0b71ee5d7...
OSName: fedora-atomic
As you can see above, the package shows up in a new
LocalPackages
. This is different from LayeredPackages
:
packages in the latter are updated as new deployments are
created, whereas those in the former are never updated. So
in the example above, ltrace
will remain at that version.
You can always unstick
a local package and fetch it back
from the repos:
# rpm-ostree uninstall ltrace-0.7.91-20.fc25.x86_64 --install ltrace
# rpm-ostree status
State: idle
Deployments:
fedora-atomic:fedora-atomic/25/x86_64/docker-host
Version: 25.89 (2017-03-26 21:04:50)
BaseCommit: 6a71adb06bc296c19839e951c38dc0b71...
OSName: fedora-atomic
LayeredPackages: ltrace
* fedora-atomic:fedora-atomic/25/x86_64/docker-host
Version: 25.89 (2017-03-26 21:04:50)
BaseCommit: 6a71adb06bc296c19839e951c38dc0b71...
OSName: fedora-atomic
LocalPackages: ltrace-0.7.91-20.fc25.x86_64
Configuration can now be reloaded (v2017.3)
Previously, one had to restart the rpm-ostreed
service to
get it to notice new remotes or repo configuration changes.
Starting from v2017.3, there is now a rpm-ostree reload
command available to do this. System administrators might
prefer to use the equivalent systemctl reload rpm-ostreed
.
More powerful package layering semantics (v2017.3)
rpm-ostree is now much smarter about how it handles layered RPMs. Previously, one couldn’t add a package that already existed in the base layer. Additionally, previously layered packages would magically disappear if an update added that same package. If another update subsequently removed that package again, you’d be left without it layered at all.
Starting in v2017.3, rpm-ostree treats layered packages in a
more declarative manner; packages requested through the
install
command are interpreted as directives to ensure
they are always present. They will then be layered only when
needed (i.e. when the base layer does not already contain
it).
Suppose you’re on an ostree branch which has strace
but
doesn’t have ltrace
:
# rpm-ostree status
State: idle
Deployments:
* branch/without/ltrace
Timestamp: 2017-04-13 23:56:48
Commit: 5745788c0e6c07bed73864b6addd4823961...
OSName: fedora-atomic
# rpm -q strace ltrace
strace-4.16-1.fc25.x86_64
package ltrace is not installed
Imagine now that we want to make sure that strace
and
ltrace
are always installed:
# rpm-ostree install strace ltrace
# reboot
# rpm-ostree status
State: idle
Deployments:
* branch/without/ltrace
Timestamp: 2017-04-14 00:09:45
Commit: 5b338d0237a343201d6b277b58010241974...
OSName: fedora-atomic
RequestedPackages: strace
LayeredPackages: ltrace
branch/without/ltrace
Timestamp: 2017-04-13 23:56:48
Commit: 5745788c0e6c07bed73864b6addd4823961...
OSName: fedora-atomic
# rpm -q ltrace
ltrace-0.7.91-20.fc25.x86_64
The output now becomes interesting. rpm-ostree determined
that out of strace
and ltrace
, only ltrace
actually
needs to be layered. This is represented by the
LayeredPackages
line above. However, it makes sure to
remember that the user always wants strace
layered. This
is represented by the RequestedPackages
line.
Imagine now that we rebase onto a different branch which
already has ltrace
installed:
# rpm-ostree rebase branch/with/ltrace
# reboot
# rpm-ostree status
State: idle
Deployments:
* branch/with/ltrace
Timestamp: 2017-04-13 23:56:23
Commit: f345e110dbdff66630fbbd554adbc5d998e7...
OSName: fedora-atomic
RequestedPackages: ltrace strace
branch/without/ltrace
Timestamp: 2017-04-14 00:15:33
BaseCommit: 5745788c0e6c07bed73864b6addd4823961...
Commit: 84438e8ca1e7cf9266c89dfbde40cbe4119...
OSName: fedora-atomic
RequestedPackages: strace
LayeredPackages: ltrace
As expected, rpm-ostree has correctly determined that
ltrace
no longer needs to be layered.
These features will be especially useful for Kubernetes
users on Fedora Atomic Host 25.
The plan
is to remove the kubernetes
package in Fedora 26 from the
host in favour of a containerized install. Migration guides
will be available, though one will be able to keep it in the
host by explicitly requesting it prior to rebasing to Fedora
26:
# rpm-ostree install kubernetes
# rpm-ostree status
State: idle
Deployments:
branch/with/ltrace
Timestamp: 2017-04-13 23:56:23
Commit: f345e110dbdff66630fbbd554adbc5d998e7...
OSName: fedora-atomic
RequestedPackages: kubernetes ltrace strace
* branch/with/ltrace
Timestamp: 2017-04-13 23:56:23
Commit: f345e110dbdff66630fbbd554adbc5d998e7...
OSName: fedora-atomic
RequestedPackages: ltrace strace
Cleaning up deployments (v2017.2)
It was always possible to delete non-booted deployments by
dropping down to the ostree command admin undeploy
. Though
as the feature set of rpm-ostree grows, it becomes important
to make sure that all proper layers and caches are cleaned
up.
In v2017.2, rpm-ostree learned the cleanup
command to do
this. It’s capable of deleting pending deployment (using
rpm-ostree cleanup --pending
), as well as rollback
deployment (using rpm-ostree cleanup --rollback
).
Local initramfs regeneration (v2017.1)
By default, rpm-ostree sets up the bootloader so that the initramfs from the content provider is used. However, there are situations where one has host-specific requirements. A typical example is ensuring that certain kernel modules are included.
Starting from v2017.1, rpm-ostree learned the initramfs
command, which causes the initramfs to be regenerated
locally. One can also pass specific arguments to dracut:
# rpm-ostree initramfs --enable --arg "--drivers" --arg "kmodule"