Epic Goal

To evolve the controller from its current proof-of-concept state into a fully-featured operator by implementing the advanced logic of the ImageUpdater CRD spec. 

Why is this important?

The current implementation proves the basic reconciliation loop works but does not address the real-world needs of managing applications at scale. To be a truly useful and production-ready tool, the controller must be:

• Flexible: Users need to manage large groups of applications without manually listing each one. 

• Safe: In a multi-team environment, it's inevitable that multiple ImageUpdater CRs will be created. The controller must have a robust mechanism to prevent conflicting CRs from "thrashing" a shared Application, which would cause system instability.

• Powerful: Users require the ability to set broad default policies and then provide specific overrides for certain applications or images. Implementing the full hierarchical settings logic enables this powerful configuration pattern.

Scenarios

• A user defines a global default updateStrategy: semver. For a specific application matched by namePattern: "legacy-app", they override the strategy to digest within that applicationRef.

• Team A has a broad policy for *-prod. Team B attempts to create a new ImageUpdater CR that also targets app-frontend-prod. The validating admission webhook rejects their new CR with a clear error message, preventing a conflict before it starts.

Other Considerations

• Out of Scope: This epic is focused on implementing the controller's logic based on the spec. The implementation of the status subresource to report outcomes is covered in a separate epic. The webhook for handling registry events is also out of scope.

• Dependencies: This work depends on the controller-runtime framework and the presence of the Argo CD Application CRD in the cluster. The conflict resolution feature (validating webhook) will likely require cert-manager for TLS certificate provisioning.

• Previous Works: A basic reconciliation loop that can update a single Application has already been implemented and demonstrated.

• Unanswered Questions: The final architectural decision on how to handle inter-CR conflicts (e.g., the "Ownership via Labels + Webhook" model) needs to be confirmed by the team before implementation. Will be done separately

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.