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

[carry 317] Cli change to pass driver specific options to docker run #1767

Merged
merged 3 commits into from Apr 3, 2019

Conversation

thaJeztah
Copy link
Member

@thaJeztah thaJeztah commented Mar 21, 2019

carries #317
closes #317
closes #156

Adds preliminary support for multiple networks on docker run now that this syntax would allow this; the daemon does not yet support this, so specifying multiple networks will still produce an error

Opened this PR since #156 was closed.

The commit contains cli changes to support driver options for a network in docker run and docker network connect cli's.
The driver-opt, aliases is now supported in the form of csv as per network option in service commands in swarm mode since #62 . This commit extends this support to docker run command as well.
For docker connect command --driver-opt is added to pass driver specific options for the network the container is connecting to.

Following is supported:

docker run -itd --net name=docknet,alias=web1.0,driver-opt=field1=value1 alpine
docker run -itd --net name=docknet,driver-opt=field1=value1 --net-alias=web1.0 alpine
docker run -itd --net name=docknet --net-alias web1 alpine
docker connect network --driver-opt field1=value1 --alias=web2.0 docknet2 dockcontainer

Signed-off-by: Abhinandan Prativadi abhi@docker.com

@codecov-io
Copy link

Codecov Report

Merging #1767 into master will decrease coverage by 0.15%.
The diff coverage is 23.94%.

@@            Coverage Diff             @@
##           master    #1767      +/-   ##
==========================================
- Coverage   56.32%   56.17%   -0.16%     
==========================================
  Files         307      307              
  Lines       21177    21210      +33     
==========================================
- Hits        11928    11914      -14     
- Misses       8382     8425      +43     
- Partials      867      871       +4

@codecov-io
Copy link

codecov-io commented Mar 21, 2019

Codecov Report

Merging #1767 into master will increase coverage by 0.11%.
The diff coverage is 73.11%.

@@            Coverage Diff             @@
##           master    #1767      +/-   ##
==========================================
+ Coverage   56.28%   56.39%   +0.11%     
==========================================
  Files         308      308              
  Lines       21299    21360      +61     
==========================================
+ Hits        11988    12047      +59     
+ Misses       8436     8434       -2     
- Partials      875      879       +4

@thaJeztah
Copy link
Member Author

@vdemeester @silvin-lubecki I marked this as "WIP", but perhaps it's already ready for review (possibly tests will have to be added still); I'm on PTO until Monday, but if you think this would be good to have for this release; I can add tests in a follow-up

@thaJeztah
Copy link
Member Author

To support multiple networks; this part will have to be removed from the engine, but otherwise (I think) that all works; https://github.com/moby/moby/blob/c7105e3c99286c88855c8d35079f957281dbf581/daemon/create.go#L308-L314

Copy link
Collaborator

@vdemeester vdemeester 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 Author

🤔

WARNING: deadline exceeded by linter unparam (try increasing --deadline)
cli/command/container/hijack.go:188:1:warning: nolint directive did not match any issue (nolint)
cli/command/trust/signer_remove.go:79:1:warning: nolint directive did not match any issue (nolint)

@thaJeztah thaJeztah changed the title [WIP][carry 317] Cli change to pass driver specific options to docker run [carry 317] Cli change to pass driver specific options to docker run Apr 3, 2019
@thaJeztah
Copy link
Member Author

ping @vdemeester @silvin-lubecki I think this should be ok now; I added tests.

Will need follow-ups for the completion-scripts (@albers) and for documentation 🤗

Copy link
Collaborator

@vdemeester vdemeester left a comment

Choose a reason for hiding this comment

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

Still LGTM 💃

}
}

func TestNetworkOptInvalidSyntax(t *testing.T) {
func TestNetworkOptdvancedSyntaxInvalid(t *testing.T) {
Copy link
Member Author

Choose a reason for hiding this comment

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

oh, typo; fixing

The commit contains cli changes to support driver options for a network in
docker run and docker network connect cli's. The driver-opt, aliases is now
supported in the form of csv as per network option in service commands in
swarm mode since docker#62 . This commit extends this support to docker
run command as well.

For docker connect command `--driver-opt` is added to pass driver specific
options for the network the container is connecting to.

Signed-off-by: Abhinandan Prativadi <abhi@docker.com>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Copy link
Contributor

@silvin-lubecki silvin-lubecki left a comment

Choose a reason for hiding this comment

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

LGTM

This refactors the way networking options are parsed, and makes the
client able to pass options for multiple networks. Currently, the
daemon does not yet accept multiple networks when creating a container,
and will produce an error.

For backward-compatibility, the following global networking-related
options are associated with the first network (in case multiple
networks are set);

  - `--ip`
  - `--ip6`
  - `--link`
  - `--link-local-ip`
  - `--network-alias`

Not all of these options are supported yet in the advanced notation,
but for options that are supported, setting both the per-network option
and the global option will produce a "conflicting options" error.

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Copy link
Contributor

@silvin-lubecki silvin-lubecki left a comment

Choose a reason for hiding this comment

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

Still LGTM 🕺

@GordonTheTurtle GordonTheTurtle added this to the 19.03.0 milestone Apr 3, 2019
@thaJeztah thaJeztah deleted the carry_317_network_advanced branch April 3, 2019 15:03
thaJeztah added a commit to thaJeztah/cli that referenced this pull request Jun 21, 2019
For backward compatibility: if no custom options are provided for the network,
and only a single network is specified, omit the endpoint-configuration
on the client (the daemon will still create it when creating the container)

This fixes an issue on older versions of legacy Swarm, which did not support
`NetworkingConfig.EndpointConfig`.

This was introduced in 5bc0963 (docker#1767)

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
thaJeztah added a commit to thaJeztah/cli that referenced this pull request Jun 24, 2019
For backward compatibility: if no custom options are provided for the network,
and only a single network is specified, omit the endpoint-configuration
on the client (the daemon will still create it when creating the container)

This fixes an issue on older versions of legacy Swarm, which did not support
`NetworkingConfig.EndpointConfig`.

This was introduced in 5bc0963 (docker#1767)

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 393c4f3)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
thaJeztah added a commit to thaJeztah/cli that referenced this pull request Jun 24, 2019
For backward compatibility: if no custom options are provided for the network,
and only a single network is specified, omit the endpoint-configuration
on the client (the daemon will still create it when creating the container)

This fixes an issue on older versions of legacy Swarm, which did not support
`NetworkingConfig.EndpointConfig`.

This was introduced in 5bc0963 (docker#1767)

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
thaJeztah added a commit to thaJeztah/cli that referenced this pull request Jun 24, 2019
For backward compatibility: if no custom options are provided for the network,
and only a single network is specified, omit the endpoint-configuration
on the client (the daemon will still create it when creating the container)

This fixes an issue on older versions of legacy Swarm, which did not support
`NetworkingConfig.EndpointConfig`.

This was introduced in 5bc0963 (docker#1767)

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 4d7e6bf)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
return nil, err
}
if _, ok := endpoints[n.Target]; ok {
return nil, errdefs.InvalidParameter(errors.Errorf("network %q is specified multiple times", n.Target))
Copy link
Collaborator

Choose a reason for hiding this comment

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

Any particular reason this was added?
We have a test in integration-cli in moby/moby that tests that this exact case is successful.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Opened moby/moby#42163 to discuss removing the test case that this validation breaks.

@albers
Copy link
Collaborator

albers commented Mar 18, 2021

@thaJeztah The csv syntax is a big problem in bash completion because it does not treat , as a word separator.
That's why I did not add this syntax for any of the commands that have it.

@david-l-riley
Copy link

To support multiple networks; this part will have to be removed from the engine, but otherwise (I think) that all works; https://github.com/moby/moby/blob/c7105e3c99286c88855c8d35079f957281dbf581/daemon/create.go#L308-L314

Is there a reason this isn't done yet? I'm happy to file a PR to make this, but given how simple it seems I just want to make sure there's not a deeper reason it hasn't been done. Seems like an arbitrary check for something the engine should be able to do just fine? Does an API spec need to be updated?

@thaJeztah
Copy link
Member Author

Is there a reason this isn't done yet? I'm happy to file a PR to make this, but given how simple it seems I just want to make sure there's not a deeper reason it hasn't been done. Seems like an arbitrary check for something the engine should be able to do just fine? Does an API spec need to be updated?

No specific reason, other than that nobody has come round to it yet. When making that change, it should probably be gated by API version (i.e., keep the old behavior for existing API versions), and tests will be needed; the network code is known to be "tricky" at times (lots of corner-cases and due to complexity on setting up the network, there's various potential race-conditions).

That said; at least having a (draft) pull request that removes the check, and verifies it works never hurts.

And once it's in a release, we can possibly update docker-compose as well to consume it (connecting multiple networks instead of connecting them one at a time)

@david-l-riley
Copy link

No specific reason, other than that nobody has come round to it yet. When making that change, it should probably be gated by API version (i.e., keep the old behavior for existing API versions), and tests will be needed; the network code is known to be "tricky" at times (lots of corner-cases and due to complexity on setting up the network, there's various potential race-conditions).

That's a perfectly good reason. :-) Just wanted to make sure it wasn't a "this turned out to be unexpectedly hard" thing.

That said; at least having a (draft) pull request that removes the check, and verifies it works never hurts.

I think I can make that happen.

And once it's in a release, we can possibly update docker-compose as well to consume it (connecting multiple networks instead of connecting them one at a time)

This is basically adjacent to my motivation; attaching multiple networks to a container is easy in docker-compose, but for local dev testing with docker run -it --rm it's been a headache trying to make it work without either scripting the whole thing with a create/network attach/start sequence, which makes --rm not do what's desired, or running a separate terminal/job to attach it. Making docker-compose do it the "right" way would be a nice cherry on top.

@thaJeztah
Copy link
Member Author

100% agreed! If it all works, it's a lot cleaner (create this container attached to these networks, with these options) all in a single API call 🎉

akerouanton added a commit to akerouanton/cli that referenced this pull request Jul 13, 2023
The new advanced --network syntax has been introduced in docker#1767
but without support for link-local-ip and mac-address fields. This
commit adds both.

Signed-off-by: Albin Kerouanton <albinker@gmail.com>
akerouanton added a commit to akerouanton/cli that referenced this pull request Jul 13, 2023
The new advanced --network syntax has been introduced in docker#1767
but without support for link-local-ip and mac-address fields. This
commit adds both.

Signed-off-by: Albin Kerouanton <albinker@gmail.com>
akerouanton added a commit to akerouanton/cli that referenced this pull request Jul 13, 2023
The new advanced --network syntax introduced in docker#1767 is
lacking support for `link-local-ip` and `mac-address` fields. This
commit adds both.

Signed-off-by: Albin Kerouanton <albinker@gmail.com>
akerouanton added a commit to akerouanton/cli that referenced this pull request Jul 13, 2023
The new advanced --network syntax introduced in docker#1767 is
lacking support for `link-local-ip` and `mac-address` fields. This
commit adds both.

Signed-off-by: Albin Kerouanton <albinker@gmail.com>
akerouanton added a commit to akerouanton/cli that referenced this pull request Jul 13, 2023
The new advanced --network syntax introduced in docker#1767 is
lacking support for `link-local-ip` and `mac-address` fields. This
commit adds both.

Signed-off-by: Albin Kerouanton <albinker@gmail.com>
akerouanton added a commit to akerouanton/cli that referenced this pull request Jul 15, 2023
The new advanced --network syntax introduced in docker#1767 is
lacking support for `link-local-ip` and `mac-address` fields. This
commit adds both.

Signed-off-by: Albin Kerouanton <albinker@gmail.com>
akerouanton added a commit to akerouanton/cli that referenced this pull request Sep 10, 2023
The new advanced --network syntax introduced in docker#1767 is
lacking support for `link-local-ip` and `mac-address` fields. This
commit adds both.

Signed-off-by: Albin Kerouanton <albinker@gmail.com>
akerouanton added a commit to akerouanton/cli that referenced this pull request Sep 10, 2023
The new advanced --network syntax introduced in docker#1767 is
lacking support for `link-local-ip` and `mac-address` fields. This
commit adds both.

Signed-off-by: Albin Kerouanton <albinker@gmail.com>
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.

None yet

9 participants