Story (Required)

• User can create 2 or more Image Updater CRs that effectively target the same Argo CD Application. With MaxConcurrentReconciles > 1 it can lead to an attempt to update the same ArgoCD app resource by 2 or more Image Updater CRs. It could be a race condition (low chance due to k8s optimistic locking with resource versions) or even worse: 1 CR can conflict with another.

For example, if CR_A wants image-updater-001 to use nginx:1.20 and CR_B wants image-updater-001 to use nginx:1.21.
Reconcile_A sets it to 1.20.
Reconcile_B (after potentially retrying) sets it to 1.21.
Then Reconcile_A runs again (due to the change made by Reconcile_B) and sets it back to 1.20.
The Application_X will keep flipping between these two states. This is highly undesirable. 

Simple manifest example. imageupdater-sample-0 and imageupdater-sample-1 targets to the same ArgoCD app "image-updater-001":

apiVersion: argocd-image-updater.argoproj.io/v1alpha1
kind: ImageUpdater 
metadata:
  name: imageupdater-sample-0
spec:
  namespace: argocd
  applicationRefs:
    - namePattern: "image-updater-001"
...
---
apiVersion: argocd-image-updater.argoproj.io/v1alpha1
kind: ImageUpdater 
metadata:
   name: imageupdater-sample-1
spec:
  namespace: argocd
  applicationRefs:
    - namePattern: "image-updater-*"
...

Another use case. 2 applications with same name in one CR. There are 2 sources of truth.

---
apiVersion: argocd-image-updater.argoproj.io/v1alpha1
kind: ImageUpdater 
metadata:
   name: imageupdater-sample-1 
spec:
  namespace: argocd
  applicationRefs:
    - namePattern: "image-updater-001"
      strategy: latest
    - namePattern: "image-updater-*" 
      strategy: digest

Background and Approach (Required)

Prohibiting users from creating two or more ImageUpdater CRs that effectively target the same Argo CD Application is a way to prevent the "thrashing" or "fighting controllers". The standard Kubernetes mechanism to enforce such a rule is a Validating Admission Webhook. Webhook Logic should be discussed in this story.

Read more
https://sdk.operatorframework.io/docs/building-operators/golang/webhook/#create-validation-webhook 
https://book.kubebuilder.io/reference/admission-webhook 

Out of Scope

• <Defines what is not included in this story.>

Dependencies

• <Describes what this story depends on. Dependent stories and EPICs should be linked to the story.>

Acceptance Criteria (Mandatory)

• <Describe edge cases to consider when implementing the story and defining tests.>
• <Provides a required and minimum list of acceptance tests for this story. More is expected as the engineer implements this story.>

Definition of Done

• Code Complete:
  • All code has been written, reviewed, and approved.
• Tested:
  • Unit tests have been written and passed.
  • Ensure code coverage is not reduced with the changes.
  • Integration tests have been automated.
  • System tests have been conducted, and all critical bugs have been fixed.
  • Tested and merged on OpenShift either upstream or downstream on a local build.
• Documentation:
  • User documentation or release notes have been written (if applicable).
• Build:
  • Code has been successfully built and integrated into the main repository / project.
  • Midstream changes (if applicable) are done, reviewed, approved and merged.
• 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.