Bug 2096863

Summary: [Satellite6]Remote execution jobs started by webhooks does not respect "Connect by IP" parameter
Product: Red Hat Satellite Reporter: Stefan Nemeth <snemeth>
Component: Hooks and WebhooksAssignee: satellite6-bugs <satellite6-bugs>
Status: NEW --- QA Contact: Satellite QE Team <sat-qe-bz-list>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 6.10.5CC: aruzicka
Target Milestone: UnspecifiedKeywords: Triaged
Target Release: UnusedFlags: aruzicka: needinfo? (snemeth)
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Stefan Nemeth 2022-06-14 12:54:03 UTC
Description of problem:
When remote execution job is started by webhook, connect by ip parametre is ignored. This is issue in environment without DHCP when job fails since it can not resolve the target

Version-Release number of selected component (if applicable):
6.10.5.1

How reproducible:
100%

Steps to Reproduce:
1. create a ansible job 
2. create webhook Administer > Webhooks Templates.
3. create condition that executes webhook

Actual results:

Job fails and ignores connect by ip parametre

Expected results:

Job executes successfully
 
Additional info:

Comment 1 Adam Ruzicka 2022-06-14 13:25:10 UTC
Recapturing what I said on last week's meeting. There is no way how you can toggle connect_by_ip per job, no matter if you use ui or api, it is not exposed. The working hypothesis right now is that by triggering a job so shortly after the host is created, the job starts running before all the host's associations are fully saved. In the excerpts in the case we can see connect_by_ip is always true and apparently host's interfaces do not have ip set at that time (search for "ip:") so it falls through to hostname.

To be able to confirm or refute this, we need logs. A sosreport from may is not enough and task exports are not enough in this case. Of course, the more verbose the logs the better.

On a side note, why do this through webhooks? Why not just turn the thing to be run into a role and assign it to a host? It should then run automatically post-provisioning.

Comment 4 Adam Ruzicka 2023-01-05 11:46:06 UTC
Revisiting this, the title is misleading. Remote execution does not (and possibly even cannot) ignore the setting/parameter, in this case the job is triggered before the host has ip addresses set on its interfaces, which is entirely different bug altogether and cannot be solved in remote execution itself.

@Stefan Do we know if the host in question was provisioned, registered or just created by Satellite receiving facts?

Comment 5 Adam Ruzicka 2023-06-14 12:07:34 UTC
Flipping over to hooks, firing an event when a host is *completely* created/updated would most likely make this go away.