Feature Overview

Applications are routed to specific agents by the namespace they are created on the control plane. For example, an Application created on the control plane cluster in the namespace "my-agent" will be mapped by the principal to an agent named "my-agent". This means that Applications targeting a specific agent must all be created in the same namespace.

This feature calls for an additional way to route Applications to agents: By leveraging the .spec.destination.name field in the Application CR, regardless of the namespace the Application is created in on the control plane cluster.

For an up-to-date discussion and additional context on this, refer to https://github.com/argoproj-labs/argocd-agent/issues/593

Goals

The main goals behind this feature are to enable ACM integration, and to enable advanced multi-tenancy on the control plane cluster.

Requirements

Use Cases

• Enable ACM's ApplicationSet integration, which uses templated destination fields in the Applications to target specific clusters. The ApplicationSet controller cannot create Applications in namespaces that are different from the one the ApplicationSet itself is created in. This is in conflict with the current  way of mapping an agent (i.e. cluster).
• Enable advanced multi-tenancy on the control plane based on the apps-in-any-namespace pattern. For example, you give teams dedicated namespaces on the control plane to manage their apps declaratively, but they'd need to target more than one cluster. This will also align with applicationsets-in-any-namespace.

Out of scope

<Defines what is not included in this story>

Dependencies

< Link or at least explain any known dependencies. >

Background, and strategic fit

This will be a breaking change, and should be implemented as "optional", i.e. as a configurable way in addition to the existing routing.

Users already specify the target agent in the .spec.destination.name field, so that the resource-proxy will fit, so migration on the principal side would be rather seamless: Just switch routing modes.

Assumptions

< Are there assumptions being made regarding prerequisites and dependencies?>
< Are there assumptions about hardware, software or people resources?>

Customer Considerations

< Are there specific customer environments that need to be considered (such as working with existing h/w and software)?>

Documentation/QE Considerations

< What educational or reference material (docs) is required to support this product feature? For users/admins? Other functions (security officers, etc)? >
< Does this feature have a doc impact? Possible values are: New Content, Updates to existing content, Release Note, or No Doc Impact?>
< Are there assumptions being made regarding prerequisites and dependencies?>
< Are there assumptions about hardware, software or people resources?>

Impact

< If the feature is ordered with other work, state the impact of this feature on the other work>

Related Architecture/Technical Documents

<links>

Definition of Ready

• The objectives of the feature are clearly defined and aligned with the business strategy.
• All feature requirements have been clearly defined by Product Owners.
• The feature has been broken down into epics.
• The feature has been stack ranked.
• Definition of the business outcome is in the Outcome Jira (which must have a parent Jira).