On Thu, Dec 24, 2020 at 10:21 AM James Cassell fedoraproject@cyberpear.com wrote:
On Wed, Dec 23, 2020, at 9:25 PM, Mark Mielke wrote:
This is an interesting point. Oracle UEK R6, as used in OL 7 and OL 8, is tied to Linux 5.4.17, and I think the above might be a good summary of why this is a good thing. One part of this is to set the expectation for what kABI is supported. The other part is to gain access to newer features, and reduce the cost of maintaining a high quality back port that still adheres to this kABI. By deploying Oracle UEK R6 simultaneously to both OL 7 and OL 8, they have effectively separated the kernel from the OS distro, allowing for both elements to be achieved. This seems like something that could be useful to do for the broader EL community.
Red Hat already does this in effect, supporting RHEL 6,7,8 user spaces on RHEL 7 and 8 kernels, via containers.
I'm not sure if I follow your reasoning... If you are saying that "this permits somebody to run Linux 5.4.17 on the host, and the user spaces can be provided by containers", then sure. But, that's not really what Oracle UEK R6 is. With Oracle UEK R6, you can "yum install kernel-uek" on either OL 7.9 or OL 8.3, and in both cases, you will get Linux 5.4.17 installed that you can boot into, on the host.
Yes, the userspace is often resilient to changes in kernels - that's how containers generally work well, and that's how Oracle UEK R6 can be so easily applied against an EL 7.x or EL 8.x machines, but actually providing a choice of different kernels to use, is not something that RHEL provides today (at least not something that comes to mind for me, although perhaps I'm missing some specialty repository, such as RHE-V?).
As for Oracle UEK kernels, the UEK repo also includes some updated packages which replace the original distro packages to make things work.
If you don't need UEK you can remove the UEK kernels, disable the UEK repos and do a distro-sync to have a clean again.
Regards, Simon