Feature Overview

The Image Updater should be a controller and introduce its own Custom Resource Definition for configuration and persisting status.

Goals

Right now, the Image Updater is not a reconciling controller. The process runs in a continuous loop, lists existing Argo CD applications, extracts its configuration from annotations on the Application and then performs the update cycle for each of the application.

This approach has some issues attached to it:

• The update cycle is run on a predefined timer with the same cadence for all Applications
• This makes it difficult to react to triggers from the outside, e.g. web hooks
• Configuring updates using annotations on Applications is simple, but becomes tedious with more than a couple of applications
• There is no way yet to persist status, which is required for some advanced features that are planned (e.g. updates via Pull Request)

The update cycle logic must me modified such that each Applications, or group of Applications, can have their own update cadence and that it becomes possible to trigger updates from the outside, e.g. through web hooks.

Furthermore, instead of parsing annotations on Applications, the update cycle should be configurable by typed Custom Resources, which will also be able to persist status information.

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

• …