Feature Overview

Currently, the Argo CD API/UI server reads several types of information from the Redis cache, without reverting to either repository server or Kubernetes API of the managed cluster. However, for the “Live manifest” view in the UI, this is not the case and the API server expects a connection to the managed cluster. This is contrary to the design of the argocd-agent project, where only the managed cluster ever initiates a connection to the control plane, and not vice versa.

We must modify the API server to read the live manifest from the Redis cache instead of the Kubernetes API, so that they can be displayed in the UI when using managed mode agents. It seems that live manifests are already stored in Git, but the “Live manifest” functionality in Argo CD doesn’t use the data from the cache. However, diffs in OutOfSync conditions are correctly being displayed by the UI, so the data must be there.

For autonomous mode agents, viewing live manifests will probably not be possible, because there will be no shared data source.

Goals

<Who benefits from this feature, and how? What is the difference between today's current state and a world with this feature?>

Requirements

Use Cases

<What are we making, for who, and why/what problem are we solving?>

Out of scope

<Defines what is not included in this story>

Dependencies

<Link or at least explain any known dependencies.>

Background, and strategic fit

<What does the person writing code, testing, documenting need to know?>

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

• …