Events that may be of interest to users of the Assisted Service are made available via the REST API. The events are stored in the SQL database. Each event is associated with a cluster and has a severity; some events are also associated with a host.
Using events, a user should be able to understand how the cluster reached its current state, and understand what, if anything, is wrong with it.
Note: Be sure not to disclose secrets or sensitive information that is not otherwise available.
Something wrong has happened that must be investigated. These should be relatively rare and are important to understand, so make them as verbose as possible - describe what happened, what the user might do to mitigate it, and anything needed to debug it.
Examples:
- REST API call failure.
- When an async process related to the resource fails.
Something unexpected happened, but we can continue. As with ERROR logs, make the messages as verbose as necessary for understanding what happened.
Examples:
- When a previously-passing (or previously-uncomputed) validation fails.
- When non-critical components failed to install.
- When the cluster specs pass minimum validations but are not supported.
This is good for marking major milestones in a flow for debuggability. Verbosity here should be as low as possible without impeding debuggability in the field. GET requests should have no INFO logs. They should be added for major milestones in flows where things may go wrong and are interesting to note.
Examples:
- When a cluster or host resource changes status.
- When a previously-failing validation passes.
- When a cluster or host resource progresses to a new installation stage.