Story (Required)

The purpose of this story is to implement the new configmap-subcontroller package. We need it because it will bring the configmap code into alignment with the described operator redesign. This story will represent the end-to-end effort involved in writing the configmap package, including unit tests and kuttl tests (potentially).

Background (Required)

The idea behind this story is to create a dedicated configmap sub-controller. This cm-subcontroller will be responsible for managing and reconciling all generic configmaps that are required for argo-cd's proper functioning, and don't belong to any single component of argo-cd. This includes:

• argocd-cm
• argocd CA configmap
• argocd rbac cm
• argocd ssh known hosts cm
• argocd tls certs cm
• argocd gpg keys cm

Out of scope

any configmaps belonging to specific components like (dex or notifications)

Approach (Required)

• set-up cm sub-controller with apt cm-controller log context
• consolidate helper functions related to controller resources into appropriate util.go/resource file
• create dedicated constants.go file for controller constants
• identify list of all resources this controller needs to manage
• implement reconciliation functions for all concerned controller resources
• create separate function to trigger deletion of all resources (if required)
• Write unit tests for all functions 
• Write controller specific kuttl tests if applicable and place under test/controller/sso

Use best practices outlined in design doc to make error handling & logging decisions 

Dependencies

https://issues.redhat.com/browse/GITOPS-3120

Acceptance Criteria (Mandatory)

• cm package is implemented end-to-end
• unit tests added for each function
• kuttl tests added for cm specific scenarios that don't involve other controllers

INVEST Checklist

Dependencies identified

Blockers noted and expected delivery timelines set

Design is implementable

Acceptance criteria agreed upon

Story estimated

Legend

Unknown

Verified

Unsatisfied

Done Checklist

• Code is completed, reviewed, documented and checked in
• Unit and integration test automation have been delivered and running cleanly in continuous integration/staging/canary environment
• Continuous Delivery pipeline(s) is able to proceed with new code included
• Customer facing documentation, API docs etc. are produced/updated, reviewed and published
• Acceptance criteria are met