Skip to content
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

Merged
merged 2 commits into from
Mar 1, 2019
Merged

Conversation

mavenugo
Copy link
Contributor

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]

Copy link
Member

@thaJeztah thaJeztah left a 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

@@ -1,9 +1,5 @@
package libnetwork

import "github.com/docker/libnetwork/drivers/ipvlan"

func additionalDrivers() []initializer {
Copy link
Member

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

Copy link
Member

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=

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1

Copy link
Contributor Author

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.

Copy link
Member

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"

Copy link
Member

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)

Copy link
Contributor Author

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.

Copy link

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"},
Copy link
Member

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? 😇

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1

@selansen
Copy link
Collaborator

LGTM

@@ -14,6 +15,7 @@ func getInitializers(experimental bool) []initializer {
{bridge.Init, "bridge"},
{host.Init, "host"},
{macvlan.Init, "macvlan"},
{ipvlan.Init, "ipvlan"},
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1

@@ -1,9 +1,5 @@
package libnetwork

import "github.com/docker/libnetwork/drivers/ipvlan"

func additionalDrivers() []initializer {
Copy link
Contributor

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]>
@mavenugo
Copy link
Contributor Author

@thaJeztah @ijc addressed the comments. PTAL.

Copy link
Member

@thaJeztah thaJeztah left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@thaJeztah
Copy link
Member

Not a maintainer here, so can't merge 😅

@thaJeztah
Copy link
Member

ping @fcrisciani PTAL

@Antauri
Copy link

Antauri commented Nov 6, 2018

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. 👍 🍻

@fcrisciani fcrisciani merged commit 8be2d07 into moby:master Mar 1, 2019
thaJeztah added a commit to thaJeztah/docker that referenced this pull request Apr 1, 2019
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]>
docker-jenkins pushed a commit to docker-archive/docker-ce that referenced this pull request Apr 3, 2019
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
adhulipa pushed a commit to adhulipa/docker that referenced this pull request Apr 11, 2019
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]>
kiku-jw pushed a commit to kiku-jw/moby that referenced this pull request May 16, 2019
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]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants