[jira] [Commented] (KUDU-1948) Client-side configuration of cluster details

["Yingchun Lai (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/KUDU-1948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16799491#comment-16799491 ] 

Yingchun Lai commented on KUDU-1948:
------------------------------------

Agree with [~danburkert] .

But I want to introduce a simple cluster name resolver for CLI tools. CLI tool is an application right? I think it's reasonable to introduce a simple configuration file for it.

As a Kudu administrator, I'm boring to type multi-masters ip:port when I use CLI tools to access a cluster, they are long and not easy to remember, instead, it's easy to use it like:

 
{code:java}
kudu table list cluster_name{code}
We can use either master address list or cluster name to access a cluster.

Of course, there should be a way to distinguish them:

eg.
 * cluster name should not contain any ':' or ','
 * master address list string must contain ':' or ','
 * default port should not omit master in address list string 

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.

 

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