Feature Overview

The Argo CD UI (or API server) allows users to run certain actions against resources, such as “Restart deployment”, “Delete resource” and even custom defined ones. For this to work, the Argo CD API server needs access to the Kubernetes API of the managed cluster. In the argocd-agent architecture, this access does not and will never exist.

We need to think about a way to extend or modify Argo CD’s design to decouple the Argo CD API Server from the Kubernetes API. The coupling itself is already wrong on many levels, as the API server usually is exposed to users and is a pretty complex piece of software.

The goal of such redesign is to allow another component to run actions triggered by the Argo CD UI/API.

Goals

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

• …