You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
in KMM V2.0, the drivers containers image are recommended to be scratched ( minimal images, no need for any packages to be installed, only .ko files). In Day1 package code, we rely on modprobe executable being present in the drivers container image. Since we recommend that the same image that is used for Day2 can also be used for day1, we need to see how this issue can be solved. One possible solution: mapped host /usr/sbin directory into the running container
The text was updated successfully, but these errors were encountered:
Unfortunately as of today Red Hat can only certify container images based on UBI. That includes kmod images, so downstream we should not recommend images based on scratch, but rather something like ubi9-micro.
One possible solution: mapped host /usr/sbin directory into the running container
Is the kmod package guaranteed to be installed on hosts?
I think it is pretty guaranteed, that kmod will be installed on an Openshift node. At the very least, it is more reliable to count on it to be installed on the node, than to count on it to be installed on the ubi-micro images, especially if somewhere in the future we/customer can move to the scratch images
Whether the DriverContainer images could be certified or not isn't a deciding factor for some partners. Additionally, the reduction in maintenance costs (security patching) that a scratch-based image provides is substantial.
in KMM V2.0, the drivers containers image are recommended to be scratched ( minimal images, no need for any packages to be installed, only .ko files). In Day1 package code, we rely on modprobe executable being present in the drivers container image. Since we recommend that the same image that is used for Day2 can also be used for day1, we need to see how this issue can be solved. One possible solution: mapped host /usr/sbin directory into the running container
The text was updated successfully, but these errors were encountered: