ctubbsii commented on a change in pull request #2467:
URL: https://github.com/apache/accumulo/pull/2467#discussion_r802197735
##########
File path:
shell/src/main/java/org/apache/accumulo/shell/commands/FateCommand.java
##########
@@ -136,7 +140,29 @@ public int execute(final String fullCommand, final
CommandLine cl, final Shell s
getZooReaderWriter(context, siteConfig,
cl.getOptionValue(secretOption.getOpt()));
ZooStore<FateCommand> zs = new ZooStore<>(path, zk);
- if ("fail".equals(cmd)) {
+ if ("fail-live".equals(cmd)) {
Review comment:
> Feedback from user(s) is:
>
> 2. Stopping the Manager is a problem because they can't load data via bulk
imports, they have strict timeliness requirements. They have to stop bulk
imports from getting kicked off, wait for the current ones to finish, then take
down the Manager. Stopping the Manager also stops any long-running WAL recovery
due to a failed TServer, table balancing, etc.
I understand stopping the manager is not preferred. I'm not sure lowering
the bar to surgery by allowing it to be performed on a conscious patient is the
right solution, though (might be taking the metaphor too far here :smiley_cat:
). I'd rather focus efforts on surgery-prevention, if we can. For example,
using the new bulk imports, using the new working compaction queue
cancellation, figuring out why 1.x compactions can't be cancelled, etc., would
be a great start. Adding range locks for compaction/merge/delete would also be
great.
Right now, this seems very risky to add, especially since we haven't even
ironed out the kinks in the other recent changes in these areas.
ExternalCompactions ITs are still flaky, and now FateIT is failing too. These
imply that there is instability in this code. Giving users more direct access
to making live changes to internals, when we haven't ironed out those internals
in our own tests, seems very high risk, and the wrong solution to the
underlying problems users are seeing. If all those other things were working
well, I would be less opposed to taking the risk here, but they're not. So,
this risk just seems too much right now.
--
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]
