Feature Overview

One of the nice things about the Argo CD experience is that you can get a visual representation of your desired state and the difference between live & desired states.

Additionally, Argo CD gives you insights into your application in form of the resource tree, that visualizes the resources owned by a particular app, any given resources that are owned by those resource and the dependencies between them.

Goals

The data used by the Argo CD API & UI server to render these things are stored in Argo CD's Redis cache. In the agent model, the Redis server typically runs on the workload clusters ("spokes"), while the Argo CD API server runs on the control plane cluster ("hub"), so the required data is not available, and these Argo CD core features will not work.

The goal of this feature is to implement a way to access data stored in the Redis on the spokes from the hub, while adhering to design principle #1: No connection from the hub to the spokes (i.e., not directly accessing any Redis on the spokes).

Requirements

Use Cases

• As a user of Argo CD with the agent model, I want to be able to see the desired manifests of my Applications, regardless on which spoke they are deployed, as if it would be a local Application
• As a user of Argo CD with the agent model, I want my Application's resource tree to be visualized in the UI, as if it would be a local Application
• As a user of Argo CD with the agent model, I want to display any differences between the desired and live states of my Application, as if it would be a local Application

Out of scope

• Display of desired manifests, resource tree or diff view when the agent is not connected. We can safely assume these will only work if the agent is connected for now. Access to that data when an agent is not available comes at a later point in time.

Dependencies

< Link or at least explain any known dependencies. >

Background, and strategic fit

Refer https://docs.google.com/document/d/17mDmWqL_JVvqUL-4mud8g35bBTYHqBil2ljw_yVykH0/edit?

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).