Only block readiness if no file settings have been applied yet #107620
Conversation
…o not block on previous errors.
| @@ -254,7 +254,7 @@ public void clusterChanged(ClusterChangedEvent event) { | |||
| // protected to allow mock service to override | |||
| protected boolean areFileSettingsApplied(ClusterState clusterState) { | |||
| ReservedStateMetadata fileSettingsMetadata = clusterState.metadata().reservedStateMetadata().get(FileSettingsService.NAMESPACE); | |||
| return fileSettingsMetadata != null && fileSettingsMetadata.errorMetadata() == null; | |||
| return fileSettingsMetadata != null && fileSettingsMetadata.version() > 0; | |||
There was a problem hiding this comment.
Unfortunately this isn't going to be reliable, version might be > 0 despite the first settings not being applied.
The way I understand it, as soon as we're able to read / parse the file, we would write the version of it's metadata when writing the error state :/
Maybe we have to better differentiate errors that are permanent and transient. And in the latter case, allow to reprocess the file settings. Currently, if we see the same version again, we discard the update and not try again.
|
I was looking into |
|
I opened a slight alternative to this in #107738. |
Only block readiness if no file settings have been applied yet, but do not block on previous errors.
This allows nodes to start up if previous file settings exist regardless if an error has been recorded.
Otherwise, unless the file settings version changes, the settings won't be re-applied if their version matches. But in that case the error won't ever be cleared and the nodes just remain not ready.