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

Adding network specific options to service create/update #33130

Merged
merged 2 commits into from May 18, 2017

Conversation

Projects
None yet
6 participants
@abhi
Contributor

abhi commented May 10, 2017

- What I did
Added capability to service create/update to accept network option in csv format and add test case to verify the same.The change includes name, alias and driver options specific to the network. The options are passed to the driver on create and join of endpoint. The corresponding changes are in swarmkit and cli.

- How I did it
Changed --network , --network-add options to accept csv format key/value by creating a new network option type.

- How to verify it

docker service create --name web --network name=docknet,alias=web1,driver-opt=field1=value1 nginx
docker service create --name web --network docknet nginx
docker service update web --network-add name=docknet,alias=web1,driver-opt=field1=value1
docker service update web --network-rm docknet

Relevant PRs:
docker/swarmkit#2176 and docker/swarmkit#2183 (merged)
docker/cli#62

The cli change in docker/cli#62 will allow users to pass driver options, alias and network name as a part of service create and service update. The driver options information will eventually trickle down as a part of endpoint create and join which will allow the drivers to use this information for any additional processing for the endpoint.
Alias information is already part of docker run as --net-alias. However since service can be created and updated with multiple networks there is a need to pass network specific aliases which can also be done with this change.
The change in this PR ties this information to backend structs to pass the driver options, alias as generic options to libnetwork

@aaronlehmann

Can you please rebase your swarmkit branch? It appears to be older than what's currently vendored, so it's effectively reverting a bunch of changes. This makes it hard to review the changes to swarmkit.

Show outdated Hide outdated opts/network.go
Show outdated Hide outdated opts/network.go
Show outdated Hide outdated api/types/network/network.go
Show outdated Hide outdated api/types/network/network.go
Show outdated Hide outdated daemon/cluster/convert/service.go
Show outdated Hide outdated daemon/cluster/executor/container/container.go
Show outdated Hide outdated daemon/cluster/executor/container/container.go
Show outdated Hide outdated vendor/github.com/docker/swarmkit/api/types.proto
Show outdated Hide outdated vendor/github.com/docker/swarmkit/manager/allocator/network.go
Show outdated Hide outdated api/types/network/network.go
Show outdated Hide outdated opts/network.go
Show outdated Hide outdated opts/network.go
Show outdated Hide outdated opts/network.go
@mavenugo

This comment has been minimized.

Show comment
Hide comment
@mavenugo

mavenugo May 12, 2017

Contributor

ping @thaJeztah

Contributor

mavenugo commented May 12, 2017

ping @thaJeztah

@abhi

This comment has been minimized.

Show comment
Hide comment
@abhi

abhi May 12, 2017

Contributor

@mavenugo addressed the comments.

Contributor

abhi commented May 12, 2017

@mavenugo addressed the comments.

@abhi

This comment has been minimized.

Show comment
Hide comment
@abhi

abhi May 17, 2017

Contributor

@aaronlehmann I have addressed the comments. PTAL

Contributor

abhi commented May 17, 2017

@aaronlehmann I have addressed the comments. PTAL

@aaronlehmann

This comment has been minimized.

Show comment
Hide comment
@aaronlehmann

aaronlehmann May 17, 2017

Contributor

This is still vendoring your fork of swarmkit. Does it need commits that are not on master?

Contributor

aaronlehmann commented May 17, 2017

This is still vendoring your fork of swarmkit. Does it need commits that are not on master?

@abhi

This comment has been minimized.

Show comment
Hide comment
@abhi

abhi May 17, 2017

Contributor

@aaronlehmann just updated the vendoring. I was waiting for a PR to be merged in swarmkit. Its merged now.

Contributor

abhi commented May 17, 2017

@aaronlehmann just updated the vendoring. I was waiting for a PR to be merged in swarmkit. Its merged now.

@aaronlehmann

This comment has been minimized.

Show comment
Hide comment
@aaronlehmann

aaronlehmann May 17, 2017

Contributor

Let's merge #32981 first - that will handle the vendoring update

Contributor

aaronlehmann commented May 17, 2017

Let's merge #32981 first - that will handle the vendoring update

@mavenugo

This comment has been minimized.

Show comment
Hide comment
@mavenugo

mavenugo May 17, 2017

Contributor

@aaronlehmann I think #32981 might take more time and based on the comments, I think it might require some more code changes. I think we should take the vendoring via this PR and let the other one rebase. wdyt ?

-- edit --

@aaronlehmann @abhinandanpb yes. Based on the CI failures I think it is better to wait for #32981. It has multiple dependencies on swarmkit and libnetwork. and it is better to have it via #32981.

Contributor

mavenugo commented May 17, 2017

@aaronlehmann I think #32981 might take more time and based on the comments, I think it might require some more code changes. I think we should take the vendoring via this PR and let the other one rebase. wdyt ?

-- edit --

@aaronlehmann @abhinandanpb yes. Based on the CI failures I think it is better to wait for #32981. It has multiple dependencies on swarmkit and libnetwork. and it is better to have it via #32981.

@aaronlehmann

This comment has been minimized.

Show comment
Hide comment
@aaronlehmann

aaronlehmann May 17, 2017

Contributor

Sure. To get CI to pass, this will have to take the changes to vendor.conf from #32981.

Contributor

aaronlehmann commented May 17, 2017

Sure. To get CI to pass, this will have to take the changes to vendor.conf from #32981.

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah May 17, 2017

Member

changes itself LGTM

Member

thaJeztah commented May 17, 2017

changes itself LGTM

@mavenugo

This comment has been minimized.

Show comment
Hide comment
@mavenugo

mavenugo May 18, 2017

Contributor

@abhinandanpb can you pls rebase this PR on top of d618b56 from https://github.com/aboch/docker ?
That will get the CI moving in parallel to #32981 instead of serializing it one after another.

Contributor

mavenugo commented May 18, 2017

@abhinandanpb can you pls rebase this PR on top of d618b56 from https://github.com/aboch/docker ?
That will get the CI moving in parallel to #32981 instead of serializing it one after another.

abhi added some commits May 9, 2017

Adding network specific options to service create/update
The commit adds capability to accept csv parameters
for network option in service create/update commands.The change
includes name,alias driver options specific to the network.
With this the following will be supported

docker service create --name web --network name=docknet,alias=web1,driver-opt=field1=value1 nginx
docker service create --name web --network docknet nginx
docker service update web --network-add name=docknet,alias=web1,driver-opt=field1=value1
docker service update web --network-rm docknet

Signed-off-by: Abhinandan Prativadi <abhi@docker.com>
swarmkit vendoring
Signed-off-by: Abhinandan Prativadi <abhi@docker.com>
@aaronlehmann

LGTM

@mavenugo

LGTM

@mavenugo mavenugo merged commit 45c6f42 into moby:master May 18, 2017

7 checks passed

dco-signed All commits are signed
experimental Jenkins build Docker-PRs-experimental 34291 has succeeded
Details
janky Jenkins build Docker-PRs 42892 has succeeded
Details
powerpc Jenkins build Docker-PRs-powerpc 3277 has succeeded
Details
vendor Jenkins build Docker-PRs-vendor 3440 has succeeded
Details
windowsRS1 Jenkins build Docker-PRs-WoW-RS1 14133 has succeeded
Details
z Jenkins build Docker-PRs-s390x 2995 has succeeded
Details

mavenugo added a commit to mavenugo/docker that referenced this pull request Jun 7, 2017

Service alias should not be copied to task alias
If a service alias is copied to task, then the DNS resolution on the
service name will resolve to service VIP and all of Task-IPs and that
will break the concept of vip based load-balancing resulting in all the
dns-rr caching issues.

This is a regression introduced in moby#33130

Signed-off-by: Madhu Venugopal <madhu@docker.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment