Feature Overview

Image Updater provides some functionality that can be reused by other projects, most notably the feature to inspect OCI and Docker registries' contents and pick an image based on some constraints.

However, Image Updater is tightly coupled with Argo CD right now and requires consumers to pull in Argo CD as a dependency.

There was some discussions within the community and within Red Hat (links needed) to decouple this functionality from the parts of the code that interact with Argo CD, i.e. need the Argo CD as requirement.

If we can decouple the functionality as a library, without the need for Argo CD as a dependency, we are more likely to attract more consumers for this library and thereby, potentially gaining more contributors. This will likely increase code quality, feature completeness and project popularity.

Goals

• Red Hat will benefit from this by being able to integrate the popular functionality (finding new versions of OCI & Docker images according to a set of constraints) into more products
• It will be easier to integrate the Argo CD specific part into Argo CD (e.g. make Argo CD a consumer of a new library), because the code to be integrated (and maintained) in Argo CD will be less and more domain specific.
• Community will benefit by having separated concerns (e.g. inspecting images and pick the right one vs. updating them in their tool of choice)
• Customers will benefit from new features and bug fixes contributed by a variety of organisations and 

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

• SECFLOWOTL-121 should be complete

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

• …