Skip to content

Consider node ready on any file settings applied #107738

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

Merged

Conversation

rjernst
Copy link
Member

@rjernst rjernst commented Apr 22, 2024

Readiness is blocked in file based settings having been applied. Yet in the case that an error occurs in a subsequent file based settings update, readiness will stop working. This was unintentional; if file based settings have already been applied once, subsequent failures to apply file based settings should not affect the running system.

This commit adjusts the readiness check to consider any file based settings having been applied as allowing the node to be ready.

Readiness is blocked in file based settings having been applied. Yet in
the case that an error occurs in a subsequent file based settings
update, readiness will stop working. This was unintentional; if file
based settings have already been applied once, subsequent failures to
apply file based settings should not affect the running system.

This commit adjusts the readiness check to consider any file based
settings having been applied as allowing the node to be ready.
@rjernst rjernst added >non-issue :Core/Infra/Core Core issues without another label labels Apr 22, 2024
@elasticsearchmachine elasticsearchmachine added Team:Core/Infra Meta label for core/infra team v8.15.0 labels Apr 22, 2024
@elasticsearchmachine
Copy link
Collaborator

Pinging @elastic/es-core-infra (Team:Core/Infra)

@mosche mosche self-requested a review April 23, 2024 06:28
@mosche
Copy link
Contributor

mosche commented Apr 23, 2024

Unfortunately ReadinessClusterIT.testNotReadyOnBadFileSettings is failing, currently looking into it.

@mosche
Copy link
Contributor

mosche commented Apr 23, 2024

I've disabled the failing test and created #107744 to tackle the issue in a follow up to not block this from getting merged asap. Broken file settings should be an absolutely rare corner case, so this should be fine.

Copy link
Contributor

@mosche mosche left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lgtm, as mentioned above we'll tackle bad initial file settings in a follow up.

@mosche mosche merged commit 0b4620e into elastic:main Apr 23, 2024
14 checks passed
rjernst added a commit to rjernst/elasticsearch that referenced this pull request Apr 23, 2024
If file settings have an update that fails, existing applied file
settings continue to work. But if the initial file settings fail to
process, readiness should be blocked. This commit adjusts readiness to
look for this special initialization case.

relates elastic#107738
rjernst added a commit that referenced this pull request Apr 26, 2024
If file settings have an update that fails, existing applied file
settings continue to work. But if the initial file settings fail to
process, readiness should be blocked. This commit adjusts readiness to
look for this special initialization case.

relates #107738
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:Core/Infra/Core Core issues without another label >non-issue Team:Core/Infra Meta label for core/infra team v8.15.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants