Epic Goal

Argo CD has recently upgraded to a new major revision v3.0.0. introducing many breaking changes compared to their previous release v2.14. The upgrade manual lists some of the breaking changes and the steps to mitigate each of them.
https://argo-cd.readthedocs.io/en/latest/operator-manual/upgrading/2.14-3.0/

The goal of this epic, is to go through this list and find out if any breaking changes can be mitigated via the operator code and if so, make changes in operator code or document the behaviour and mitigation steps in the release notes. If there are any severe breaking changes, that can potentially cause outages for customers, postpone the Argo CD update to OpenShift GitOps 1.18.0 and update the fix version.

Why is this important?

• There are known breaking changes in the latest Argo CD version 3.0.0 and being a major version update, lots of new changes are expected in the build. We need to ensure that there are no major changes that has the potential to cause a major outage.

Scenarios

1. Customer upgrades OpenShift GitOps to 1.17.0 which contains Argo CD v3.0.0 and notices breaking changes. We should either have a documented mitigation steps or handle it in the operator code so that no manual upgrade steps are required from customers. The risks of this upgrade should be clearly spelt out in the Release notes.

Other Considerations

• <Call out anything explicitly as Out of Scope?>
• <Call out internal and external dependencies?>
• <Are there any known previous works?>
• <Any unanswered questions?>

Definition of Ready

• The epic has been broken down into stories.
• Stories have been scoped.
• The epic has been stack ranked.

Definition of Done

• Code Complete:
  • All code has been written, reviewed, and approved.
• Tested:
  • Unit tests have been written and passed.
  • Integration tests have been completed.
  • System tests have been conducted, and all critical bugs have been fixed.
  • Tested on OpenShift either upstream or downstream on a local build.
• Documentation:
  • User documentation or release notes have been written.
• Build:
  • Code has been successfully built and integrated into the main repository / project.
• Review:
  • Code has been peer-reviewed and meets coding standards.
  • All acceptance criteria defined in the user story have been met.
  • Tested by reviewer on OpenShift.
• Deployment:
  • The feature has been deployed on OpenShift cluster for testing.
• Acceptance:
  • Product Manager or stakeholder has reviewed and accepted the work.