A new optional incident-file command line option

[jlruedab]

Hi

I'm working on a sosreport analysis tool and I have a low impact idea that I like to put to your consideration.

I think it would be very helpful to add a new optional --incident-file="/full/path/filename" option to sos report. This option would allow the user to provide his/hers own description of he problem in no more than 500 KB (enforced), sanitized text file containing a detailed description of the incident or issue that the sosreport is intended to address.

If the option is specified, and the file exists and is not empty after sanitization, its contents should be included in the archive under a standard filename such as /incident_description.txt (or any other name you prefer).

I think that this simple improvement will have several benefits like:

• add more context to the data
• preserves the incident description
• no need to go to other tools or systems to understand the problem
• will make easier to integrate the sos command to an incident management pipeline
• help in AI assisted analysis
• low performance impact
• low archive-size impact

That's the idea. Let me know what you think. Thanks.

[pmoravec]

I am somehow inclined to acknowledge such a feature request. It can help in some user scenarios like the listed ones.

One can argue that sos report aims to just collect diagnostic data for troubleshooting. But customer/user verbatim what the underlying problem is, that belongs to such diagnostic data.

Shall we enforce or suggest some data format of the incident/issue file (not sure if incident-file is the best name, but that is a minor nitpick)? On one side, some tooling can safely rely on a that format (json, xml,..?), on the other side, we would limit users that want quickly write up the problem statement.

We do allow collecting some such stuff even now, in fact by two (indirect) ways:

• put a file under /etc/sos as we collect the dir completely (up to cleaner dir) in host plugin
• use sos_extras plugin: echo ":/full/path/filename" > /etc/sos/extras.d/problem_desctiption.txt will trigger sos_extras plugin to collect the /full/path/filename - see plugin description for more

Anyway, both options are somehow indirect, and the collected files are not marked as "here, here, there is the problem description".

[TurboTurtle]

I'm a little unsure of this, mainly due to the fact that most of our downstreams that consume sos are corporate entities that have formal ticketing systems where this context would already be captured. That said, I see a potential use in having the reason for a particular sos report recorded in the archive; to a limited extent this is what --label tries to help with in the archive naming.

I think I see two interfaces for this:

• An --incident-file option like described where we take a local file and place it in the archive under a standardized name/location.
• A separate --reason (--incident-reason?) or somesuch option that interactively prompts the user to describe their issue. We could even make this a bit guided, e.g.:

# sos report --reason
[...]
Enter a brief description of the issue for this report: <input>

Enter any specific steps to reproduce the issue: <input>

How frequently are you seeing this issue? <input>

[... you get the idea ...]

I think I'd prefer this to be a straight/plain text file, but I'm wondering if there's applicability to writing this out as json? I'd also be wary about this being used as a vector for compromising AI doing analysis, but then again that'd be more on the agent to protect itself against than us.

[jlruedab]

I don't see an issue for corporate entities that are already using ticketing systems. They just won't use the option.

I think it will be better not to force a format on the the file and treat it just as plain text. This will make it easier for the user. Whether the user prefers to write the content as json, html, yaml, markup or just text is up to the user.

One think that I didn't though about is if the obfuscator will also clean this file (it should though). That, I do not know.

I think that implementing the --reason option will add needless complexity and provide limited benefit

[pmoravec]

+1 the cleaner should obfuscate the file. Having interactive prompt is mho a nice-to-have sub-feature of this feature (from UX perspective, it can sometimes be easier to invoke sos report --reason and type the description, than open a file, put there text, copy the filename, run sos report --reason-file ..). The --*-file option makes more sense to me, for more automated executions of sos report (esp. with `--batch mode).

Not sure what name the option should have. If we chose both (say) --reason and --reason-file, then I would vote for identical "prefix" (i.e. not --reason and --incident-file, that lacks relationship between the two options).

[jlruedab]

What is the expected behavior when a person use both --reason and --batch?

[pmoravec]

Good point. I think --batch should beat other options every time, like it supersedes (not using) --case-id. So sos report --reason --batch should non-interactively ignore the --reason option.