-
Notifications
You must be signed in to change notification settings - Fork 9
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
_start_opensearch
does not catch OpenSearchUserMgmtError
#164
Comments
_start_opensearch
does not catch _start_opensearch
does not catch OpenSearchUserMgmtError
So, I did some more digging on this issue. In a nutshell, I believe we try to access the .opensearch-security index, which is hosted on unit opensearch/3, at the moment that unit is restarting. The main question here is where was the valid replicas of There are 3x OpenSearch nodes:
The node having an issue is
On the logs above, it is possible to see that multiple calls actually go through, but eventually the Looking at the logs of opensearch/4, I can see the unit loses contact with
Then, the unit is removed:
Now, looking into unit
and only comes back on 08:12:30:
So, |
This is not quite accurate, search requests restrict the search to the local node only if added |
Hi @Mehdi-Bendriss this GET is not a search but rather a GET against one of the plugins. The actual call that breaks is:
Which is present here And this log line:
Does not specify any parameters, at least not injected in the URL. |
The main goal is to have a more controlled stop routine, where it is checked if all shards belonging to the given node are reassigned or failing otherwise. That behavior can also be toggled with an option: soft=False to untoggle it. Option set as True by default. Fixes-Bug: #164
There seems to be some race condition happening at
_post_start_init
, where some of the CI tests fail withOpenSearchUserMgmtError
. That is caused in the stack at the end.Side note:
_post_start_init
should be renamed to something else, as it runs as the very first line at_start_opensearch
.Stack trace: https://pastebin.ubuntu.com/p/WRMY3FnZCc/
The text was updated successfully, but these errors were encountered: