#1364 New Build Targets and Tags for the Kmods SIG
Closed: Fixed 2 months ago by pjgeorg. Opened 2 months ago by pjgeorg.

Please create kmods{8,9}-kernel-6.6-el{8,9} and kmods9-kernel-latest-el9 build targets and the usual tags for these.

For all these build targets these properties should be applied:
External repos: rhel(8|9)-{appstream,baseos,crb}, i.e., no epel repos.
rpm.macro.vendor: 'CentOS Kmods SIG'

Thanks!


Metadata Update from @arrfab:
- Issue priority set to: Waiting on Reporter (was: Needs Review)
- Issue tagged with: cbs, high-gain, medium-trouble

2 months ago

I can quickly create the tags but just checking : will the Kmods SIG start building also kernels parallel to kmod packages for el8/el9/c8s/c9s released kernels ?

Yes, that's the idea. It turned out that we can not provide some of the kernel modules we'd like to, e.g., btrfs, due to the high amount of work required to backport changes to get these to work with the RHEL kernel. The simplest solution seems to be to provide a newer kernel(s) with a config very similar to the one of Fedora.

Let me give you some more details of what is currently planned:
- The kernel(s) will only be built against the RHEL targets, assuming that they'll also work for Stream.
- With RHEL 8 entering maintenance phase soon it will be stuck at the LTS kernel 6.6, only getting updates for this kernel version.
- For RHEL 9 (and 10) the idea was to always build the current stable release in kernel-latest up until the last LTS release during the Full Support phase. At that release kernel-latest will stop moving forward. At every kernel LTS release the idea was to branch off and continue providing updates for these branches until they reach EOL. Kernel 6.6 would be the first LTS release branch for RHEL 9.

I do know that kernel(s) require a lot of resources to build and also to store on disk. I already tried to take that into account. You can find a test build here 1 on CBS. As you can see there some of the subpackages are not provided, in particular no debuginfo which usually takes quite a lot of disk space. In addition for the sources we always use the full tarball of a minor version and for patch releases use the incremental patch file from kernel.org, reducing the space used on the lookaside cache.

In case you think having multiple active streams for RHEL 9 (and 10) would cause too much load I think it should also be sufficient to have a single version always tracking the current stable up until the last kernel LTS release during the Full Support phase of the targeted RHEL at which point it will stick to that version. In this case the single required build target for RHEL 8 and 9 should probably be named differently as there won't be different versions, e.g., kmods{8,9}-kernel-mainline-el{8,9}?
Thinking about that option right now it actually seems to align very well with what people expect during the different Support phases of a RHEL life cycle.

In case you think building kernel(s) is actually not explicitly written in the current charter of the Kmods SIG, you are right. Do you think an approval by the CentOS Board is required to be allowed to do so?

Several points (and just my opinions ;-) ) :

  • I like the fact that you thought about lookaside cache usage (and so +1 for the patch approach to keep it smaller)
  • I don't think that you need to ask for board approval for kernel builds : automotive SIG and Hyperscale SIG are also building kernels already .. I was just wondering if there wouldn't be some kind of "overlap" (like for btrfs with hyperscale)

Let me so create the tags and I'll update ticket when done, but let me just ask you to confirm that you'll build for same architectures as before, so x86_64, aarch64 and ppc64le ?

Yes, please create for the same architectures as before (x86_64, aarch64, ppc64le). Thanks!

At least at the beginning I'll disable ppc64le manually in the spec file, but that might be changed soon.

Great ! here we go :

* Checking distribution el8 configuration...
 -> Checking kmods config...
Using default options for kmods/kernel
Creating tag  : kmods8-kernel-6.6-candidate
Creating tag  : kmods8-kernel-6.6-testing
Creating tag  : kmods8-kernel-6.6-release
 -> creating kmods8-kernel-6.6-el8
Added external repo rhel8-baseos to tag kmods8-kernel-6.6-el8-build (priority 5)
Added external repo rhel8-appstream to tag kmods8-kernel-6.6-el8-build (priority 10)
Added external repo rhel8-crb to tag kmods8-kernel-6.6-el8-build (priority 15)

* Checking distribution el9 configuration...
 -> Checking kmods config...
Using default options for kmods/kernel
Creating tag  : kmods9-kernel-6.6-candidate
Creating tag  : kmods9-kernel-6.6-testing
Creating tag  : kmods9-kernel-6.6-release
 -> creating kmods9-kernel-6.6-el9
Added external repo rhel9-baseos to tag kmods9-kernel-6.6-el9-build (priority 5)
Added external repo rhel9-appstream to tag kmods9-kernel-6.6-el9-build (priority 10)
Added external repo rhel9-crb to tag kmods9-kernel-6.6-el9-build (priority 15)

* Checking distribution el9 configuration...
 -> Checking kmods config...
Using default options for kmods/kernel
Creating tag  : kmods9-kernel-latest-candidate
Creating tag  : kmods9-kernel-latest-testing
Creating tag  : kmods9-kernel-latest-release
 -> creating kmods9-kernel-latest-el9
Added external repo rhel9-baseos to tag kmods9-kernel-latest-el9-build (priority 5)
Added external repo rhel9-appstream to tag kmods9-kernel-latest-el9-build (priority 10)
Added external repo rhel9-crb to tag kmods9-kernel-latest-el9-build (priority 15)

Feel free to verify and then close ticket but tags were created as requested

All looks good. Thanks!

Metadata Update from @pjgeorg:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

2 months ago

Login to comment on this ticket.

Metadata