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

Skip IPAddr validation for "host-gateway" string #2293

Closed
wants to merge 1 commit into from

Conversation

arkodg
Copy link
Contributor

@arkodg arkodg commented Jan 27, 2020

Relates to - moby/moby#40007
The above PR added support in moby, that detects if
a special string "host-gateway" is added to the IP
section of --add-host, and if true, replaces it with
a special IP value (value of --host-gateway-ip Daemon flag
which defaults to the IP of the default bridge).

This PR is needed to skip the validation for the above
feature

Signed-off-by: Arko Dasgupta arko.dasgupta@docker.com

@silvin-lubecki
Copy link
Contributor

Related to #2290

opts/hosts.go Outdated
@@ -24,6 +24,9 @@ var (
DefaultTLSHost = fmt.Sprintf("tcp://%s:%d", DefaultHTTPHost, DefaultTLSHTTPPort)
// DefaultNamedPipe defines the default named pipe used by docker on Windows
DefaultNamedPipe = `//./pipe/docker_engine`
// HostGatewayName defines a special string which users can append to --add-host
// to add an extra entry in /etc/hosts that maps host.docker.internal to the host IP
HostGatewayName = "host-gateway"
Copy link
Member

Choose a reason for hiding this comment

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

This should be a const; also wondering if there's a const for this in moby/moby that we can use

opts/hosts.go Outdated
return "", fmt.Errorf("invalid IP address in add-host: %q", arr[1])
// Skip IPaddr validation for "host-gateway" string
if arr[1] != HostGatewayName {
if _, err := ValidateIPAddress(arr[1]); err != nil {
Copy link
Member

Choose a reason for hiding this comment

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

Actually slightly on the fence if we should validate at all in the cli, or if we should just pass it to the daemon and have the daemon validate / produce an error (haven't checked yet what the UX looks like in that case)

opts/hosts.go Outdated
@@ -24,6 +24,9 @@ var (
DefaultTLSHost = fmt.Sprintf("tcp://%s:%d", DefaultHTTPHost, DefaultTLSHTTPPort)
// DefaultNamedPipe defines the default named pipe used by docker on Windows
DefaultNamedPipe = `//./pipe/docker_engine`
// HostGatewayName defines a special string which users can append to --add-host
// to add an extra entry in /etc/hosts that maps host.docker.internal to the host IP
HostGatewayName = "host-gateway"
Copy link
Contributor

Choose a reason for hiding this comment

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

I think this value should be used directly from moby

@thaJeztah thaJeztah added this to the next milestone Jan 30, 2020
@thaJeztah
Copy link
Member

Tested what it looks like if we remove the IP address validation;

docker create --add-host foo:fooobar nginx:alpine
Error response from daemon: invalid IP address in add-host: "fooobar"

docker run --add-host foo:fooobar nginx:alpine
docker: Error response from daemon: invalid IP address in add-host: "fooobar".

And, I think those errors look reasonable (have not tried docker stack deploy though)

@thaJeztah
Copy link
Member

docker service create also validates on the service, but appears to be retrying creation; perhaps it's only validating the moment the container is created and not when the service is created;

docker service create --host foo:foooobar nginx:alpine
opbff21havwdz5fyrjk68so11
overall progress: 0 out of 1 tasks
1/1: invalid IP address in add-host: "foooobar"

...

overall progress: 0 out of 1 tasks
1/1: assigned  [======================>                            ]

...

overall progress: 0 out of 1 tasks
1/1: invalid IP address in add-host: "foooobar"

@arkodg
Copy link
Contributor Author

arkodg commented Jan 30, 2020

sure, there is already an identical validation in the daemon, and this PR is just here to unblock this feature.
we can completely remove ValidateHost from the cli, but I'm not sure what the design philosophy is for cli and daemon arg validation

@thaJeztah
Copy link
Member

Overall, I prefer delegating validation to the daemon as much as possible; at most validating well-formedness of values (which in this case was possible before).

Keeping the daemon as source of truth not only keeps complexity out of the cli code, it also prevents situations where the cli talks to a different (older/newer) version of the daemon, or (eg) a daemon running on a different platform.

We should probably (as a follow up) look at the docker service create example though, because that UX isn't ideal (if possible, validate earlier, or perhaps give up if the config is invalid instead of keep retrying)

@arkodg
Copy link
Contributor Author

arkodg commented Jan 31, 2020

@thaJeztah IMHO for the docker service create case, I think keeping the logic here makes sense, updated the PR removing the const

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

@silvin-lubecki
Copy link
Contributor

@arkodg The vendoring looks weird:

These files were changed:

?? vendor/github.com/opencontainers/runc/libcontainer/cgroups/
?? vendor/github.com/opencontainers/runc/libcontainer/configs/

@silvin-lubecki
Copy link
Contributor

Please also rebase 🦁

@thaJeztah
Copy link
Member

@arkodg could you;

  • move the vendor update to a separate commit (first commit)
    • only including changes needed related to that update (I see some tests failing, which could be related to changes upstream)
  • move local changes to for this feature to a commit coming after that (combine the local changes in the current commits)

Bumping to the lastest refpoint to include
the HostGatewayName constant from moby

Signed-off-by: Arko Dasgupta <arko.dasgupta@docker.com>
@arkodg
Copy link
Contributor Author

arkodg commented Feb 11, 2020

@thaJeztah the issue is with make cross using the latest docker/docker refpoint

@thaJeztah
Copy link
Member

opened #2333 to update vendoring

@thaJeztah
Copy link
Member

@arkodg I think this was a bad rebase, as I see no local code-changes anymore, other than adding the import 🤔

Noticed this when I rebased the PR (also the commit message was now only about vndr); see https://github.com/docker/cli/compare/master...thaJeztah:carry_2293_add_host_gateway_dns_entry?expand=1

@thaJeztah
Copy link
Member

@silvin-lubecki found an old commit here; 709cf07

Updating my branch with that

@arkodg
Copy link
Contributor Author

arkodg commented Feb 13, 2020

@thaJeztah I removed the old commit from the PR after you suggested to rc the CI issue by separating the commits to a vendor commit and the feature commit :)

@yuraku
Copy link

yuraku commented Feb 22, 2020

Hi guys. Is there any ETA on when this PR will be merged? 🤞🏻

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.

5 participants