Bug #17603
closedPrefer fqdn instead of IP when tracking if remote execution is enabled for the host
Description
Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1402432
Description of problem:
Customer has nodes within RAC cluster where IP addresses are changing quite often. This might result in jobs to be executed on the different host
$ egrep 'remote|tfm-rubygem-katello' installed_packages
tfm-rubygem-smart_proxy_remote_execution_ssh_core-0.1.2-1.el7sat.noarch
rubygem-smart_proxy_remote_execution_ssh-0.1.2-2.el7sat.noarch
tfm-rubygem-hammer_cli_foreman_remote_execution-0.0.5.3-1.el7sat.noarch
tfm-rubygem-foreman_remote_execution-0.3.0.12-1.el7sat.noarch
tfm-rubygem-katello-3.0.0.82-1.el7sat.noarch
How reproducible:
100%
Steps to Reproduce:
Taken from the case:
On my test system I have eth0 and eth1:
- facter
ipaddress => 10.12.213.48
ipaddress_eth0 => 10.12.213.48
ipaddress_eth1 => 10.12.212.180
So now, if I supply a puppet report of facts, the Satellite now knows my IP of my RE interface (eth0) and the other interface.
If I bring down eth0 now, and send a new puppet report the Satellite will report the IP as blank for the RE interface and the RE Job will fail to connect via SSH.
If we sent a new puppet report (puppet agent -tv), the Satellite will receive the new 'ipaddress' fact which has changed to the IP of eth1. Now when we attempt a job, even though that interface is NOT checked for RE, the job will succeed..
Actual results:
Network interface with RE NOT enabled successfully executes the jobs.
Expected results:
Job should not be marked as successfully if new changed interface with IP was not marked for RE.
Additional info:
Can we use fqdn instead of ip address as a source of remote execution activation?