Maybe a more detailed technical explanation of the preceding line.
- Verify that A happens
- Verify that B is present
- Verify that C does not happen
- What happens when X?
- Don't forget Y.
- See also related thing Z.
As a Discovery customer, I want to download at least partial data and logs even when scans failed so that I have better information about where things went wrong. As a Discovery maintainer/supporter, I want access to logs and partial facts even when scans failed so that I can help diagnose issues.
In other words, a failure in collecting data from the scan, the generation of deployments report, or any of the csv version of reports should not prevent the generation of the tarball. Considering the tarball report contains essential debugging information (like the raw facts themselves and now Ansible logs for network scans), it would be useful to have the tarball generated with partial results.
- When a scan fails part way through (for example, sshd on target dies for a network scan), the user can still download a tarball of some results and logs.
- For a network scan, the Ansible logs are included. For other types of scans, we do not currently collect and save logs.
- If the deployment report is available, we include all current reports (details, deployments, json, csv).
- If the deployment report is NOT available, we include the details JSON if we have any.
- When a scan fails to start the inspect phase because it also failed the connect phase (for example, an IP address that can't be reached), then we preserve existing behavior and do not provide a download.
- The web UI preserves existing behavior for incomplete scans. This means the customer cannot download from the UI unless the scan and deployments report all completed successfully. The web UI continues to treat a "partial" report as a FAILED report.
- The CLI command for downloading a report by default preserves existing behavior for incomplete scans. This means the customer cannot download from the CLI unless the scan and deployments report all completed successfully. The CLI by default continues to treat a "partial" report as a FAILED report.
- However, the CLI command for downloading a report now has a new optional flag (disabled by default) that enables download of a partially complete report. Consider
--partialor--forceor I dunno something like that! - The man page includes an explanation of the new CLI argument.
- Do we need to update customer-facing web docs to explain this new behavior and CLI argument?
- Probably not, but let's discuss with Miranda Williams.
- Consider implementing a status as an enum with at least three states: success, partial success, failure.
- How do we indicate to the customer that a report is only partially complete? How do we show this in the UI?
- Maybe we just implement in the server and CLI for now? Maybe we implement the web UI later?
- Investigate the two state machines we already have: one in the scan (mostly used for pause/resume) and one in the deployment report generation (but is also intertwined with the scan state). Maybe we should refactor or extend these in some way.
- This might enable us to make changes to when or how we include different kinds of reports. For example, the deployments report doesn't entirely make sense for an Ansible scan. Maybe in the future, different types of scans would generate different types of reports. (We do NOT need to make that change now.)
- How can we break a scan in a way to test and verify this behavior?
- Maybe we rely only on unit tests.
- Maybe we shut down the VM or kill sshd (and all related processes) during a scan.
- After a scan, access the database and delete the deployments report.
- Try to think of more ideas!