ctubbsii commented on a change in pull request #2467:
URL: https://github.com/apache/accumulo/pull/2467#discussion_r802669973



##########
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:
       > > might be taking the metaphor too far here
   > 
   > I'm not convinced that it's the right one as it's 
[documented](https://accumulo.apache.org/docs/2.x/administration/fate). For me, 
surgery is manually inserting / updating / deleting rows from the metadata 
table.
   
   Internals can still be documented. We document the metadata structure and 
have shared knowledge in various forms on how to do that kind of surgery as 
well. The key point for me is that FaTE operations don't have a public API. It 
is an implementation detail of other operations. In any case, if it helps, I'm 
happy to concede that surgery is not a great metaphor, but I do think it's 
worth noting that users should never have to touch with it under normal 
operations.
   
   > 
   > > 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.
   > 
   > I"m starting to think the issue is ZK based on the information you added 
to in #2463 and the fact that FateIT has one test.
   
   Perhaps. More troubleshooting needs to be done for those, I think, to draw a 
sound conclusion. The relevance for this PR, though, is that I would like to 
hold off on introducing more high-risk, potentially destabilizing code, until 
the reliability of what's there now is improved.




-- 
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]


Reply via email to