So for "rolling create new" strategy, constructor don't check the available resource for the plan like "create new" strategy. But this will bring an incomplete plan execution.
What I expect is that constructor can use the same resource capacity validation algorithm both for "create new " or "rolling create new" strategy. Because we have limited resource, so we choose "rolling create new" as the default strategy.
We hope that we can break the plan execution immediately if there is not enough capacity.
Rolling grow+shrink was something of a workaround because when we released ECE, "pure" rolling plans weren't quite robust enough to present as an option (and many ECE users didn't have enough capacity to do "full" grow+shrink). As a result, it still has some known rough edges - including the one you point out here.
From 1.1.5 onwards, rolling plans have been "production ready", and as of the (just-released!) 2.1.0 the standard UI always allows the option of rollling. (We don't mark it as default yet, that will come soon though)
As a result, rolling grow+shrink should not really be used any more (the only real use cases are: maintaining availability during changes to "large" (*) single zone cluster, and switching "large" clusters from being master+data to master-only + data-only)
(*) "large" meaning that there is less than that cluster size's allocatable space remaining in 1+ zones
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.