Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update Deep Metrics test when https://github.com/Kuadrant/kuadrant-operator/issues/1035 is resolved #602

Open
jsmolar opened this issue Nov 21, 2024 · 4 comments

Comments

@jsmolar
Copy link

jsmolar commented Nov 21, 2024

Remove standalone_only from test_deep_metrics.py when Kuadrant/kuadrant-operator#1035 is resolved.

Line change will be needed, to reflect a new name, or tag that will be added to metric:
and x["metric"]["authconfig"].endswith(authorization.name())

@github-project-automation github-project-automation bot moved this to 🆕 New in Kuadrant QE Nov 21, 2024
@jsmolar jsmolar moved this from 🆕 New to 📋 Backlog in Kuadrant QE Dec 19, 2024
@Boomatang
Copy link

This issue is linked to a kuadrant-operator issue: Kuadrant/kuadrant-operator#1035 We are not sure why the work in the kuadrant-operator needs to be done. We don't know what the use case is. Can there be more information given?

@averevki
Copy link
Contributor

@Boomatang I believe the issue was that you couldn't trace what AuthPolicy this metric belongs to without knowing the name of the generated AuthConfig. Before, the AuthConfig name was generated using the AuthPolicy name, and now it is a derived hash, which user can not know without looking at the implementation.

I'm not sure where this issue belongs to, kuadrant or authorino operator. We can move it to where it will be more appropriate.

@Boomatang
Copy link

The issue is within the kuadrant operator. So the thing I am trying to work out is much priority we need to give this issue? What value is gained by the test? Is there away other we could test this?

@averevki
Copy link
Contributor

Well, as I see, the deep metrics work as they supposed to. Only thing that there is no method to identify which authpolicy this metric belongs to(in case there are multiple of them). So I would assign it the same priority as you give to the observability features, maybe lower.

In the current state, we aren't able to automate deep metrics reporting on Kuadrant before some method of traceability appears here. In the meantime, we rolled back to testing deep metrics only on a standalone authorino instances, where we can choose the AuthConfig name ourselves and match it with the generated metrics.

Ultimately, for me, it narrows down to the existence of some link between AuthPolicies and AuthConfig generated for them (any reference, annotation, known name generation, etc.). Without this link, I think, it isn't possible for now to test this in the automated way.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: 📋 Backlog
Development

No branches or pull requests

3 participants