Bug 2105144

This apparently did get broken by trying to fix https://bugzilla.redhat.com/show_bug.cgi?id=1914902 . For 6.11 it was also touched by https://bugzilla.redhat.com/show_bug.cgi?id=2052048

> It works expected using hammer

Does it? I would say it is more a case of several wrongs somewhat cancelling each other out. At least on my 6.10.7, if I pass --start-at '2022-07-07 23:09:16' to hammer, hammer assumes it is in UTC and adds +00:00 suffix to it before sending it to the server. On the server side, it gets processed and results into a task being scheduled for $TIME in server's time zone (2022-07-07 23:09:00 -0600), not the user's, which should be -0700.

Upstream bug assigned to aruzicka

Upstream bug assigned to aruzicka

I ran some test and using this format "2022-07-08T09:20:00+00:00" the local timezone set for the user is considered (meaning, it will schedule the job to run at 09:20 at the timezone of the user making the request.

Example (time zone of the user is set to "Eastern Time (US & Canada)" which currently represents GMT-4 due to daylight saving)

~~~
# curl -k -X POST -H "Content-Type:application/json" -d '{"job_invocation" : {"job_template_id":"158","inputs": { "command": "uptime"}, "search_query":"name ^ (testserver)", "targeting_type":"static_query", "scheduling": { "start_at" : "2022-07-08T09:20:00+00:00" }}}' -s -u admin:password https://$(hostname -f)/api/job_invocations|json_reformat
{
    "id": 56,
    "description": "Run uptime",
    "job_category": "Commands",
    "targeting_id": 56,
    "status": 2,
    "start_at": "2022-07-08 09:20:00 -0400",
    "status_label": "queued",
    "dynflow_task": {
        "id": "432ed185-4520-4bd2-b50f-fb6254ab26d8",
        "state": "scheduled"
    },
    "succeeded": "N/A",
    "failed": "N/A",
    "pending": "N/A",
    "total": "N/A",
    "missing": 0,
    "targeting": {
        "bookmark_id": null,
        "search_query": "name ^ (testserver)",
        "targeting_type": "static_query",
        "user_id": 4,
        "randomized_ordering": null,
        "hosts": [

        ]
    },
    "task": {
        "id": "432ed185-4520-4bd2-b50f-fb6254ab26d8",
        "state": "scheduled"
    },
    "mode": "future",
    "scheduling": {
        "start_at": "2022-07-08 09:20:00 -0400",
        "start_before": null
    }
}
~~~

If the user doesn't have a specific timezone defined (set to "Browser timezone"), then same syntax will schedule jobs to run at UTC time:

~~~
# curl -k -X POST -H "Content-Type:application/json" -d '{"job_invocation" : {"job_template_id":"158","inputs": { "command": "uptime"}, "search_query":"name ^ (testserver)", "targeting_type":"static_query", "scheduling": { "start_at" : "2022-07-08T10:20:00+00:00" }}}' -s -u admin:redhat https://$(hostname -f)/api/job_invocations|json_reformat
{
    "id": 57,
    "description": "Run uptime",
    "job_category": "Commands",
    "targeting_id": 57,
    "status": 2,
    "start_at": "2022-07-08 10:20:00 UTC",
    "status_label": "queued",
    "dynflow_task": {
        "id": "360ae89a-f6ce-41a5-a37f-5da68e5838f6",
        "state": "scheduled"
    },
    "succeeded": "N/A",
    "failed": "N/A",
    "pending": "N/A",
    "total": "N/A",
    "missing": 0,
    "targeting": {
        "bookmark_id": null,
        "search_query": "name ^ (testserver)",
        "targeting_type": "static_query",
        "user_id": 4,
        "randomized_ordering": null,
        "hosts": [

        ]
    },
    "task": {
        "id": "360ae89a-f6ce-41a5-a37f-5da68e5838f6",
        "state": "scheduled"
    },
    "mode": "future",
    "scheduling": {
        "start_at": "2022-07-08 10:20:00 UTC",              <================== HERE
        "start_before": null
    }
}
~~~

Maybe this is not the expected behavior, but seems consistent.

Moving this bug to POST for triage into Satellite since the upstream issue https://projects.theforeman.org/issues/35181 has been resolved.

Hi Adam, I just wanted to make sure it's OK to take in foreman_remote_execuion 8.0.0 for this BZ, or do we need another version upstream to be released?

There is no foreman_remote_execution-8.0.0 yet. Also there are some changes in master which require changes which will land in foreman-3.4, meaning there will need to be a new, foreman-3.3-compatible, release of rex before you can pull it in. I'll take this as a request to make one

Verified on Satellite 6.12 snap 6

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Important: Satellite 6.12 Release), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2022:8506