[ https://issues.apache.org/jira/browse/KUDU-1948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16800423#comment-16800423 ]
Yingchun Lai edited comment on KUDU-1948 at 3/31/19 3:29 AM: ------------------------------------------------------------- [~adar] Some questions by gflags: * Seemed use `–flagfile file_path` doesn't reduce the command line length much * Command line arguments order may looks odd. e.g. {code:java} kudu table rename old_name --flagfile /path/to/cluster_one new_name{code} I agree that comments in JSON are unsupported or hacked(On my own branch, I use an extra "comment" field in deed). So my points are: * Configuration file is for CLI tool, not for client library, we can add a cluster name resolve feature for it. * Do not change the old command line style, i.e. keep cluster name as a required argument follow the action name. * Use YAML as the config file format(We have to introduce a third-party YAML parser for it). was (Author: acelyc111): Some questions by gflags: * Seemed use `–flagfile file_path` doesn't reduce the command line length much * Command line arguments order may looks odd. e.g. {code:java} kudu table rename old_name --flagfile /path/to/cluster_one new_name{code} I agree that comments in JSON are unsupported or hacked(On my own branch, I use an extra "comment" field in deed). So my points are: * Configuration file is for CLI tool, not for client library, we can add a cluster name resolve feature for it. * Do not change the old command line style, i.e. keep cluster name as a required argument follow the action name. * Use YAML as the config file format(We have to introduce a third-party YAML parser for it). > Client-side configuration of cluster details > -------------------------------------------- > > Key: KUDU-1948 > URL: https://issues.apache.org/jira/browse/KUDU-1948 > Project: Kudu > Issue Type: New Feature > Components: client, security > Affects Versions: 1.3.0 > Reporter: Todd Lipcon > Assignee: Grant Henke > Priority: Major > > In the beginning, Kudu clients were configured with only the address of the > single Kudu master. This was nice and simple, and there was no need for a > client "configuration file". > Then, we added multi-masters, and the client API had to take a list of master > addresses. This wasn't awful, but started to be a bit aggravating when trying > to use tools on a multi-master cluster (who wants to type out three long > hostnames in a 'ksck' command line every time?). > Now with security, we have a couple more bits of configuration for the > client. Namely: > - "require SSL" and "require authentication" booleans -- necessary to prevent > MITM downgrade attacks > - custom Kerberos principal -- if the server wants to use a principal other > than 'kudu/<HOST>@REALM' then the client needs to know to expect it and fetch > the appropriate service ticket. (Note this isn't yet supported but would like > to be!) > In the future, there are other items that might be best specified as part of > a client configuration as well (e.g. CA cert for BYO PKI, wire compression > options, etc). > For the above use cases it would be nicer to allow the various options to be > specified in a configuration file rather than adding specific APIs for all > options. -- This message was sent by Atlassian JIRA (v7.6.3#76005)