-
Feature Request
-
Resolution: Unresolved
-
Undefined
-
None
-
2.4, 2.5
-
False
-
-
False
What is the nature and description of the request?
Currently when trying to understand what changes go into the Operator releases the Errata needs to be referenced in addition to the Controller release notes (if a change is seen there).
This process is less than ideal for trying to easily understand the changes made between Operator versions. And to add to that, the Operator version often is not mentioned in the Errata which causes more confusion as release dates or even container hashes may need to be compared instead.
Why does the customer need this? (List the business requirements here)
So customers are able to more easily understand the impact/changes to upgrading the Operator without needing to dig too deeply.
How would you like to achieve this? (List the functional requirements here)
I think there are a multitude of ways this could be achieved so I don't know if there's one right way to do it. That said, here's a couple ideas:
- Make references to the Operator version somewhere in the Errata
- Make better use of the AAP Operator Release notes to include specific versions (clustered/namespaced) as seen when deploying the Operator: https://access.redhat.com/documentation/en-us/red_hat_ansible_automation_platform/2.4/html/red_hat_ansible_automation_platform_release_notes/operator-240-intro
- Make a Labs comparison tool to diff Operator versions: https://access.redhat.com/labs/
List any affected known dependencies: Doc, UI etc..