Currently admins install RPMs (but yum plugin has been prototyped). These RPMs include a kernel module that is loaded; the data is dropped in /var/lib/kpatch (SCAP knows to scan there).
The RPM also regenerates the initramfs to ensure that the kpatch is also applied on the next boot (but that's optional).
I think the most important thing to happen here is to figure out the desired administrator UX, as well as what the update provider supports. There are a lot of fundamental questions.
The RPM-delivery model has kpatches as distinct stream of RPMs (yum repository). Perhaps the simplest start is to just match the kpatch-rpm experience via something like:
$ rpm-ostree install -A "kpatch-patch = $(uname -r)"
As of recently, rpm-ostree supports live updates ( https://github.com/coreos/rpm-ostree/issues/639 ) particularly for "pure package additions".
kpatch is logically a pure package addition.
RHEL spends a lot of effort on generating kpatches, and we should support their use on rpm-ostree systems too.
Currently admins install RPMs (but yum plugin has been prototyped). These RPMs include a kernel module that is loaded; the data is dropped in
/var/lib/kpatch
(SCAP knows to scan there).The RPM also regenerates the initramfs to ensure that the kpatch is also applied on the next boot (but that's optional).
I think the most important thing to happen here is to figure out the desired administrator UX, as well as what the update provider supports. There are a lot of fundamental questions.
The RPM-delivery model has kpatches as distinct stream of RPMs (yum repository). Perhaps the simplest start is to just match the kpatch-rpm experience via something like:
(This also heavily intersects with https://github.com/coreos/rpm-ostree/issues/2883 in that we can make it literally the same command)
There's a bunch of other tweaks to do; ideally
rpm-ostree status
shows you the kpatches that are applied)