-
Notifications
You must be signed in to change notification settings - Fork 373
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Skip loading openvswitch Kernel module if built-in #5979
Skip loading openvswitch Kernel module if built-in #5979
Conversation
If a module is built-in, trying to load the module with modprobe inside a container may fail (insted of just being a no-op). This will cause Antrea initialization to fail unless agent.dontLoadKernelModules is explicitly set to true. Now that the Docker Desktop LinuxKit VM comes with openvswitch built-in (starting with 4.27.0), trying to install "default" Antrea (i.e., without setting agent.dontLoadKernelModules) in a Kind cluster running with Docker Desktop on macOS will fail. To make sure that users will not run into this issue, we add logic to the install_cni script to skip the modprobe call if the module is built-in. After this agent, there should be very limited use cases for the agent.dontLoadKernelModules parameter, but there is no harm in keeping in case it is needed in the future or for some corner cases. I also realized that the "--skip-kmod" flag for the start_ovs script did not provide any value. Either the openvswitch module needs to be explicitly loaded, in which case the install_cni script will take care of it anyway, or it should not be loaded at all (e.g., because it is built-in). Additionally, because we do not mount the host's /lib/modules to the antrea-ovs container, it is not possible to load any kernel module from the container. Fixes antrea-io#5939 Signed-off-by: Antonin Bas <antonin.bas@broadcom.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code LGTM.
Do you mean "After this change" by "After this agent" in the commit message?
Yes :) I'll fix the commit when I merge |
/test-all |
I will only backport this change to 1.15, for the following reasons:
|
If a module is built-in, trying to load the module with modprobe inside a container may fail (insted of just being a no-op). This will cause Antrea initialization to fail unless agent.dontLoadKernelModules is explicitly set to true. Now that the Docker Desktop LinuxKit VM comes with openvswitch built-in (starting with 4.27.0), trying to install "default" Antrea (i.e., without setting agent.dontLoadKernelModules) in a Kind cluster running with Docker Desktop on macOS will fail. To make sure that users will not run into this issue, we add logic to the install_cni script to skip the modprobe call if the module is built-in. After this change, there should be very limited use cases for the agent.dontLoadKernelModules parameter, but there is no harm in keeping in case it is needed in the future or for some corner cases. I also realized that the "--skip-kmod" flag for the start_ovs script did not provide any value. Either the openvswitch module needs to be explicitly loaded, in which case the install_cni script will take care of it anyway, or it should not be loaded at all (e.g., because it is built-in). Additionally, because we do not mount the host's /lib/modules to the antrea-ovs container, it is not possible to load any kernel module from the container. Fixes antrea-io#5939 Signed-off-by: Antonin Bas <antonin.bas@broadcom.com>
If a module is built-in, trying to load the module with modprobe inside a container may fail (insted of just being a no-op). This will cause Antrea initialization to fail unless agent.dontLoadKernelModules is explicitly set to true. Now that the Docker Desktop LinuxKit VM comes with openvswitch built-in (starting with 4.27.0), trying to install "default" Antrea (i.e., without setting agent.dontLoadKernelModules) in a Kind cluster running with Docker Desktop on macOS will fail. To make sure that users will not run into this issue, we add logic to the install_cni script to skip the modprobe call if the module is built-in. After this change, there should be very limited use cases for the agent.dontLoadKernelModules parameter, but there is no harm in keeping in case it is needed in the future or for some corner cases. I also realized that the "--skip-kmod" flag for the start_ovs script did not provide any value. Either the openvswitch module needs to be explicitly loaded, in which case the install_cni script will take care of it anyway, or it should not be loaded at all (e.g., because it is built-in). Additionally, because we do not mount the host's /lib/modules to the antrea-ovs container, it is not possible to load any kernel module from the container. Fixes #5939 Signed-off-by: Antonin Bas <antonin.bas@broadcom.com>
If a module is built-in, trying to load the module with modprobe inside a container may fail (insted of just being a no-op). This will cause Antrea initialization to fail unless agent.dontLoadKernelModules is explicitly set to true.
Now that the Docker Desktop LinuxKit VM comes with openvswitch built-in (starting with 4.27.0), trying to install "default" Antrea (i.e., without setting agent.dontLoadKernelModules) in a Kind cluster running with Docker Desktop on macOS will fail. To make sure that users will not run into this issue, we add logic to the install_cni script to skip the modprobe call if the module is built-in.
After this change, there should be very limited use cases for the agent.dontLoadKernelModules parameter, but there is no harm in keeping in case it is needed in the future or for some corner cases.
I also realized that the "--skip-kmod" flag for the start_ovs script did not provide any value. Either the openvswitch module needs to be explicitly loaded, in which case the install_cni script will take care of it anyway, or it should not be loaded at all (e.g., because it is built-in). Additionally, because we do not mount the host's /lib/modules to the antrea-ovs container, it is not possible to load any kernel module from the container.
Fixes #5939