-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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
[kbn-es] await native realm setup, error if there are failures #36290
Conversation
Pinging @elastic/kibana-operations |
Looks like the port check is failing:
Additionally, if we are getting rid of the try/catch in |
This comment has been minimized.
This comment has been minimized.
Fixed the port issue (typo) and filtered out 400 errors, which is what we get when xpack is not included since the |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
retest |
💚 Build Succeeded |
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, just one minor nit regarding the log message with the mocked bin.
💚 Build Succeeded |
…ic#36290) * [kbn-es] await native realm setup, error if there are failures * cleanup listener from started promise too * fix typo * log native realm setup errors on run and handle 400 when xpack isn't available * avoid creating potentially unused promises * avoid Promise constructor that's larger than necessary * group similar operations, add some light comments * set passwords in parallel so that logging is grouped * update native realm tests * update es_bin fixture to handle _xpack requests * log started after server is listening * remove unused mockEsBin args * use more realistic http address log
… failures (elastic#36290)"" This reverts commit a102ca1.
…ic#36475) * Revert "Revert "[kbn-es] await native realm setup, error if there are failures (elastic#36290)"" This reverts commit a102ca1. * [kbn/es] retry setPassword call if it fails
While trying to debug some transient es security failures we've been seeing I noticed that the native realm setup logic is outside of the promise chain and isn't guaranteed to be done before the promise returned by
Cluster#start()
resolves. Additionally, errors in that process do not bubble up, but are logged in a way that's too easy to miss.This moves the nativeRealm setup to its own promise, along with the http port discovery, and consumes them as necessary.