-
Notifications
You must be signed in to change notification settings - Fork 25k
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
Handle expired tokens in cluster migration tests #89422
Handle expired tokens in cluster migration tests #89422
Conversation
assertEquals(false, bulkResponseMap.get("errors")); | ||
} | ||
|
||
private void refreshSecurityTokensIndex() throws IOException { |
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.
This may be overkill but I want to avoid weird flakiness here -- it would take forever to debug for someone looking at this in the future.
@elasticsearchmachine update branch plz |
@elasticsearchmachine run elasticsearch-ci/part-2 |
Pinging @elastic/es-security (Team:Security) |
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.
LGTM
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.
LGTM
This PR addresses a failure around token BWC during cluster upgrade
tests: the tests assert that tokens created in a cluster before (or
during) an upgrade are still valid in the mixed or upgraded clusters.
Our cluster upgrade test suites are long running however such that
tokens created in the old (or mixed) cluster may be expired by the time
we test their validity. The maximum lifetime of tokens is configured
via a setting which has a max value of 1h. This PR extends the lifetime
of all tokens by writing to the
.security-tokens
index directly, foreach test where this is necessary. This (hacky) solution allows us to
robustly exercise the target path of the test (validating that a token
is valid and authenticates correctly) while keeping the fix confined to
test code (as opposed to solving this via a system property).
Closes #77350