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

[ImageUpdater][CRD] Introduce status logic

XMLWordPrintable

    • [ImageUpdater][CRD] Introduce status logic
    • False
    • Hide

      None

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

      Epic Goal

      To implement the logic that allows the ImageUpdater controller to accurately report its observed state and actions back to the user by updating the status subresource of the ImageUpdater Custom Resource (CR).

      Why is this important?

      The status subresource is the primary mechanism for a Kubernetes controller to provide feedback. A well-implemented status makes the controller's behavior transparent, observable, and easy to debug. It informs users about what the controller is doing, which applications it is managing, what the latest checked images are, and, most importantly, if any errors or conflicts have occurred. Without a status, the controller is a "black box," and users have no way of knowing if it's working correctly.

      Scenarios

      • A user creates an ImageUpdater CR. The controller successfully reconciles it, and the status is updated to show a Ready condition with the last check time.
      • The controller finds a new image for a targeted Application. The status is updated to reflect which image was updated in which application and at what time.

      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
              dkarpele@redhat.com Denis Karpelevich
              Tangerine
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated: