moby / moby

The Moby Project - a collaborative project for the container ecosystem to assemble container-based systems
https://mobyproject.org/
Apache License 2.0
68.77k stars 18.67k forks source link

When a service is created with a network attached to it, it's not found by the other nodes #29273

Closed damienlust closed 1 year ago

damienlust commented 7 years ago

Description

Steps to reproduce the issue:

  1. Initialise a swarm manager and 2 nodes via the swarm init and swarm join commands in 3 separated Linux VM (Redhat 7.2), no usage of docker-machine
  2. From the swarm manager, create a network docker network create --driver overlay skynet
  3. From the swarm manager, create a service docker service create --name test -p 8080:8080 --network skynet --replicas 4

Describe the results you received: Services test not created as expected with 4 replicas sread over the manager and the 2 workers If you do a docker service ps test, you will see a lot of "network skynet not found"

Describe the results you expected: Service created with 4 replicas spread over my 3 nodes

Additional information you deem important (e.g. issue happens only occasionally): The workaround is to add an update parameter when a service is created like --update-delay 10s

Output of docker version:

lient:
 Version:      1.12.3
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   6b644ec
 Built:
 OS/Arch:      linux/amd64

Server:
 Version:      1.12.3
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   6b644ec
 Built:
 OS/Arch:      linux/amd64

Output of docker info:

Client:
 Version:      1.12.3
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   6b644ec
 Built:
 OS/Arch:      linux/amd64

Server:
 Version:      1.12.3
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   6b644ec
 Built:
 OS/Arch:      linux/amd64
[root@berx341 dlust]# docker info
Containers: 2
 Running: 1
 Paused: 0
 Stopped: 1
Images: 9
Server Version: 1.12.3
Storage Driver: overlay
 Backing Filesystem: xfs
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge overlay host null
Swarm: active
 NodeID: 8z9ks35fjzzkupnvhv4w1fc0m
 Is Manager: true
 ClusterID: dxn7m97rbw9n7ne9qh99jm23e
 Managers: 1
 Nodes: 3
 Orchestration:
  Task History Retention Limit: 5
 Raft:
  Snapshot Interval: 10000
  Heartbeat Tick: 1
  Election Tick: 3
 Dispatcher:
  Heartbeat Period: 5 seconds
 CA Configuration:
  Expiry Duration: 3 months
 Node Address: 10.4.98.247
Runtimes: runc
Default Runtime: runc
Security Options: seccomp
Kernel Version: 3.10.0-327.el7.x86_64
Operating System: Red Hat Enterprise Linux Server 7.2 (Maipo)
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 3.702 GiB
Name: berx341
ID: ENV3:VDDK:GSNO:7H7D:CB3Z:VZKL:54Q6:S46Z:V42E:A4MZ:WMSD:ARDS
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
WARNING: bridge-nf-call-ip6tables is disabled
Insecure Registries:
 127.0.0.0/8

Additional environment details (AWS, VirtualBox, physical, etc.):

thaJeztah commented 7 years ago

This may be the issue that was fixed by https://github.com/docker/docker/pull/27466, but

ping @mavenugo to verify

mavenugo commented 7 years ago

@thaJeztah @damienlust this is not related to #27466

Does the task eventually get scheduled ? Yes, the error messages are annoying and these must be transient (due to the asynchronous nature of the system and the reconciliation loop should fix them automatically).

thaJeztah commented 1 year ago

Let me close this ticket for now, as it looks like it went stale.