Page MenuHomePhabricator

Separate rolling release and LTS kernel builds
Closed, ResolvedPublicBUG

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
Is it a breaking change?
Perfectly compatible

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
syncer triaged this task as Normal priority.Aug 31 2019, 12:01 AM
syncer edited projects, added VyOS 1.3 Equuleus; removed VyOS 1.2 Crux.
c-po claimed this task.Sat, Sep 28, 7:13 AM
c-po set Is it a breaking change? to Perfectly compatible.
c-po changed the task status from Open to In progress.Thu, Oct 3, 9:04 AM
c-po moved this task from Need Triage to Finished on the VyOS 1.3 Equuleus board.
c-po closed this task as Resolved.Fri, Oct 4, 1:42 PM
c-po moved this task from Needs Triage to Finished on the VyOS 1.2 Crux (VyOS 1.2.4) board.