Dear Users,
I’m my previous Cylc setup, I added a single host (let’s say “hostA”) in the [suite host self-identification] section of global.rc file.
It works as expected, no problem for this single host.
Recently, I added a second host to the existing setup and I need to add that host to the [suite host self-identification] as well. Do you think that it can be done? If yes, how can I do it?
Thank you in advance,
Mauro
Hi,
You can have multiple “hardwired” hosts on the network, however, each must have a different global configuration file to allow the hardwired address to be manually configured for each host.
Cylc requires each host to have a unique identifier (e.g. an IP address) which can be used to contact if from other hosts on the network. Normally Cylc asks the host to identify itself, the “hardwired” method allows you to hardcode the server name in the global configuration file. This exists to work around issues where the name the server identifies with (e.g. the result of running hostname) is not suitable for other hosts to contact it by (e.g. by running ssh <hostname>). E.G. the server name returned is not unique or cannot be used to contact the host from other hosts.
Using the “hardwired” option should be a last resort if nothing else works. Use one of of the other methods (“name” or “address”) if possible as this saves configuring each hostname individually.
The Cylc 8 user guide now contains some example Cylc 8 platform configurations which may be of interest.
https://cylc.github.io/cylc-doc/stable/html/reference/config/writing-platform-configs.html
Cheers,
Oliver
Hi Oliver,
many many thanks for your help and your explanation.
I really appreciated it.
The reason why I was asking your support is the following one.
I will try to describe my environment and my needs.
Environment
One year ago, I created a CYLC server virtual machine with these two IP addresses:
192.168.118.37 (for standard communication between cylc client and server)
172.16.0.37 (for admin management purposes)
From the CYLC server, I can submit cylc suites, without any issues, against an LSF cluster login node named “zeus03”.
“zeus03” have these two IP addresses:
192.168.118.13 (for standard communication between cylc client and server)
172.16.0.13 (for admin management purposes)
The cylc client (login node) /etc/hosts file contains these two lines:
192.168.118.13 zeus03
172.16.0.13 login3
login3 and zeus3 represents the same login node
Problem description
The submission request is sent from CYCL server to login3 via 192.168.118.0/24 network.
If I specify host=zeus03 in the [suite host self-identification] section of global.rc file, I can see the correct IP mentioned in the command line output provided by “cylc run test-suite”:
"*** listening on https: zeus03:43063***”
If I remove host info in the [suite host self-identification] section of global.rc file, I can’t see the correct IP mentioned in the command line output provided by “cylc run test-suite”:
"*** listening on https: login3:43063***”
So, the use of the suite host self-identification helped me to see in the output message the correct IP (zeus03 - 192.168.118.13) defined on the communication network I prefer.
Now, due to the additional login node (zeus02), I need to do the same thing for both the nodes or remove the host info from the [suite host self-identification] at all (returning to the old issue I described above).
In your opinion, do you think that the second solution can be dangerous for the communication between cylc client and server?
Thank you again for you patience,
Mauro
Cylc uses Python’s socket interfaces to identify hosts:
# to identify the host the Cylc server is started on
import socket
print(socket.getfqdn())
# to identify other hosts on the network
import socket
hostname = 'zeus03' # a hostname as it might appear in the suite.rc file
print(socket.gethostbyname_ex(hostname))
So for the suite-host zeus03, socket.getfqdn() is returning login03? If so this is down to the configuration of the virtual machine which is something which can be changed. Unfortunately I’m not going to be able to help with virtual machine DNS setup, maybe look up the hostnamectl command?
Otherwise, you can hardcode the address of each host using “hardwired” by having one global configuration file per machine.
Both should be safe, but getting the issue fixed in the virtual machine’s DNS would make things easier.