[
https://issues.apache.org/jira/browse/KUDU-1948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16800185#comment-16800185
]
Adar Dembo commented on KUDU-1948:
----------------------------------
[~acelyc111] couldn't you do cluster name resolution via different flag files?
For example:
File named 'cluster_one' with contents:
{noformat}
--master_addresses=host1,host2,host3
{noformat}
File named 'cluster_two' with contents:
{noformat}
--master_addresses=host4,host5,host6
{noformat}
Then switching between clusters become:
{noformat}
kudu table list --flagfile /path/to/cluster_one
{noformat}
Or:
{noformat}
kudu table list --flagfile /path/to/cluster_two
{noformat}
>From reading through Todd and Dan's past comments, it sounds like there's
>still some uncertainty as to whether CLI tools should automatically opt into
>client configs from a well-known location or not. If not, then I think flag
>files, although clunkier than pure cluster name resolution, get us 80% of the
>way there. What do you think?
{quote}
We can reuse most code of JsonReader, and introduce a new class JsonFileReader
to read configurations from a JSON config file, place it in a path like
$KUDU_HOME, so it's not needed to add any new gflags.
{quote}
I would strongly recommend against using JSON for configuration because you
can't use comments, and comments really important for config file maintenance.
Some JSON parsers support comments, and there are hacks (i.e. include a
"comment" field in objects that is ignored), but by and large it's not
universal and therefore rare. This is one of the reasons that Todd originally
suggested YAML, and I'd be fine with that or any other format that supported
commenting.
> 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)
