-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
Add missing opts to --network advanced syntax #4419
Add missing opts to --network advanced syntax #4419
Conversation
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## master #4419 +/- ##
==========================================
+ Coverage 59.66% 59.71% +0.04%
==========================================
Files 288 288
Lines 24785 24805 +20
==========================================
+ Hits 14789 14812 +23
+ Misses 9111 9109 -2
+ Partials 885 884 -1 |
795787a
to
c19599b
Compare
cli/command/container/opts.go
Outdated
@@ -679,6 +679,14 @@ func parse(flags *pflag.FlagSet, copts *containerOptions, serverOS string) (*con | |||
return nil, err | |||
} | |||
|
|||
if hostConfig.NetworkMode.IsBridge() || hostConfig.NetworkMode.IsUserDefined() { |
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.
Before I forget to comment; we need to check if this does what we expect it to.
I recall I wanted to use some of these functions on the client-side, but the code was written "platform specific", so IsUserDefined()
on a Linux client potentially wouldn't detect a "user-defined" network if the daemon is Windows (or vice-versa).
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.
Instead of making this check work when CLI OS and daemon OS don't match, I'll just remove it. It should not be a problem since the daemon checks whether a MAC address is specified along with an incompatible network mode here:
if (hc.NetworkMode.IsContainer() || hc.NetworkMode.IsHost()) && c.MacAddress != "" {
return ErrConflictContainerNetworkAndMac
}
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.
OHMAN this one is complicated I tried to make changes what I (think) is needed while reviewing, and opened a PR;
However, it may need checking, and there's some other comments I left (including "migrating containers during restore"), which I didn't look into yet.
Following flags are silently ignored when they're passed with no `--network` specified (ie. when the default network is used): - `--network-alias` - `--ip` - `--ip6` - `--link-local-ip` This is not really an issue right now since the first 3 parameters are not allowed on the default bridge network. However, with [moby/moby#45905][1], the container-wide MacAddress parameter will be deprecated and dismissed. Because of that, with [docker#4419][2], it's currently not possible to use the `--mac-address` flag for the default network. Morever, `docker network connect --link-local-ip ...` works properly, so it should also work on `docker container create`. This also lay the ground for making the default bridge network just a "normal" network. [1]: moby/moby#45905 [2]: docker#4419 Signed-off-by: Albin Kerouanton <albinker@gmail.com>
Following flags are silently ignored when they're passed with no `--network` specified (ie. when the default network is used): - `--network-alias` - `--ip` - `--ip6` - `--link-local-ip` This is not really an issue right now since the first 3 parameters are not allowed on the default bridge network. However, with [moby/moby#45905][1], the container-wide MacAddress parameter will be deprecated and dismissed. Because of that, with [docker#4419][2], it's currently not possible to use the `--mac-address` flag with no default network specified. Morever, `docker network connect --link-local-ip ...` works properly, so it should also work on `docker container create`. This also lay the ground for making the default bridge network just a "normal" network. [1]: moby/moby#45905 [2]: docker#4419 Signed-off-by: Albin Kerouanton <albinker@gmail.com>
Following flags are silently ignored when they're passed with no `--network` specified (ie. when the default network is used): - `--network-alias` - `--ip` - `--ip6` - `--link-local-ip` This is not really an issue right now since the first 3 parameters are not allowed on the default bridge network. However, with [moby/moby#45905][1], the container-wide MacAddress parameter will be deprecated and dismissed. Because of that, with [docker#4419][2], it's currently not possible to use the `--mac-address` flag with no default network specified. Morever, `docker network connect --link-local-ip ...` works properly, so it should also work on `docker container create`. This also lay the ground for making the default bridge network just a "normal" network. Since the 3 parameters in the list above aren't ignored anymore, if users provide them, moby's ContainerStart endpoint will complain about those. To provide better UX, [moby/moby#46183][3] make sure these invalid parameters lead to a proper error message on `docker container create` / `docker run`. [1]: moby/moby#45905 [2]: docker#4419 [3]: moby/moby#46183 Signed-off-by: Albin Kerouanton <albinker@gmail.com>
Following flags are silently ignored when they're passed with no `--network` specified (ie. when the default network is used): - `--network-alias` - `--ip` - `--ip6` - `--link-local-ip` This is not really an issue right now since the first 3 parameters are not allowed on the default bridge network. However, with [moby/moby#45905][1], the container-wide MacAddress parameter will be deprecated and dismissed. Because of that, with [docker#4419][2], it's currently not possible to use the `--mac-address` flag with no default network specified. Morever, `docker network connect --link-local-ip ...` works properly, so it should also work on `docker container create`. This also lay the ground for making the default bridge network just a "normal" network. Since the 3 parameters in the list above aren't ignored anymore, if users provide them, moby's ContainerStart endpoint will complain about those. To provide better UX, [moby/moby#46183][3] make sure these invalid parameters lead to a proper error message on `docker container create` / `docker run`. [1]: moby/moby#45905 [2]: docker#4419 [3]: moby/moby#46183 Signed-off-by: Albin Kerouanton <albinker@gmail.com>
Following flags are silently ignored when they're passed with no `--network` specified (ie. when the default network is used): - `--network-alias` - `--ip` - `--ip6` - `--link-local-ip` This is not really an issue right now since the first 3 parameters are not allowed on the default bridge network. However, with [moby/moby#45905][1], the container-wide MacAddress parameter will be deprecated and dismissed. Because of that, with [docker#4419][2], it's currently not possible to use the `--mac-address` flag with no default network specified. Morever, `docker network connect --link-local-ip ...` works properly, so it should also work on `docker container create`. This also lay the ground for making the default bridge network just a "normal" network. Since the 3 parameters in the list above aren't ignored anymore, if users provide them, moby's ContainerStart endpoint will complain about those. To provide better UX, [moby/moby#46183][3] make sure these invalid parameters lead to a proper error message on `docker container create` / `docker run`. [1]: moby/moby#45905 [2]: docker#4419 [3]: moby/moby#46183 Signed-off-by: Albin Kerouanton <albinker@gmail.com>
c19599b
to
efbfb17
Compare
Signed-off-by: Albin Kerouanton <albinker@gmail.com>
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>
efbfb17
to
9e1b42e
Compare
if n.MacAddress != "" && copts.macAddress != "" { | ||
return errdefs.InvalidParameter(errors.New("conflicting options: cannot specify both --mac-address and per-network MAC address")) | ||
} |
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.
Haven't checked out the code locally yet, but I wonder now if these errors are always correct; this error is legit if I would do the following;
This is a conflict, because I'm setting the mac-address
TWICE for the default (bridge
) network;
docker run \
--mac-address=foo \
--network name=bridge,mac-address=bar \
myimage
This is NOT a conflict, because I'm setting the mac-address
twice, but for different networks; for bridge
, I set it to foo
and for mynetwork
, I set it to bar
;
docker run \
--mac-address=foo \
--network bridge \
--network name=mynetwork,mac-address=bar \
myimage
This one is more tricky though, as this one could be seen in 2 different ways;
- an implicit
--network=bridge
with a mac-address specified for the default (bridge
) network - a conflict (because I specified the network to be
mynetwork
, NOTbridge
, and specified the mac-address twice for that network);
docker run \
--mac-address=foo \
--network name=mynetwork,mac-address=bar \
myimage
(Taking mac-address
as example, but the same applies to other options that also have a separate --flag
)
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.
I think the original idea was to make sure no potentially ambiguous notations could be used. I think it will avoid some mistakes, so it's probably better to stick with that UX.
As it's mostly unrelated to my PR, could you open an issue if you think it's worth revisiting?
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
This is a follow-up of docker#4419. That PR leveraged the fact that EndpointSettings.MacAddress is already available, although not used by the CreateNetwork endpoint. TestParseWithMacAddress was testing whether the container-wide MacAddress field is set, and we still need to test that to ensure backward compatibility. But we now also need to test whether the endpoint-specific MacAddress is set. Signed-off-by: Albin Kerouanton <albinker@gmail.com>
This is a follow-up of docker#4419. That PR leveraged the fact that EndpointSettings.MacAddress is already available, although not used by the CreateNetwork endpoint. TestParseWithMacAddress was testing whether the container-wide MacAddress field is set, and we still need to test that to ensure backward compatibility. But we now also need to test whether the endpoint-specific MacAddress is set. Signed-off-by: Albin Kerouanton <albinker@gmail.com>
This is a follow-up of docker#4419. That PR leveraged the fact that EndpointSettings.MacAddress is already available, although not used by the CreateNetwork endpoint. TestParseWithMacAddress was testing whether the container-wide MacAddress field is set, and we still need to test that to ensure backward compatibility. But we now also need to test whether the endpoint-specific MacAddress is set. Signed-off-by: Albin Kerouanton <albinker@gmail.com>
- What I did
Related to:
The new advanced
--network
syntax introduced in #1767 is lacking support forlink-local-ip
andmac-address
fields. This PR adds both.- How to verify it
With a daemon built out of moby/moby#45905:
- Description for the changelog
The advanced syntax for
--network
now supportslink-local-ip
andmac-address
fields.- A picture of a cute animal (not mandatory but encouraged)