Feature Overview (aka. Goal Summary)

An elevator pitch (value statement) that describes the Feature in a clear,
concise way.

As a admin/workflow developer I would like to review logs for workflows from RHDH UI to support needs of large customers. At the moment any information about progress/failures of workflows can be found in workflow pod logs. It takes time to find the correct pod and the right log messages in it. At the moment it is not possible to correlate logs with particular workflow instances.

Goals (aka. expected user outcomes)

The observable functionality that the user now has as a result of receiving
this feature. Include the anticipated primary user type/persona and which
existing features, if any, will be expanded.

As a user/admin I would like to view specific workflow instance logs to understand what was the outcome of each action in a workflow

Additional use case:
As a user I would like to get meaningful message why my workflow failed.

Requirements (aka. Acceptance Criteria):

A list of specific needs or objectives that a feature must deliver in order
to be considered complete. If the feature spans across releases then good
to have scope for each release with acceptance criteria. Be sure to
include nonfunctional requirements such as security, reliability,
performance, maintainability, scalability, usability, etc.

• available documentation on how to configure the log collecting stack
• meaningful message available on the UI after workflow failure
• it is possible to browse workflow instance logs from the UI

Out of Scope (Optional)

High-level list of items that are out of scope.

<your text here>

Customer Considerations (Optional)

Provide any additional customer-specific considerations that must be made
when designing and delivering the Feature. Initial completion during
Refinement status.

Requested by a large customer.

Documentation Considerations

Provide information that needs to be considered and planned so that
documentation will meet customer needs. If the feature extends existing
functionality, provide a link to its current documentation.

Users will need to know how to configure the log collection stack, and navigate to browse and filter it in the UI.

Dependencies (internal and external)

• Changes are needed in sonataFlow runtime to provide structured logging
• Configuration/link to configuration needs to be part of the documentation on how to configure openTelementry
• The orchestrator backend needs to be configured with openTelemetry to fetch the logs
• The orchestrator frontend needs to provide an action to view logs for a workflow instance