EdColeman commented on a change in pull request #2467:
URL: https://github.com/apache/accumulo/pull/2467#discussion_r801738937
##########
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:
w.r.t cloning and allowing a compaction to complete was to highlight
that case because there maybe issues that I don't foresee - say you have
table_a and clone_a that was made from table_a - they have shared files and
possibly some unique files. If clone_a is compacted and then a delete request
for clone_a occurs - is there any benefit to table_a if the compaction was
allowed to complete? I don't "think so", but maybe?
In the case of trying to clone table_a and while that was in progress a
request to delete table_a is executed - allowing the clone to complete (which
should be fast) seems it would best preserve operator intent - but if the clone
was aborted, and table_a deleted, well, that might not be a complete surprise
either, If you wanted to clone the table, you shouldn't have deleted it until
you verified that the clone was complete - and maybe we just don't try to
protect from that.
Have clone wait on other operations on the source table would seem the best
to allow operator to reason about the state of the clone.
--
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]
