[
https://issues.apache.org/jira/browse/HADOOP-14094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15872699#comment-15872699
]
Aaron Fabbri commented on HADOOP-14094:
---------------------------------------
Yes, s3a as the subcommand is confusing. e.g. {{hadoop s3a init}}, {{hadoop
s3a destroy}}.. fsck, etc... Especially since we want some s3a-only commands
in the near future, e.g. HADOOP-14007.
Three options I thought of:
{{hadoop s3guard <options>}}
{{hadoop s3a s3guard <options>}}
{{hadoop s3a [s3guard-init | s3guard-destroy | ...]}}
Any thoughts on implementation complexity for different options? I'm fine with
any of these to be honest.
What do other folks think?
As for the -Dkey=value option not working, i suppose we should look at why we
don't seem to be getting the generic options parsing. The basic command changes
feel like higher priority though, as adding support for generic command options
later should not break compatibility AFAICT. So maybe that can be followup
JIRA if needed?
IMO any syntax / option changes, along with consistent behavior of options
(endpoint etc) is the big priority at the moment.
> Rethink S3GuardTool options
> ---------------------------
>
> Key: HADOOP-14094
> URL: https://issues.apache.org/jira/browse/HADOOP-14094
> Project: Hadoop Common
> Issue Type: Sub-task
> Components: fs/s3
> Reporter: Sean Mackrory
>
> I think we need to rework the S3GuardTool options. A couple of problems I've
> observed in the patches I've done on top of that and seeing other developers
> trying it out:
> * We should probably wrap the current commands in an S3Guard-specific
> command, since 'init', 'destroy', etc. don't touch the buckets at all.
> * Convert to whole-word options, as the single-letter options are already
> getting overloaded. Some patches I've submitted have added functionality
> where the obvious flag is already in use (e.g. -r for region, and read
> throughput, -m for minutes, and metadatastore uri). I may do this early as
> part of HADOOP-14090.
> * We have some options that must be in the config in some cases, and can be
> in the command in other cases. But I've seen someone try to specify the table
> name in the config and leave out the -m option, with no luck. Also, since
> commands hard-code table auto-creation, you might have configured table
> auto-creation, try to import to a non-existent table, and it tells you table
> auto-creation is off.
> We need a more consistent policy for how things should get configured that
> addresses these problems and future-proofs the command a bit more.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org
