Uploaded image for project: 'OpenShift GitOps'
  1. OpenShift GitOps
  2. GITOPS-8806

Image Updater: Trigger update by webhook from registry

XMLWordPrintable

    • Icon: Feature Feature
    • Resolution: Done
    • Icon: Normal Normal
    • None
    • None
    • None
    • False
    • Hide

      None

      Show
      None
    • False
    • GITOPS-8800Provide GitOps-compatible image updating
    • 0% To Do, 0% In Progress, 100% Done

      Feature Overview

      The Image Updater should be event triggered whenever a container image is updated in a registry. Right now, it only supports polling.

      Goals

      Currently, the Argo CD Image Updater polls the registry for new versions of an image configured to be updated at a user-definable interval. However, when this interval is too short, unnecessary load is being put on the registry and the image updater workload itself and when the interval is too long, workloads are not updated in a timely enough fashion.

      The goals of this feature are to reduce unnecessary compute cycles while also reducing the time between the push of a new image version to the registry and the time this new image will be deployed.

      Requirements

      Requirements Notes IS MVP
      Provide a webhook endpoint in the registry workload Must be secured with server side TLS Y
      Provide a webhook processor for webhooks sent by Quay Support for validation of Quay's client side cert must be supported Y
      Provide webhook processors for other popular registries - N

      Use Cases

      • As a user, I do not want to poll my registry for new versions of images but instead want to perform updates that are event based
      • As a user, I want timely updates of my image workloads

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

              cfang@redhat.com Cheng Fang
              jfischer@redhat.com Jann Fischer
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated:
                Resolved: