Page MenuHomePhabricator

Separate rolling release and LTS kernel builds
Open, Requires assessmentPublicBUG

Description

We really need to be able to keep separate kernels for rolling and LTS.
When we had no LTS, this was not a problem at all. When we did, but didn't use so many out of kernel drivers, it was an acceptable headache since you only needed to import one package into the LTS branch.

Now we (and guess who I mean by "we"? ;) have to manually import a whole bunch of packages from rolling when we make LTS maintenance releases, including multiple Intel modules, wireguard, accel-ppp, and of course the kernel itself. That's a tedious and error-prone process and it backfired multiple times already.

Worse yet, since we have no per-release kernel branches, and always download the latest upstream drivers, when something turns out to be broken, post inclusion into LTS, we have no way back. And we have no way to store multiple package versions since reprepro cannot do it and tools that can are orders of magnitude harder to use and poorly documented.

That's not to mention that having the very latest kernel in an LTS release is not always desirable.

I suggest the following:

  1. Create per-release branches in the kernel repo
  2. Parameterize the kernel build pipeline with a branch like all other jobs
  3. Devise a procedure for automatically importing upstream modules into git repos and tagging them, so that we can go back to an older release if needed

Details

Difficulty level
Normal (likely a few hours)
Version
1.2.0
Why the issue appeared?
Will be filled on close

Event Timeline

c-po added a comment.Jun 29 2019, 7:07 AM

I only see some minor problems, but in general I like the idea very much!

There is definately a need for a per-release branch of the Kernel to support easy and fast maintenance updates from upstream. Also there are some - non upstream - patches included, we need to check if they are still needed.

The Kernel Pipeline repo (vyos-ci) could be branched to build a specific, pinned revision for the LTS release and so for the out of tree modules. Seems to be the easiest and cleanest way.

Then we can be bleeding edge on current for both the kernel and out-of-tree modules and have still LTS support.

Hope that helps.

runar added a subscriber: runar.Jun 29 2019, 7:10 AM

and always download the latest upstream driver

i think that out-of-tree drivers also needs to be under the same control as modules and the kernel

c-po added a comment.EditedJun 29 2019, 7:15 AM

Unfortunately this is not 100% correct, the intel drivers are pinned to a specific version. Only vyos-wireguard, vyos-accel-ppp are using git HEAD revision from their individual repos.

https://github.com/vyos/vyos-ci/blob/master/build-intel-drivers.sh#L10-L17

pasik added a subscriber: pasik.Jul 2 2019, 3:27 PM