-
Notifications
You must be signed in to change notification settings - Fork 2k
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
CLI does not fill NetworkAttachmentConfig.Target correctly #391
Labels
Comments
ping @abhinandanpb @mavenugo |
ping @abhi can you have a look; is this still an issue? $ docker service create --network=bridge nginx:alpine
0aajbat10xptfsqvkty27bked
$ docker service inspect --format '{{json .Spec.TaskTemplate.Networks}}' 0aajbat10xptfsqvkty27bked
[{"Target":"i2262bjzwohcd94p2o5ttrbxa"}]
$ docker network create --driver=overlay foo
ncvighu47mg2gqpz9kcyejr8r
$ docker service create --network=foo nginx:alpine
o33rila7nd2zgzbbyeowiky65
$ docker service inspect --format '{{json .Spec.TaskTemplate.Networks}}' o33rila7nd2zgzbbyeowiky65
[{"Target":"ncvighu47mg2gqpz9kcyejr8r"}] |
Oh, nevermind; looks like it's still an issue;
JSON request to create the service: {
"EndpointSpec": {
"Mode": "vip"
},
"Labels": {},
"Mode": {
"Replicated": {}
},
"TaskTemplate": {
"ContainerSpec": {
"DNSConfig": {},
"Image": "nginx:alpine@sha256:18f83c1759551c173dba982e5fe6f43d62412888e6f431c9c20b8164661592e3"
},
"ForceUpdate": 0,
"Networks": [
{
"Target": "foo"
}
],
"Placement": {
"Platforms": [
{
"Architecture": "amd64",
"OS": "linux"
}
]
},
"Resources": {
"Limits": {},
"Reservations": {}
}
}
} |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The CLI used to put whatever reference to a network the user entered directly into
NetworkAttachmentConfig.Target
. This field is documented to only contain a network ID, so this was the wrong behavior. It turned out that the daemon was automatically rewriting these names into IDs, which is bad because the daemon shouldn't be modifying the spec supplied by the user. The CLI behavior was fixed as part of moby/moby#32062, and there was a lot of discussion about this in the PR:moby/moby#32062 (comment)
moby/moby#32062 (comment)
moby/moby#32062 (comment)
The daemon still rewrites names into IDs for backward compatibility, but this code path isn't meant to be used going forward, and ideally should only be enabled for older API versions.
The CLI's behavior appears to have regressed in #62. It's no longer using the ID as it should. The problem is hidden by the magic rewriting in the daemon.
The text was updated successfully, but these errors were encountered: