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

Image Updater: Introduce Custom Resource Definition

XMLWordPrintable

    • Introduce CRD for Image Updater and create a controller for reconciling the same
    • False
    • Hide

      None

      Show
      None
    • False
    • In Progress
    • SECFLOWOTL-158 - Image Updater: Refactor update cycle logic and introduce Custom Resource Definition
    • 0% To Do, 0% In Progress, 100% Done

      Epic Goal

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

      Why is this important?

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

      Scenarios

      1. ...

      Other Considerations

      • <Call out anything explicitly as Out of Scope?>
      • <Call out internal and external dependencies?>
      • <Are there any known previous works?>
      • <Any unanswered questions?>

      Definition of Ready

      • The epic has been broken down into stories.
      • Stories have been scoped.
      • The epic has been stack ranked.

      Definition of Done

      • Code Complete:
        • All code has been written, reviewed, and approved.
      • Tested:
        • Unit tests have been written and passed.
        • Integration tests have been completed.
        • System tests have been conducted, and all critical bugs have been fixed.
        • Tested on OpenShift either upstream or downstream on a local build.
      • Documentation:
        • User documentation or release notes have been written.
      • Build:
        • Code has been successfully built and integrated into the main repository / project.
      • Review:
        • Code has been peer-reviewed and meets coding standards.
        • All acceptance criteria defined in the user story have been met.
        • Tested by reviewer on OpenShift.
      • Deployment:
        • The feature has been deployed on OpenShift cluster for testing.
      • Acceptance:
        • Product Manager or stakeholder has reviewed and accepted the work.

              cfang@redhat.com Cheng Fang
              isequeir@redhat.com Ishita Sequeira
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated:
                Resolved: