Bug 1761012

Could you please share more information about what columns the report should contain or how it should be structured? Is on record representing a job or a host? Do they want to have STDOUT/STDERR for a particular host included in the report? Do they want to mix REX and Ansible runs in the same report or should it be optional or even two separate reports? I guess that's clear, but it would be based on our DB, meaning once data gets automatically cleaned, they wouldn't be part of the report.

Hello Marek,


 Could you please share more information about what columns the report should contain or how it should be structured?

 - we dont have a specific requirement. we can have it as JOB ID, DATE/TIME, HOST, RESULT (STDOUT)

 Is on record representing a job or a host?

 - Its representing a job.

 Do they want to have STDOUT/STDERR for a particular host included in the report? 

 - Customer is expecting the Result of command output. If we have a option to include STDERR it will be great.

 Do they want to mix REX and Ansible runs in the same report or should it be optional or even two separate reports? 

 - Customer is expecting the report based on the job so we can have a two different reports.



Regards 

Perumal

*** Bug 1757739 has been marked as a duplicate of this bug. ***

Thanks for answers. If the report is per job, why do you want to include job ID in it? That will be the same ID for every line in csv right? But that is a small detail we can figure out later. I think it's now clear enough for us to get started.

Upstream bug assigned to dmatoule

Upstream bug assigned to dmatoule

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

Added link to redmine issue where I solved the problem described by Lukáš.

FailedQA for multiple reasons. Tried with Sat 6.10.0 snap 21.0.

1) Attempting to render with some nonexistent job_id results in file only containing headers. No warning.

2) Attempting to render a running job results in "undefined method `in_time_zone' for nil:NilClass"

3) The template is named "Jobs - Invocation report template", inconsistently with the others.

4) stderr is in "stdout" column together with stdout, "stderr" column is empty:

Have this executable file on the host in /root/runthis.py:
```
#!/usr/bin/python

import sys

print("stdout1\nstdout2\nstdout3")
sys.stderr.write("stderr1\nstderr2\nstderr3\n")
```

On the host, run the following SSH job:
```
/root/runthis.py
```

Generate a report and see everything in the stdout column

Note: can't test with Ansible due to bug 2010863.

I'm under the impressions these were not introduced with the new version right? Considering we're now accepting only blocker fixes, is some of the findings blocker in your opinion?

My assumption
1) not a blocker, should be tracked as a separate bug
2) seems like an edge case, but could be simple to solve
3) imho not a blocker, also not sure what inconsistency you mean, perhaps singular vs plural of the first word? Or the word template? Probably trivial to change
4) I believe this is unrelated bug that was found in REX some time ago, we no longer are able to distinguish between stdout and stderr, I think Adam has more info on this one, perhaps there's already a BZ tracking it

> 4) I believe this is unrelated bug that was found in REX some time ago, we no longer are able to distinguish between stdout and stderr, I think Adam has more info on this one, perhaps there's already a BZ tracking it

The script currently runs in a PTY on the remote side. PTYs provide only one input stream and one output stream, meaning we lose the distinction between stdout and stderr. This is nothing new, this behavior has been there for ages. There are some bits and pieces which can still end up in what Satellite thinks is stderr, but those will be about things that happen before the script is actually started on the other side. Afaik there's no BZ for this yet, but it will most likely go away once we move away from net/ssh

Re comment 19, if we can't distinguish stdout from stderr, that's fine but the report shouldn't contain the stderr column in that case. Except maybe if we plan to fix it and it's for forward compatibility but it should be documented that it doesn't actually contain stderr yet and stdout does.

The newly linked RM issue resolves 2) and 3). For 1) and 4) recommend opening a separate bugs.

Upstream bug assigned to mhulan

Upstream bug assigned to mhulan

*** Bug 1997742 has been marked as a duplicate of this bug. ***

The RM issue is merged, moving to POST, the fix is in Foreman 3.4

Tested with 6.13 Snap 8

Steps to Verify:
1. Register a Host on Satellite
2. Run some jobs on the host, for example "Run Ansible Roles"
3. Check the job run out on the Jobs page
3. Click the "Generate Report" button, and have it download to the browser.

Results:
CSV file was downloaded properly, and the various columns on the sheet did contain the appropriate information, split accordingly. YAML, JSON and HTML also all work appropriately.

Setting the download at a later date also functions properly.

Personally, it would be nice to see the columns sorted to have the information at the top, rather than the bottom, as when the STDOUT is long ( which it always will be ) the other columns are comparatively difficult to 
view, without some formatting. Doesn't seem to be a blocker to me though, as the information can be imported into any given Excel-ish program, and manipulated.

With respect to email function, mail is delivered appropriately to the inbox (Testing in this case was done using the Host VM as the target, and the mail is delivered appropriately as verified using /var/log/maillog, and visible in /var/mail/root)

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.13 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-2023:2097