Here's my counterproposal: We have a netkit label, and issues with the netkit implementation get tagged with them

I have no strong objection to this, but I worry a bit that issues in that list may get closed after a fix is in place somewhere (e.g. new feature added to the kernel) making users dig for information more on issues they hit. My feeling is that it's probably worth pointing users directly to issues that require an update to their kernel or Cilium version to resolve. We could later add a "fixed in version" note here as well. WDYT?

I don't think the docs are a great way to track known issues unless those known issues are inherent in the design or expected to be long-term problems. We already struggle to maintain the large amount of docs that we have. We have an issue tracker, and we can even use a link that refers to closed issues as well. If it helps, we could clone issues for individual branches/versions to help track the status of those fixes as they flow through to releases.

I empathize with the goal to minimize the burden on users to find out the stability status, but we're also talking about a cutting edge feature. If there's this many issues with the feature, we should be clearly setting expectations with the users in general terms by marking it as beta.

My feeling is that it's probably worth pointing users directly to issues that require an update to their kernel or Cilium version to resolve.

This I do agree with, if there are specific kernel version minimums for the feature to work correctly then that makes sense to describe in the docs.

Alright, sounds fine to me then. I will link to the issue tracker instead then.

marking it as beta

Should we go ahead and make this explicit in the docs then?

This I do agree with, if there are specific kernel version minimums for the feature to work correctly then that makes sense to describe in the docs.

It looks like we already specify a minimum kernel version here, but this may need updating later on. Additionally, we could add guardrails in later Cilium releases to probe the kernel and make sure any required features are supported (speaking specifically about Daniel's proposed patch here).

The beta thing makes sense to me, seems like an oversight. /cc @borkmann if you had a different perspective on it.

The beta thing makes sense to me, seems like an oversight. /cc @borkmann if you had a different perspective on it.

yeah that's fine, maybe we can work towards fixing all known issues until 1.17 is out. :) p.s. the netkit patch will go out this week as start

if there are specific kernel version minimums for the feature to work correctly

Somewhat unrelated to this PR, but I'm generally curious if Cilium drives backports of kernel patches to various distros. Is ensuring fixes get backported to distro-specific kernels generally left up to end users and distros themselves or does Cilium make an effort to request backports? For RHEL 8 and 9 do we expect new features such as netkit to make it into their kernels given that the kernel versions are 4.18 and 5.10 respectively? It seems like RHEL in particular has backported a lot of features into their kernels that aren't necessarily reflected by the version number.

if there are specific kernel version minimums for the feature to work correctly

Somewhat unrelated to this PR, but I'm generally curious if Cilium drives backports of kernel patches to various distros. Is ensuring fixes get backported to distro-specific kernels generally left up to end users and distros themselves or does Cilium make an effort to request backports? For RHEL 8 and 9 do we expect new features such as netkit to make it into their kernels given that the kernel versions are 4.18 and 5.10 respectively? It seems like RHEL in particular has backported a lot of features into their kernels that aren't necessarily reflected by the version number.

In general it is up to the community. For upstream kernel fixes, we ensure that a proper Fixes tag is present such that these patches automatically get picked up by the kernel stable team for affected kernels. Occasionally, we'll also ask stable to pick up kernel patches when something potentially affects Cilium, but we don't really have much visibility in what downstream distros pull from the upstream stable. For the case of netkit, I've opened a launchpad ticket some time ago to make sure all fixes land in Ubuntu 24.04 LTS where I've been told they regularly pull in everything which comes via stable. For RHEL, their customers typically drive the asks for feature backports, it's more fuzzy there. For Amazon Linux as another example, I've seen them actively backporting some of the eBPF relevant patches to upstream stable where they eventually pull from it once this lands. tl;dr: It's certainly organic and community driven, and its best to send backports to kernel stable when needed and not there yet so that distros eventually pull these in.

Alright, I went ahead and added a warning that calls this out of as a beta feature and links to the list of netkit-related issues.

/test