Uploaded image for project: 'OpenShift Virtualization'
  1. OpenShift Virtualization
  2. CNV-27492

Refactor KubeVirt code to separate alerts and recording rules from the core operator code

XMLWordPrintable

    • kubevirt-alerts-recording-rules-code-refactoring
    • Hide

      Kubevirt alerts and recording rules code is separated from the core operator code

      Show
      Kubevirt alerts and recording rules code is separated from the core operator code
    • Green
    • To Do
    • CNV-8094 - CNV Observability
    • 0% To Do, 0% In Progress, 100% Done
    • dev-ready, doc-ready, po-ready, qe-ready, ux-ready
    • Hide

      2024-03-14: almost done....

      Show
      2024-03-14: almost done....

      Goal

      The KubeVirt metrics code is currently embedded in the heart of the operator code.
      This causes issues with code readability, code complexity and maintainability etc.
      We would like to

      User Stories

      • High-Level goal-based user story, with context.
      • As a core KubeVirt Developer I want be able to have a readable code, that is not cluttered with monitoring code and is easier to maintaine.
      • As a KubeVirt monitoring developer I would like to have the metrics and all of the monitoring code and logic in a separate place where it will be easier to read and maintain.
        As part of CNV-21957 it will be decided on how to refactor the code so it will:

      - Enhance development speed
      - Decouple the monitoring code from operator code
      - Enhance security: monitor publicly available data only
      - Become more modular and generic - resilient to future changes

      • As a user I would like to be able to opt-in and opt-out of specific metrics types.

        Non-Requirements

      • List of things not included in this epic, to alleviate any doubt raised during the grooming process.

      Notes

      • we are mainly focusing on kubevirt/kubevirt (we will eventually extend it to other operators later on), it's just about code refactoring, no impact on existing tier2 (and maybe also tier1) tests.
      • at the first step we think only about refactoring the code but continue executing it in the same pod where is now. We can think later on to move it to a different container or even different pod.

      Done Checklist

      Who What Reference
      DEV Upstream roadmap issue (or individual upstream PRs) <link to GitHub Issue>
      DEV Upstream documentation merged <link to meaningful PR>
      DEV gap doc updated <name sheet and cell>
      DEV Upgrade consideration <link to upgrade-related test or design doc>
      DEV CEE/PX summary presentation label epic with cee-training and add a <link to your support-facing preso>
      QE Test plans in Polarion <link or reference to Polarion>
      QE Automated tests merged <link or reference to automated tests>
      DOC Downstream documentation merged <link to meaningful PR>

              jvilaca@redhat.com João Vilaça
              sradco Shirly Radco
              Ahmad Hafi Ahmad Hafi
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated:
                Resolved: