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

Fix test_no_new_hco_related_objects: dict key collision loses ServiceAccount entries

XMLWordPrintable

    • CNV I/U Operators Sprint 285
    • None

      Test

      Path: tests/install_upgrade_operators/strict_reconciliation/test_hco_related_objects.py:20
      Polarion: CNV-9843

      Issue

      The test test_no_new_hco_related_objects fails because HCO PR #3953 (OCPBUGS-70353) added dedicated ServiceAccount resources for kubevirt-console-plugin and kubevirt-apiserver-proxy in CNV 4.21.1. These ServiceAccounts share the same name as their corresponding Deployments.

      The test uses a dict comprehension with name as key and kind as value to compare expected vs actual relatedObjects. Since Python dicts only keep one value per key, when two resources share the same name but have different kinds (Deployment and ServiceAccount), only the last one survives in the dict. This causes:

      • Expected dict: keeps only Deployment (from ALL_HCO_RELATED_OBJECTS)
      • Actual dict: keeps only ServiceAccount (last in HCO relatedObjects list)
      • DeepDiff reports values_changed: Deployment -> ServiceAccount

      Simply adding ServiceAccount entries to ALL_HCO_RELATED_OBJECTS will NOT fix the problem because the dict would still overwrite Deployment with ServiceAccount (or vice versa). The data structure itself is fundamentally broken for this use case.

      Evidence

      • Error: AssertionError: There are new HCO related objects: values_changed root kubevirt-console-plugin new_value ServiceAccount old_value Deployment, root kubevirt-apiserver-proxy new_value ServiceAccount old_value Deployment
      • HCO relatedObjects count: 40 actual vs 38 in ALL_HCO_RELATED_OBJECTS constant
      • HCO operator PR: https://github.com/kubevirt/hyperconverged-cluster-operator/pull/3953 (merged 2026-01-08, cherry-picked to release-1.17 via PR #3968 on 2026-01-15)
      • HCO change author: Oren Cohen (orenc1), JIRA: OCPBUGS-70353
      • Motivation: security hardening - pods should not use the default ServiceAccount
      • Jenkins: https://jenkins-csb-cnvqe-main.dno.corp.redhat.com/job/test-pytest-cnv-4.21-iuo-ocs/33/
      • ReportPortal: Launch #159769 - classified as To Investigate
      • Historical: Failed in builds #33 (current error), #28 and #27 (different error - ConsoleQuickStart removal)
      • Must-gather confirms: HCO status.relatedObjects contains both Deployment and ServiceAccount for kubevirt-console-plugin and kubevirt-apiserver-proxy

      Proposed Fix

      Two changes are required:

      1. Update ALL_HCO_RELATED_OBJECTS in utilities/constants.py

      Add two new ServiceAccount entries to the list:

      • KUBEVIRT_CONSOLE_PLUGIN: "ServiceAccount"
      • KUBEVIRT_APISERVER_PROXY: "ServiceAccount"

      2. Refactor comparison logic in test_hco_related_objects.py

      Replace dict-based comparison with set-of-tuples to support multiple resources with the same name but different kinds:

      Change actual_related_objects from dict comprehension (name: kind) to a set comprehension producing (name, kind) tuples. Apply the same change to expected_related_objects. Update the DeepDiff call to compare the two sets instead of dicts.

      This ensures all 40 relatedObjects are individually tracked without key collisions.

      Validation

      1. Verify ALL_HCO_RELATED_OBJECTS has 40 entries (was 38)
      2. Run test_no_new_hco_related_objects against a CNV 4.21.1 cluster
      3. Confirm the set comparison correctly detects additions and removals without key collisions
      4. Run pre-commit and tox to verify code quality

      Impact

      • Frequency: Persistent on CNV 4.21.1+ (will fail every run)
      • Jobs affected: test-pytest-cnv-4.21-iuo-ocs, test-pytest-cnv-4.21-post-upgrade-marker-iuo and all IUO tier2 jobs
      • CI impact: Consistent false failure masking real relatedObjects changes
      • Branches: main and cnv-4.21 need the fix
      • Contact: hmeir@redhat.com (IUO team owner)

              rlobillo Ramón Lobillo
              rlobillo Ramón Lobillo
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated: