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
Add e2e test on secret update for PrometheusAgent #6426
base: main
Are you sure you want to change the base?
Conversation
Thanks for tackling this issue anyway! I'm not entirely sure how this can be tested as well, some ideas that I had:
|
Since we're looking at end-to-end tests, I would tackle it from the end-user's standpoint: "I updated the credentials used to connect to my target but the update was never propagated to Prometheus and scrapes started to fail". In practice:
|
Signed-off-by: Mohammad Jamshidi <jamshidi.m799@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm struggling a bit to understand the correctness of the test. Is abc
a valid bearertoken? Could we add comments to the code explaining the test a little bit?
t.Fatal(err) | ||
} | ||
|
||
time.Sleep(time.Minute * 2) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe WaitForHealthyTargets
already waits until it finds the healthy targets. What do you think about removing this sleep then?
if err := framework.WaitForHealthyTargets(context.Background(), ns, "prometheus-agent-operated", 1); err == nil { | ||
t.Fatal("All targets should be down") | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If all targets should be down, why do we look for 1 healthy target?
It fixes #6414
Type of change
What type of changes does your code introduce to the Prometheus operator? Put an
x
in the box that apply.CHANGE
(fix or feature that would cause existing functionality to not work as expected)FEATURE
(non-breaking change which adds functionality)BUGFIX
(non-breaking change which fixes an issue)ENHANCEMENT
(non-breaking change which improves existing functionality)NONE
(if none of the other choices apply. Example, tooling, build system, CI, docs, etc.)Verification
Please check the Prometheus-Operator testing guidelines for recommendations about automated tests.
Changelog entry
Please put a one-line changelog entry below. This will be copied to the changelog file during the release process.