Bug #32742

Job rerun using hammer fails when operating system properties are not consistent. Works fine on webUI

Added by Adam Ruzicka about 1 year ago. Updated about 1 year ago.



Cloned from

Description of problem:

1. Job execution fails (for any reason)
2. User wants to rerun job on failed hosts using hammer.
3. Rerun job cannot be posted due to error below:

  1. hammer job-invocation rerun --id 20057 --failed-only=true
    Validation failed: Targeting: Hosts is invalid

If "rerun failed" is called using webUI it works fine.

How reproducible:

  • Host on Satellite must have some inconsistent configurations (easy way to reproduce it is assigning a medium_id to the host that is not linked to its operating system) **

1. Try running a job and force it to fail (type wrong password, for example). Note the job id from the URL ( => job id is 20060)
2. Ensure host has a wrong medium_id assigned:

- Create a random media on Satellite and get its id (let's say, medium_id = 12). Do not assign this media to the operating system of the host!
- Assign the medium_id to the host manually:
echo "update hosts set medium_id = '12' where id = '57';"|su - postgres -c "psql foreman"

3. Rerun the job using hammer and it will fail:

hammer job-invocation rerun --id 20060 --failed-only=true

On the webUI ( click option "Rerun failed" and job will start properly.

Actual results:

WebUI is able to rerun job. Hammer cannot rerun job due to extra verification.

Expected results:

WebUI and hammer should be able to rerun the job (or both should fail). I only expect consistency.

Additional info:

Associated revisions

Revision 2dc0d602 (diff)
Added by Adam Růžička about 1 year ago

Fixes #32742 - Ensure job rerun through api works with invalid hosts (#598)

When a job is rerun through the UI, we take out selected fields from the
old job, render the form and then submit it. Essentially it behaves like
running a new job with some fields pre-populated.

When rerunning a job through the api, there is no form middle step. We
just take the old job, run it through job composer, get a new job out of
it and then link the new job's targeting against old job's hosts. This
step was triggering validations on the hosts.


#1 Updated by The Foreman Bot about 1 year ago

  • Assignee set to Adam Ruzicka
  • Status changed from New to Ready For Testing
  • Pull request added

#2 Updated by The Foreman Bot about 1 year ago

  • Fixed in Releases foreman_remote_execution 4.1.1 added

#3 Updated by Adam Ruzicka about 1 year ago

  • Target version set to foreman_remote_execution-4.5.1
  • Status changed from Ready For Testing to Closed
  • Fixed in Releases deleted (foreman_remote_execution 4.1.1)

#4 Updated by Adam Ruzicka about 1 year ago

  • Fixed in Releases foreman_remote_execution-4.5.1 added

#5 Updated by Adam Ruzicka about 1 year ago

  • Fixed in Releases foreman_remote_execution-4.7.0 added

Also available in: Atom PDF