-
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
[CI] denying access as action [internal:admin/tasks/ban] is not an index or cluster action #54887
Comments
Pinging @elastic/es-distributed (:Distributed/Task Management) |
Pinging @elastic/ml-core (:ml) |
I took a look at the failure. The warning was logged when we were sending unban requests; thus, it should not be the cause of the failure. I have integrated #55404 to make sure that unban requests will be sent in the right context. @droberts195 Would you like to continue investigating this failure, or let's close and wait for the next occurrence? I have removed my assignment and updated the label as I think the task framework issue is resolved. Thank you for reporting this :). |
OK, I think the ML problem is probably that we need to wait for indices to have their replicas allocated before upgrading during the rolling upgrade tests. There's a message in the log of this test |
There have been a few test failures that are likely caused by tests performing actions that use ML indices immediately after the actions that create those ML indices. Currently this can result in attempts to search the newly created index before its shards have initialized. This change makes the method that creates the internal ML indices that have been affected by this problem (state and stats) wait for the shards to be initialized before returning. Fixes elastic#54887 Fixes elastic#55221 Fixes elastic#55807 Fixes elastic#57102 Fixes elastic#58841 Fixes elastic#59011
…#59027) There have been a few test failures that are likely caused by tests performing actions that use ML indices immediately after the actions that create those ML indices. Currently this can result in attempts to search the newly created index before its shards have initialized. This change makes the method that creates the internal ML indices that have been affected by this problem (state and stats) wait for the shards to be initialized before returning. Fixes #54887 Fixes #55221 Fixes #55807 Fixes #57102 Fixes #58841 Fixes #59011
An ML test failed in https://gradle-enterprise.elastic.co/s/d5tipghjjliwc
The error was:
However, the server side logs (downloadable from https://elasticsearch-ci.elastic.co/job/elastic+elasticsearch+master+matrix-java-periodic/ES_RUNTIME_JAVA=adoptopenjdk11,nodes=general-purpose/616/gcsObjects/) show the following error was the root cause:
That message is from
x-pack/qa/rolling-upgrade/build/testclusters/v8.0.0-1/logs/v8.0.0.log
.It looks like the ban action needs to be called from within the system security context, and this does not always happen (although it must happen sometimes by coincidence as the test failure is quite rare).
The text was updated successfully, but these errors were encountered: