-
Notifications
You must be signed in to change notification settings - Fork 881
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
Moving IPVLAN driver out of experimental #2230
Conversation
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.
SGTM to move out of experimental if we document the current limitations (around L3 management)
Left some comments about removing dead code
drivers_experimental_linux.go
Outdated
@@ -1,9 +1,5 @@ | |||
package libnetwork | |||
|
|||
import "github.com/docker/libnetwork/drivers/ipvlan" | |||
|
|||
func additionalDrivers() []initializer { |
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.
better remove this file / function altogether now that there's currently no experimental drivers; it's not exported, so shouldn't break anyone
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.
Perhaps best to do that in a separate commit; looks like there's quite some dead code and docs we can remove then https://github.com/docker/libnetwork/search?utf8=✓&q=experimental&type=
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.
+1
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.
@thaJeztah @abhi though I agree that promoting IPVLAN driver will result in NOOP code wrt experimental drivers, I still believe it is useful to retain it instead of removing these files altogether. This acts as a template for anyone willing to add experimental drivers. I would hate to see folks spending more than necessary to add the infra to add experimental drivers.
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.
That's what we have version control for; better to remove dead code than keeping it "just in case"
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.
And the commit that removes it can be used as template (that's why it's good to keep it in a single, separate commit)
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.
@thaJeztah sure. But anyone in the future who is trying to add a new experimental driver may not know this history and may not dig into the git history to identify this particular commit. They would have spent valuable time redoing the work and we may have to point them back to this commit, etc. Having framework code in place is useful in certain situations.
IMO Code that performs a logic or functional in nature being dead will confuse everyone, while framework code will help guide folks. In any case, if other maintainers prefer to remove this unused code (which it seems like), I will go ahead and remove it.
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.
But anyone in the future who is trying to add a new experimental driver may not know this history and may not dig into the git history to identify this particular commit.
Shouldn't someone who is adding a new new experimental driver be talking to the community up front? If so then at that point they can be pointed at the history/commit. If not, well, that's why we suggest that people discuss big things before doing lots of work...
@@ -14,6 +15,7 @@ func getInitializers(experimental bool) []initializer { | |||
{bridge.Init, "bridge"}, | |||
{host.Init, "host"}, | |||
{macvlan.Init, "macvlan"}, | |||
{ipvlan.Init, "ipvlan"}, |
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.
Is this list sorted alphabetically? 😇
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.
+1
LGTM |
@@ -14,6 +15,7 @@ func getInitializers(experimental bool) []initializer { | |||
{bridge.Init, "bridge"}, | |||
{host.Init, "host"}, | |||
{macvlan.Init, "macvlan"}, | |||
{ipvlan.Init, "ipvlan"}, |
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.
+1
drivers_experimental_linux.go
Outdated
@@ -1,9 +1,5 @@ | |||
package libnetwork | |||
|
|||
import "github.com/docker/libnetwork/drivers/ipvlan" | |||
|
|||
func additionalDrivers() []initializer { |
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.
+1
IPVLAN driver had been retained in experimental for multiple releases with the requirement to have a proper L3 control-plane (such as BGP) to go along with it which will make this driver much more useful. But based on the community feedback, moby/moby#21735, am proposing to move this driver out of experimental. Signed-off-by: Madhu Venugopal <[email protected]>
Signed-off-by: Madhu Venugopal <[email protected]>
@thaJeztah @ijc addressed the comments. PTAL. |
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.
LGTM
Not a maintainer here, so can't merge 😅 |
ping @fcrisciani PTAL |
Glad to see some action here! We are watching this so closely. 1y or more in production on IPVLAN (with the limitations managed by ourselves with an Ansible-based abstraction layer). If this gets moved out of experimental we're gonna pop the beers. Hopefully the Kubernetes guys also pick it up, making it a viable option to take in consideration on our side (we didn't choose experimenting with Kubernetes since information on setting-up Kubernetes + IPVLAN is lacking and we required IPVLAN for the network performance and isolation reasons we've outlined in the original feedback). We want get drunk, so if there's a maintainer here, we'll drink in honor of your name if you could be kind enough to approve and capture this in an upcoming release. 👍 🍻 |
full diff: moby/libnetwork@1a06131...ebcade7 relevant changes: - moby/libnetwork#2349 IPVS: Add support for GetConfig/SetConfig - moby/libnetwork#2343 Revert "debian has iptables-legacy and iptables-nft now" - moby/libnetwork#2230 Moving IPVLAN driver out of experimental - moby/libnetwork#2307 Fix for problem where agent is stopped and does not restart - moby/libnetwork#2303 Touch-up error-message and godoc for ConfigVXLANUDPPort - moby/libnetwork#2325 Fix possible nil pointer exception - moby/libnetwork#2302 Use sync.RWMutex for VXLANUDPPort - moby/libnetwork#2306 Improve error if auto-selecting IP-range failed Signed-off-by: Sebastiaan van Stijn <[email protected]>
full diff: moby/libnetwork@1a06131...ebcade7 relevant changes: - moby/libnetwork#2349 IPVS: Add support for GetConfig/SetConfig - moby/libnetwork#2343 Revert "debian has iptables-legacy and iptables-nft now" - moby/libnetwork#2230 Moving IPVLAN driver out of experimental - moby/libnetwork#2307 Fix for problem where agent is stopped and does not restart - moby/libnetwork#2303 Touch-up error-message and godoc for ConfigVXLANUDPPort - moby/libnetwork#2325 Fix possible nil pointer exception - moby/libnetwork#2302 Use sync.RWMutex for VXLANUDPPort - moby/libnetwork#2306 Improve error if auto-selecting IP-range failed Signed-off-by: Sebastiaan van Stijn <[email protected]> Upstream-commit: 3ab093d5670e8d59f6ae0c4604b8fcabf1582854 Component: engine
full diff: moby/libnetwork@1a06131...ebcade7 relevant changes: - moby/libnetwork#2349 IPVS: Add support for GetConfig/SetConfig - moby/libnetwork#2343 Revert "debian has iptables-legacy and iptables-nft now" - moby/libnetwork#2230 Moving IPVLAN driver out of experimental - moby/libnetwork#2307 Fix for problem where agent is stopped and does not restart - moby/libnetwork#2303 Touch-up error-message and godoc for ConfigVXLANUDPPort - moby/libnetwork#2325 Fix possible nil pointer exception - moby/libnetwork#2302 Use sync.RWMutex for VXLANUDPPort - moby/libnetwork#2306 Improve error if auto-selecting IP-range failed Signed-off-by: Sebastiaan van Stijn <[email protected]>
full diff: moby/libnetwork@1a06131...ebcade7 relevant changes: - moby/libnetwork#2349 IPVS: Add support for GetConfig/SetConfig - moby/libnetwork#2343 Revert "debian has iptables-legacy and iptables-nft now" - moby/libnetwork#2230 Moving IPVLAN driver out of experimental - moby/libnetwork#2307 Fix for problem where agent is stopped and does not restart - moby/libnetwork#2303 Touch-up error-message and godoc for ConfigVXLANUDPPort - moby/libnetwork#2325 Fix possible nil pointer exception - moby/libnetwork#2302 Use sync.RWMutex for VXLANUDPPort - moby/libnetwork#2306 Improve error if auto-selecting IP-range failed Signed-off-by: Sebastiaan van Stijn <[email protected]>
IPVLAN driver had been retained in experimental for multiple releases
with the requirement to have a proper L3 control-plane (such as BGP) to
go along with it which will make this driver much more useful. But
based on the community feedback,
moby/moby#21735, am proposing to move this
driver out of experimental.
Signed-off-by: Madhu Venugopal [email protected]