XMLWordPrintable

    • Icon: Epic Epic
    • Resolution: Duplicate
    • Icon: Undefined Undefined
    • None
    • None
    • Observability
    • None
    • MCO E2E tests simplification
    • False
    • None
    • False
    • Not Selected
    • To Do
    • 100% To Do, 0% In Progress, 0% Done

      E2E tests should consist of a select few cases that validate integration at the system level. These tests should cover what can't be validated in unit tests and lower level integration tests (with api-server and etcd, such as envtest). Specifically, they should:

      • Validate full kubernetes integration: pods are well scheduled and in running state
      • Validate integration with ACM: manifest works are propagated, addons are spawned in spokes, addon status is green
      • Validate communications between the hub and spokes: making sure that updates on the hub are propagated to the spokes, and that metrics/alerts are sent back to the hub
      • Possibly validate interaction with specific controllers like the cert manager if needed

      In current e2e, we have tests like:

      • Addon:
        • Should not have the expected MCO addon pods when disable observabilityaddon
        • resource requirements are propagated from addon to resources
        • Modifying MCO cr to enable observabilityaddon
        • Should not set interval to values beyond scope
        • Should not have the expected MCO addon pods when disable observability from managedcluster

      These are typically test can be executed ant the integration level.
      And this is just the addon_test file. There are ~15 files.

      Epic Goal

      Streamline e2e tests to achieve the following objectives:

      • Focus on e2e integration scenarios.
      • Increase reliability.
      • Simplify maintenance.
      • Reduce execution time.

      Why is this important?

      Failures in end-to-end tests, due to various reasons beyond the scope of this epic, have significantly hindered our development progress.

      Scenarios

      ...

      Acceptance Criteria

      ...

      Dependencies (internal and external)

      1. ...

      Previous Work (Optional):

      1. ...

      Open questions:

      Done Checklist

      • CI - CI is running, tests are automated and merged.
      • Release Enablement <link to Feature Enablement Presentation>
      • DEV - Upstream code and tests merged: <link to meaningful PR or GitHub
        Issue>
      • DEV - Upstream documentation merged: <link to meaningful PR or GitHub
        Issue>
      • DEV - Downstream build attached to advisory: <link to errata>
      • QE - Test plans in Polarion: <link or reference to Polarion>
      • QE - Automated tests merged: <link or reference to automated tests>
      • DOC - Doc issue opened with a completed template. Separate doc issue
        opened for any deprecation, removal, or any current known
        issue/troubleshooting removal from the doc, if applicable.

              Unassigned Unassigned
              rh-ee-tmange Thibault Mange
              Xiang Yin Xiang Yin
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated:
                Resolved: