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

Refactor KubeVirt code to separate libvirt metrics code from the core operator code - kubevirt implementation

    • kubevirt-libvirt-metrics-code-refactoring-implementation
    • Hide

      All of the monitoring metrics code should be in a separate package, and all metrics should work as expected (no changes)

      Show
      All of the monitoring metrics code should be in a separate package, and all metrics should work as expected (no changes)
    • Green
    • To Do
    • CNV-8094 - CNV Observability
    • 0% To Do, 6% In Progress, 94% Done
    • dev-ready, doc-ready, po-ready, qe-ready, ux-ready
    • Hide

      analysis test results...

      Show
      analysis test results...

      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

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

        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:
      • 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.
      • Design doc: https://docs.google.com/document/d/1FoBdaCcJXo5ru5DnmXhNXYHCarYBVZbDLkcpEdGmfec/edit?usp=sharing

      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
            Ohad Revah Ohad Revah
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated: