bbeaudreault commented on a change in pull request #3536:
URL: https://github.com/apache/hbase/pull/3536#discussion_r679472058
##########
File path: hbase-client/src/main/java/org/apache/hadoop/hbase/client/Admin.java
##########
@@ -1253,6 +1253,15 @@ default boolean balancer() throws IOException {
*/
boolean balance() throws IOException;
+ /**
+ * Invoke the balancer in dry run mode. Will show plan but not actually move
any regions.
+ * Can NOT run for various reasons. Check logs.
+ *
+ * @return <code>true</code> if dry run ran, <code>false</code> otherwise.
+ * @throws IOException if a remote or network exception occurs
+ */
+ boolean dryRunBalance() throws IOException;
Review comment:
I could do that. I didn't initially do that for a few reasons:
- There are already a lot of overloads of `balance()`, between the
deprecated `balancer()` and the `boolean force`.
- I didn't want to add another boolean argument. IMO an interface
`balance(boolean, boolean)` can be easily messed up. I could expose a
client-side version of RunMode enum though, but in order to preserve backwards
compatibility we'd have to add a whole set of new overloads.
- In the comments of HBASE-26147 we discussed enhancing dry run mode to
accept config overrides for cost functions. This would make it much more
intuitive to iterate on cost functions without doing a bunch of gymnastics. If
we wanted to do that, we'd need to add another argument that would be specific
to dry run mode which would further complicate the interface of `balance()`.
To the last reason, I could plan ahead for that and have `balance()` take a
BalancerConfig object instead of an enum. That'd give us the future flexibility
to add config overrides to just dry run mode, but it's a more complex interface
and not _that_ much better than having 2 separate methods.
Do you have any opinions on the above? I'm not sure how the hbase devs weigh
interface change questions like this.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]