Project

General

Profile

Actions

Bug #17603

closed

Prefer fqdn instead of IP when tracking if remote execution is enabled for the host

Added by Ivan Necas over 7 years ago. Updated almost 6 years ago.

Status:
Closed
Priority:
High
Assignee:
Category:
-
Target version:
Fixed in Releases:
Found in Releases:

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:

  1. 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?

Actions

Also available in: Atom PDF