Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
Red Hat Satellite engineering is moving the tracking of its product development work on Satellite to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "Satellite project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs will be migrated starting at the end of May. If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "Satellite project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/SAT-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
When trying to create a Remote Execution job that is set as 'Schedule future execution' instead of 'Execute now', the job is never run, regardless of time/date chosen.
Version-Release number of selected component (if applicable):
Satellite 6.2.2.1:
rubygem-smart_proxy_remote_execution_ssh-0.1.2-2.el7sat.noarch
tfm-rubygem-foreman_remote_execution-0.3.0.12-1.el7sat.noarch
tfm-rubygem-smart_proxy_remote_execution_ssh_core-0.1.2-1.el7sat.noarch
How reproducible:
100%
Steps to Reproduce:
1. Create a REX job for any command / system.
2. For Schedule, choose: 'Schedule future execution' and set time a few minutes in the future.
3. Await for the scheduled time to pass, and notice that the job stays in the 'queued' status under Monitor -> Jobs.
Actual results:
Job stays in 'queued' status under Monitor -> Jobs, is never canceled or moved. (Even if specifying a cancel time as part of rules)
If we goto the job itself and click 'Job Task', the task has an error/traceback:
Oops, we're sorry but something went wrong undefined method `join' for "N/A":String
Expected results:
REX Job should create a task and execute at desired time set.
Additional info:
the first thing to check would be if there is a "delayed_executor"
running. It is the thing that handles running scheduled tasks in
Dynflow.
One way to do that would be opening the Dynflow console, in the
"Status" tab[1], clicking "check status" and checking if any of the
entries has "delayed_executor" => true in the meta column and is
marked as valid.
The CLI equivalent would be running:
cat <<-END | foreman-rake console
states = ForemanTasks.dynflow.world.worlds_validity_check(false)
ForemanTasks.dynflow.world.coordinator.find_worlds.map do |world|
world.meta.merge(:valid => states.fetch(world.id, :invalid))
end
END
This should print the same information as in the Dynflow console, so the same check should be done here.
If there is no entry with delayed_executor or the world with it is invalid, restarting foreman-tasks service should fix it.
Hope this helps or at least helps us get some more information about what's going on.
[1] https://fqdn.of.the.satellite.server/foreman_tasks/dynflow/worlds
It looks like the cause of this BZ is directly tied to the issue in BZ 1390931.
Once I applied the workaround: https://bugzilla.redhat.com/show_bug.cgi?id=1390931#c2
Everything was able to proceed at planned scheduled times completely without issue.
Thanks for the help, Ivan.