success is {@code false}. */
- public static void close(boolean success, Iterablesuccess is {@code false}. */
- public static void close(boolean success, Releasable... releasables) {
- close(success, Arrays.asList(releasables));
+ private static void close(boolean success, Releasable... releasables) {
+ try {
+ // this does the right thing with respect to add suppressed and not wrapping errors etc.
+ IOUtils.close(releasables);
+ } catch (IOException e) {
+ if (success) {
+ throw new UncheckedIOException(e);
+ }
+ }
}
/** Wrap several releasables into a single one. This is typically useful for use with try-with-resources: for example let's assume
diff --git a/libs/core/src/test/java/org/elasticsearch/core/IOUtilsTests.java b/libs/core/src/test/java/org/elasticsearch/core/IOUtilsTests.java
index 719c2e3ef4846..0d7576a56acb0 100644
--- a/libs/core/src/test/java/org/elasticsearch/core/IOUtilsTests.java
+++ b/libs/core/src/test/java/org/elasticsearch/core/IOUtilsTests.java
@@ -117,10 +117,6 @@ public void testDeleteFilesIgnoringExceptionsArray() throws IOException {
runDeleteFilesIgnoringExceptionsTest(Function.identity(), IOUtils::deleteFilesIgnoringExceptions);
}
- public void testDeleteFilesIgnoringExceptionsIterable() throws IOException {
- runDeleteFilesIgnoringExceptionsTest((Function+ * This concept is useful as it provides more context about future topology changes to the system + * as well as the desired set of nodes in the cluster, allowing it to make better decisions + * about allocation, autoscaling, auto-expand replicas, etc. + *
+ * + *+ * Additionally, settings validation is done during desired nodes updates avoiding boot-looping + * when an invalid setting is provided before the node is started. + *
+ * + *+ * To modify the desired nodes it is necessary to provide the entire collection of nodes that will + * be part of the proposed cluster topology. + *
+ * + *+ * Desired nodes are expected to be part of a lineage defined by the provided {@code historyId}. + * The {@code historyId} is provided by the orchestrator taking care of managing the cluster. + * In order to identify the different proposed desired nodes within the same history, it is + * also expected that the orchestrator provides a monotonically increasing {@code version} + * when it communicates about future topology changes. + * The cluster rejects desired nodes updated with a {@code version} less than or equal + * than the current {@code version} for the same {@code historyId}. + *
+ * + *+ * The {@code historyId} is expected to remain stable during the cluster lifecycle, but it is + * possible that the orchestrator loses its own state and needs to be restored to a + * previous point in time with an older desired nodes {@code version}. In those cases it is + * expected to use new {@code historyId} that would allow starting from a different version. + *
+ * + *+ * Each {@link DesiredNode} part of {@link DesiredNodes} has a {@link DesiredNodeWithStatus.Status} + * depending on whether or not the node has been part of the cluster at some point. + *
+ * + * The two possible statuses {@link DesiredNodeWithStatus.Status} are: + *+ * See {@code JoinTaskExecutor} and {@code TransportUpdateDesiredNodesAction} for more details about + * desired nodes status tracking. + *
+ * + *+ * Finally, each {@link DesiredNode} is expected to provide a way of identifying the node when it joins, + * {@link Node#NODE_EXTERNAL_ID_SETTING} allows providing that identity through settings. + *
+ * + */ public class DesiredNodes implements Writeable, ToXContentObject, Iterable