Epic Goal

Ansible Operator SDK better supports exposing custom Operator/Operands metrics, emitting events, and logging.

Why is this important?

The Operator Framework defines a set of capability levels that really starts to get interesting in Level 4 and 5.

Ansible Operators are expected to be able to go above Level 3, beyond being excellent at running/upgrading/recovering their software stack and support the advanced use cases such as,

• “reconfigure based on the load they are experiencing (eg. Monitoring getting tons of user workload metrics).”

It’s important that Ansible SDK supports Operator authors with pre-written solutions so they can easily opt-in so that the SDK promotes best practices.

Scenarios

1. ...

Acceptance Criteria

• CI - MUST be running successfully with tests automated
• Release Technical Enablement - Provide necessary release enablement details and documents.
• ...
• SDK includes k8s_event module in sdkutils so Ansible Operators can better emit k8s events as a way for troubleshooting or potential reconciliations

• SDK updates the ansible-runner in its dependency to have better supports on logging so users can potentially parse the logging output and emit the noteworthy log events.

• SDK invests in a POC to investigate how to support “exposing custom metrics” for Operator/Operand instances and “fire reconciliations for custom metrics”.

Dependencies (internal and external)

1. ...

Previous Work (Optional):

1. …

Open questions::

1. …

Done Checklist

• CI - CI is running, tests are automated and merged.
• Release Enablement <link to Feature Enablement Presentation>
• DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
• DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
• DEV - Downstream build attached to advisory: <link to errata>
• QE - Test plans in Polarion: <link or reference to Polarion>
• QE - Automated tests merged: <link or reference to automated tests>
• DOC - Downstream documentation merged: <link to meaningful PR>