Story (Required)

The idea is to leverage the .spec.sourceNamespaces field on AppProject to determine the synchronization targets. This field needs to be set in order to allow Applications to be displayed by the UI, and a source namespace is already mapped to an agent. So when a namespace is listed in .spec.sourceNamespace, it additionally defines the synchronization target: The agent that is synchronized from this namespace.

Background (Required)

When the agent starts up, it lists all currently existing AppProjects as part of the informer setup and configures the watch.

Out of scope

* 

Approach (Required)

Although this seems to make the field .spec.sourceNamespaces ambigiuous at first, a closer look shows that it makes sense - because a namespace on the control plane defines the mapping, and in order for an Application to be manageable, it must be associated to an AppProject which already contains that namespace in the .spec.sourceNamespaces.

Using the .spec.sourceNamespaces field also allows for n:m relationships between AppProjects and managed clusters.

* On AppProject creation

https://github.com/argoproj-labs/argocd-agent/blob/main/docs/architecture/appprojects.md#on-appproject-creation
When a new AppProject is created on the control plane, argocd-agent will evaluate the new object's .spec.sourceNamespaces field to determine the connected synchronization targets. The .spec.sourceNamespaces field is a list of strings, so the principal has to iterate over this list to find all potential targets.

The new AppProject is then submitted to all connected agents for creation on their respective systems.

If an agent that would be the target of an AppProject creation is not connected at the time of AppProject creation, it will receive the create request the next time it connects to the principal.

 * On AppProject modification

https://github.com/argoproj-labs/argocd-agent/blob/main/docs/architecture/appprojects.md#on-appproject-modification
When an AppProject is modified on the control plane, the informer provides information about the AppProject before and after the modification. The principal then needs to compare the .spec.sourceNamespaces field of both versions and apply the following logic:

• For each entry that exist in the old resource version, but not in the new one, the control plane needs to submit a deletion request to the connected agents matching this entry
• For each entry that exist in the new resource version, but not in the new one, the control plane needs to submit a creation request to the connected agents matching this entry
• For all other entries in the new resource version, an update request must be sent to the connected agents matching these entries

If an agent that would be the target of an AppProject modification is not connected at the time of AppProject modification, it will receive either of the create, delete or modification request the next time it connects to the control plane.

 * On AppProject deletion

https://github.com/argoproj-labs/argocd-agent/blob/main/docs/architecture/appprojects.md#on-appproject-deletion
When an AppProject is deleted on the control plane, the informer provides information about the deleted AppProject. For each of the entries in the .spec.sourceNamespaces field, the principal submits a deletion request for this AppProject to the connected agents matching the given pattern.

If an agent that would be the target of an AppProject deletion is not connected at the time of AppProject deletion, it will receive the deletion request the next time it connects to the principal.

Reference Code Pointers:

• Outbound event emissions from Agent for Applications: https://github.com/ishitasequeira/argocd-agent/blob/main/agent/outbound.go 
• Outbound event emissions from Principal for Applications: https://github.com/ishitasequeira/argocd-agent/blob/main/principal/callbacks.go 

Dependencies

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

Acceptance Criteria (Mandatory)

• The agent and principal are able to emit appProject create/update/delete events.
• Add required unit tests for the code change.
• CI checks succeed.

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