-
Notifications
You must be signed in to change notification settings - Fork 799
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
ptp: Enabling L2 mode #987
Comments
Can't you just leave IPAM plugin out? |
No, the documentation specifies it is a required field. Leaving it as an empty dictionary will result in an unexpected behavior, with the message "no plugin name provided". (While if you fill the IPAM fields, it will work as expected). This behavior has been tested both in a microk8s cluster and a kubeadm one. Edit: I've checked the code and in the bridge plugin this option is contemplated by checking the value of the IPAM field, while in ptp, it's not the case. |
After revisiting the PTP plugin’s design and purpose, I’ve seen that this plugin is inherently L3-focused as it relies on L3 as the routing is done from the host machine via IP to the next container/namespace within the same subnet. Enabling Layer 2 (or omitting IP addresses entirely) would require a fundamental redesign and go beyond its intended scope. For scenarios requiring a more flexible Layer 2 or “no-IP” approach, the bridge plugin (or a custom plugin) is more appropriate. Accordingly, I’m closing this issue, as the original request does not align with the PTP plugin’s core design. |
Current Situation:
When utilizing the PTP plugin to establish a connection between two containers, the current workflow necessitates the use of IP Address Management (IPAM) to assign IP addresses to the connected veth pair.
Enhancement Proposal:
It would greatly enhance the usability of the PTP plugin if there were an option to create the veth pair without explicitly specifying IP addresses. This would parallel the simplicity offered by bridge configurations, making the PTP plugin more versatile. In certain scenarios, the use of PTP proves to be a superior alternative to bridge configurations, and eliminating the mandatory requirement for IP addresses would streamline the setup process.
Expected Behavior:
Users should have the flexibility to create a PTP connection between containers without the obligation to provide explicit IP addresses.
This enhancement would align the PTP plugin's functionality more closely with the user-friendly experience offered by bridge configurations.
The text was updated successfully, but these errors were encountered: