Leonard Foerster

First need to split out the metal specific parts so we keep track of what went in for metal specifically (Issue https://github.com/bottlerocket-os/bottlerocket/issues/2211).

I have been working towards this and checked what we are currently missing, mostly in the storage and networking side. We are currently mostly missing support for some 10G+ networking...

There is some additional planning work that needs to happen here. We so far have worked towards enabling what I'd call modern common server hardware (standard RAID controllers and 10G+...

Yes, I think there is some steps to this here. I am thinking of something like the following: - [x] Separate the config but have the same build with all...

I have been looking into how to split the builds. Doing this the basic way of just adding some logic in the `kernel.spec` that determines when to merge the metal...

The functional parts of splitting the configs and building the kernel with the variant appropriate config are done. As discussed in https://github.com/bottlerocket-os/bottlerocket/pull/2279 the impact of re-building the kernel with each...

I have had a first look at this, and from the image I can see all the ip_vs modules are in the image: ``` bash-5.1# pwd /x86_64-bottlerocket-linux-gnu/sys-root/usr/lib/modules/5.15.79 bash-5.1# find ....

Looking further in our packages, we seem to load only the `rr`, `wrr`, and `sh` variants of the modules as a precursor to launching kube-proxy defined in [in load-ipvs-modules.conf (here...

Digging a bit around in kubernetes proxier code there is some interesting bits in there: Proxier will only ever attempt to load the following ip_vs modules: `ip_vs`, `ip_vs_rr`, `ip_vs_wrr`, and...

I understand that yet another configuration layer might not be the best user experience. Ideally the appropriate scheduler module would be loaded automatically, and as far as I understand that...