iceccd does not connect to server with the -s flag

[Diogo Guerra]

This is run on Kubernetes

Specifying the server ip address on the iceccd node reaching the server. furthermore, the network name is named as (net ) and not as (ICECREAM) as i would expect.
Even specifying the same network name, and without network name client never connects to the server, although remote server is reachable 

command:

        - iceccd

        args:

        - -vvv

        - -n ICECREAM

        - -m 1

        # - -l /dev/stdout

        - -s 192.168.1.25

~/Documents/repositories/icecc$ kn division logs pod/icecc-division-worker-8656f6568b-rh6qw

[1] 2019-07-09 13:12:56: ICECREAM daemon 1.2.0 starting up (nice level 5) 

[1] 2019-07-09 13:12:56: 16 CPU(s) online on this server

[1] 2019-07-09 13:12:56: allowing up to 1 active jobs

[1] 2019-07-09 13:12:56: not detaching

[1] 2019-07-09 13:12:56: already a process group leader

[1] 2019-07-09 13:12:56: ignoring localhost lo

[1] 2019-07-09 13:12:56: broadcast eth0 192.168.1.26

[1] 2019-07-09 13:12:57: Netnames:

[1] 2019-07-09 13:12:57: scheduler is on  192.168.1.25:8765 (net )

[1] 2019-07-09 13:12:57: Unknown host(Error: Success)

[1] 2019-07-09 13:12:57: scheduler not yet found/selected.

[1] 2019-07-09 13:13:00: scheduler not yet found/selected.

[1] 2019-07-09 13:13:03: scheduler is on  192.168.1.25:8765 (net )

[1] 2019-07-09 13:13:03: Unknown host(Error: Success)

[1] 2019-07-09 13:13:03: scheduler not yet found/selected.

[1] 2019-07-09 13:13:06: scheduler not yet found/selected.

[1] 2019-07-09 13:13:09: scheduler is on  192.168.1.25:8765 (net )

[1] 2019-07-09 13:13:09: Unknown host(Error: Success)

[1] 2019-07-09 13:13:09: scheduler not yet found/selected.

[1] 2019-07-09 13:13:12: scheduler not yet found/selected.

:~/Documents/repositories/icecc$ kn division logs pod/icecc-division-scheduler-6749595978-p7nz5

[1] 2019-07-09 13:12:33: ICECREAM scheduler 1.2.0 starting up, port 8765

[1] 2019-07-09 13:12:33: scheduler ready

[1] 2019-07-09 13:12:33: ignoring localhost lo

[1] 2019-07-09 13:12:33: broadcast eth0 192.168.1.25

[1] 2019-07-09 13:12:33: ignoring localhost lo

[1] 2019-07-09 13:12:33: broadcast eth0 192.168.1.25

[1] 2019-07-09 13:12:33: Received scheduler announcement from 192.168.1.25:53589 (version 39, netname ICECREAM)

[1] 2019-07-09 13:12:33: broadcast from 192.168.1.25:42040 (version 39)

[1] 2019-07-09 13:12:36: accepted 192.168.1.25

[1] 2019-07-09 13:12:36: login icecc-division-scheduler-6749595978-p7nz5 protocol version: 39 []

~/Documents/repositories/icecc$ kn division exec -it pod/icecc-division-worker-8656f6568b-rh6qw -- bash

[root@icecc-division-worker-8656f6568b-rh6qw /]# ping 192.168.1.25

PING 192.168.1.25 (192.168.1.25) 56(84) bytes of data.

64 bytes from 192.168.1.25: icmp_seq=1 ttl=63 time=0.104 ms

64 bytes from 192.168.1.25: icmp_seq=2 ttl=63 time=0.040 ms

^C

--- 192.168.1.25 ping statistics ---

2 packets transmitted, 2 received, 0% packet loss, time 1041ms

rtt min/avg/max/mdev = 0.040/0.072/0.104/0.032 ms

[root@icecc-division-worker-8656f6568b-rh6qw /]# traceroute 192.168.1.25

traceroute 192.168.1.25            
traceroute to 192.168.1.25 (192.168.1.25), 30 hops max, 60 byte packets
1  full.qualified.domain.name (xxx.xxx.xxx.xxx)  0.043 ms  0.010 ms  0.008 ms
2  192-168-1-25.icecc-division-scheduler.division.svc.cluster.local (192.168.1.25)  0.032 ms  0.016 ms  0.014 ms

The containers are running on the same machine. But even specifying the server IP it seems icecc needs broadcast capabilities.

[root@icecc-division-scheduler-6749595978-p7nz5 /]# ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1440
       inet 192.168.1.25  netmask 255.255.255.255  broadcast 0.0.0.0
       inet6 fe80::8862:8bff:fecc:5bf2  prefixlen 64  scopeid 0x20<link>
       ether 8a:62:8b:cc:5b:f2  txqueuelen 0  (Ethernet)
       RX packets 33  bytes 2402 (2.3 KiB)
       RX errors 0  dropped 0  overruns 0  frame 0
       TX packets 26  bytes 2052 (2.0 KiB)
       TX errors 0  dropped 1 overruns 0  carrier 0  collisions 0

[root@icecc-division-worker-8656f6568b-rh6qw /]# ifconfig

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1440

        inet 192.168.1.26  netmask 255.255.255.255  broadcast 0.0.0.0

        inet6 fe80::986f:efff:fed1:544c  prefixlen 64  scopeid 0x20<link>

        ether 9a:6f:ef:d1:54:4c  txqueuelen 0  (Ethernet)

        RX packets 874  bytes 2514504 (2.3 MiB)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 818  bytes 70161 (68.5 KiB)

        TX errors 0  dropped 1 overruns 0  carrier 0  collisions 0

All ports are open. Same on scheduller and worker node

        ports:

        # Daemon computers

        - containerPort: 10245

        # Scheduler computer

        - containerPort: 8765

        # broadcast to find the scheduler (optional)

        - containerPort: 8765

          protocol: UDP

        # telnet interface to the scheduler (optional)

        - containerPort: 8766

known issue? I don't think this specific use of -server is network config specific, or i might be using the flag wrong??

Reading the flag i can know that is solely based by hostname? Does it also solve for IP?

What gives?

Best regards

[Diogo Guerra]

This was caused because an error with the client trying to connec to the server did not had hostname.

The error message was not clear on which side the error was comming, server or client.

https://github.com/icecc/icecream/blob/5f5da80a30138a148b6184f1dfdcf2b18706792c/services/comm.cpp
```c

if (!host) {
	log_perror("Unknown host");
	if ((-1 == close(remote_fd)) && (errno != EBADF)){
	log_perror("close failed");
	}
	return -1;
	}

```

I will open an issue.

[Diogo Guerra]

Solution 

command:

        - /bin/bash

        args:

        - -c

        - "iceccd -vvv -m 1 -s $(host -4 icecc-division-scheduler  | awk '{print $4}')"

Em terça-feira, 9 de julho de 2019 15:50:34 UTC+2, Diogo Guerra escreveu: