Skip to content

Data path traffic separation option in swarm mode#32717

Merged
cpuguy83 merged 2 commits intomoby:masterfrom
fcrisciani:data_path
Apr 27, 2017
Merged

Data path traffic separation option in swarm mode#32717
cpuguy83 merged 2 commits intomoby:masterfrom
fcrisciani:data_path

Conversation

@fcrisciani
Copy link
Copy Markdown
Contributor

@fcrisciani fcrisciani commented Apr 19, 2017

- What I did
In SWARM mode is now possible to pass a new flag to specify which is the interface to use for data path traffic. This will allow to separate data traffic (container to container pkts) from control traffic (grpc between workers and managers)

- How I did it
Introduced a new flag --data-path-addr in the docker swarm init and docker swarm join

- How to verify it
Create a swarm cluster on hosts with at least 2 interfaces, one will be dedicated for the management and will be the one that will be used in the --advertise-addr, the other instead will be the one for the--data-path-addr flag.
Second step is to create an overlay network
Third step is to launch containers on different workers using the overlay network.
At this point the traffic between the containers on different workers will happen on the interface identified by the --data-path-addr

- Description for the changelog

Data path traffic separation option in swarm mode

Fixes #32446

- A picture of a cute animal (not mandatory but encouraged)
hqdefault

@fcrisciani
Copy link
Copy Markdown
Contributor Author

fcrisciani commented Apr 19, 2017

@aaronlehmann @aboch had to reopen it because the previous pull #32615 was not getting updated.
Please review this one

@fcrisciani fcrisciani force-pushed the data_path branch 3 times, most recently from 30952b1 to 3aee03b Compare April 19, 2017 18:20
@fcrisciani fcrisciani changed the title Data path Data path traffic separation option in swarm mode Apr 20, 2017
@aaronlehmann
Copy link
Copy Markdown

LGTM

@aboch
Copy link
Copy Markdown
Contributor

aboch commented Apr 25, 2017

looks good to me

@cpuguy83
Copy link
Copy Markdown
Member

Can you squash so there are two commits, one for libnetwork and one for the new flag/test/etc

@auntunif
Copy link
Copy Markdown

/ test / etc

@fcrisciani
Copy link
Copy Markdown
Contributor Author

@cpuguy83 good like that?

@fcrisciani
Copy link
Copy Markdown
Contributor Author

@cpuguy83 the powerpc pipeline is stuck

@cpuguy83
Copy link
Copy Markdown
Member

Can we move these cli changes over to the docker/cli repo?

@aaronlehmann
Copy link
Copy Markdown

I thought the CLI code hadn't been moved over yet. Shouldn't we make changes here until it is?

@cpuguy83
Copy link
Copy Markdown
Member

Every change is 1 more rebase.
As I understand it's fairly imminent.

@aaronlehmann
Copy link
Copy Markdown

I'm concerned about having two diverging implementations. I think we should continue making changes here until the switch happens.

Among other things, the integration test being added here wouldn't pass because there would be a circular dependency between the test and the code being added in docker/cli. I think this is one of the things we need to solve before splitting out the CLI. I haven't heard a proposal yet.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

If --data-path-addr not specified, should it use AdvertiseAddr, or empty string?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

According to document, it should use AdvertiseAddr.

+If unspecified, Docker will use the same IP address or interface that is used for the
 +advertise address.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

The config is saved consistently with the user input, this way we are not losing track of the original value inserted from the CLI.
The final decision on what to use in case the parameter is not specified is left to the final user of the flag itself.
Today libnetwork if the DataPathAddr is not specified will fallback using the AdvertiseAddr.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Make sense. I think the GetDataPathAddress should clarify its description.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

GetDataPathAddress returns the address configured for data path traffic.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Would you prefer something like: GetDataPathAddress returns the address to be used for the data path traffic, if specified.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

That sounds good.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

k will change it

Flavio Crisciani added 2 commits April 26, 2017 15:33
Vendor libnetwork changes for --data-path-addr flag

Signed-off-by: Flavio Crisciani <[email protected]>
This new flag will allow the configuration of an interface that
can be used for data path traffic to be isolated from control
plane traffic. This flag is simply percolated down to libnetwork
and will be used by all the global scope drivers (today overlay)

Negative test added for invalid flag arguments

Signed-off-by: Flavio Crisciani <[email protected]>
@dongluochen
Copy link
Copy Markdown
Contributor

looks good to me

Copy link
Copy Markdown
Member

@cpuguy83 cpuguy83 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
Copy Markdown
Member

/cc @johndmulhausen @mstanleyjones for docs

@thaJeztah thaJeztah added this to the 17.06.0 milestone Apr 29, 2017
if err != errNoSuchInterface {
specifiedIP, err := resolveInputIPAddr(specifiedHost, true)
if err != nil {
if err == errBadNetworkIdentifier {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

@fcrisciani why this error is overwritten?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

This is the resolveListenAddr that validates the listening address so the error is converted in a way that report an issue on the listening address

func (s *DockerSwarmSuite) TestSwarmInitUnspecifiedDataPathAddr(c *check.C) {
d := s.AddDaemon(c, false, false)

out, err := d.Cmd("swarm", "init", "--data-path-addr", "0.0.0.0")
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Here I would add a test with a completely invalid data path addr to check if the error is consistent

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

non valid IP addresses are captured by the net.ParseIP() and all collapsed to the same error message errBadNetworkIdentifier.


#get libnetwork packages
github.com/docker/libnetwork b13e0604016a4944025aaff521d9c125850b0d04
github.com/docker/libnetwork 5dc95a3f9ce4b70bf08492ca37ec55c5b6d84975
Copy link
Copy Markdown
Contributor

@fntlnz fntlnz May 22, 2017

Choose a reason for hiding this comment

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

I see that this commit implements your required changes from libnetwork but why not using the latest commit at this stage?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

for those who need a compare:

Proposed commit
moby/libnetwork@b13e060...5dc95a3

Master:
moby/libnetwork@b13e060...master

Is there something I'm missing?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Not sure I follow, this patch got merged already several days ago

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

@fntlnz this PR was merged 25 days ago, so wouldn't be able to get all changes in master that are available now :)

Copy link
Copy Markdown
Contributor

@fntlnz fntlnz May 22, 2017

Choose a reason for hiding this comment

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

daf*** haven't noticed the merged label :D had it in my review list and finally found time to look at it! Anyway @fcrisciani super nice feature!

@praving55
Copy link
Copy Markdown

praving55 commented Jul 4, 2017

This looks to be broken - #33936

@thaJeztah
Copy link
Copy Markdown
Member

@praving55 ah! I see you commented here as well; I see the flag was renamed during the design/PR review process (originally --datapath-addr, later --data-path-addr. I updated the top description to prevent this confusion (already commented in #33936 (comment))

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Daemon shutdown delayed by "broadcasting node event"

10 participants