Skip to content

test: add Kuadrant operator metrics tests#876

Open
silvi-t wants to merge 1 commit intoKuadrant:mainfrom
silvi-t:kuadrant-metrics
Open

test: add Kuadrant operator metrics tests#876
silvi-t wants to merge 1 commit intoKuadrant:mainfrom
silvi-t:kuadrant-metrics

Conversation

@silvi-t
Copy link
Contributor

@silvi-t silvi-t commented Feb 25, 2026

Description

  • Add observability tests for Kuadrant operator health metrics (existence, readiness, components, dependencies, controllers)
  • Add observability tests for Kuadrant policy metrics (kuadrant_policies_total and kuadrant_policies_enforced) across all policy kinds
  • Add disruptive lifecycle test verifying policy metrics increment/decrement on policy create/delete
  • Fix assertion message in existing test_observability.py for clarity

Closes #875

Verification steps

poetry run pytest -vv -n4 --dist loadfile\
  testsuite/tests/singlecluster/observability/test_kuadrant_operator_health_metrics.py \
  testsuite/tests/singlecluster/observability/test_kuadrant_policy_metrics.py

The lifecycle test requires sequential execution (marked disruptive):

poetry run pytest -vv testsuite/tests/singlecluster/observability/test_kuadrant_policy_metrics_lifecycle.py

@silvi-t silvi-t self-assigned this Feb 25, 2026
Comment on lines +23 to +26
metrics = prometheus.get_metrics(
key="kuadrant_exists",
labels={"service": "kuadrant-operator-metrics", "namespace": settings["service_protection"]["system_project"]},
)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Try to get all relevant metrics only once, from the shared fixture. Then use .filter() on the returned structure to filter metrics you got from a single request to jaeger. Check out the methodology other testsuite tests for metrics follow

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I looked into the existing metrics tests and the .filter() approach isn't unified across the testsuite — some tests use has_label(), others use raw lambdas, and some don't use a shared fixture at all. I can refactor this tests to use the shared fixture + .filter()pattern.
Should I also refactor the other metric tests so that they use a uniform methodology, so that it will be unified throughout the test suite?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CoreDNS tests will probably have the best usage of the interface for metrics we have in the testsuite currently, I would inspire from them. The main point with filtering on already collected metrics is less API calls done from testsuite.

Should I also refactor the other metric tests so that they use a uniform methodology, so that it will be unified throughout the test suite?

that would be great, doesn't need to be in this PR though 👍

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've refactored the metrics tests based on the suggested CoreDNS pattern. I will also open a new issue to unify the rest of the metrics tests across the testsuite to follow the same approach, so we do not forget about that.

Signed-off-by: Silvia Tarabova <starabov@redhat.com>
@silvi-t silvi-t force-pushed the kuadrant-metrics branch from 1fd1a4f to e2181e6 Compare March 9, 2026 12:25
@silvi-t silvi-t mentioned this pull request Mar 9, 2026
9 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Kuadrant Operator Metrics

3 participants