Description of Problem

When installing agent via helm, if the argocd instance is named as argocd, agent resources like deployment and svc get deleted by the controller. This happens as the controller checks if the agent was enabled, by examining the CR. Since agent installation via helm doesn't require setting spec.ArgoCDAgent.Agent.Enabled: true, its assumed that agent is not enabled and the resources should be deleted 

Additional Info

• Starting 1.19, a feature has been added for enabling agent via argocd CR 

Problem Reproduction

• Enable agent, name the argocd instance as `argocd`

Reproducibility

• Always

Prerequisites/Environment

• Agent is enabled using helm
• argocd instance is named as `argocd`

Steps to Reproduce

• Install 1.19.0 RC
• Setup principal 
• Setup agent in another cluster using helm
• Name the argocd instance as `argocd`

Expected Results

• agent stays connected to the principal

Actual Results

• principal-agent is disconnected as the deployment gets deleted

Root Cause

If agent is disabled in argocd CR (.spec.ArgoCDAgent.Agent.Enabled: false ) and agent is installed via helm chart and only when ArgoCD instance name is given argocd, the generated resource names in operator are same as hard coded names of helm chart and upon next ArgoCD reconciliation, operator will see that agent component is disabled in ArgoCD CR and it will delete agent resources which were actually created by helm install

Workaround (If Possible)

• Do not name the argocd instance as `argocd` in workload cluster 

Fix Approaches

• <If we decide to fix this bug, how will we do it?>

Acceptance Criteria

• ...

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.