[jira] [Assigned] (KUDU-3211) Add a cluster supported features request

["Grant Henke (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/KUDU-3211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Grant Henke reassigned KUDU-3211:
---------------------------------

    Assignee:     (was: Grant Henke)

> Add a cluster supported features request
> ----------------------------------------
>
>                 Key: KUDU-3211
>                 URL: https://issues.apache.org/jira/browse/KUDU-3211
>             Project: Kudu
>          Issue Type: Improvement
>          Components: master, supportability
>    Affects Versions: 1.13.0
>            Reporter: Grant Henke
>            Priority: Major
>
> Recently we have come across a few scenarios where it would be useful to make decisions in client integrations (Backup/Restore, Spark, NiFi, Impala) based on the supported features of the target Kudu cluster. This can especially helpful when we want to use new features by default if available but using the new feature requires client/integration logic changes. 
> Some recent examples:
> - Push bloomfilter predicates only if supported
> - Use insert ignore operations (vs session based ignore) only if supported
> It is technically possible to be optimistic about the support of a feature and try to handle errors in a clever way using the required feature capabilities of the RPCs. However, that can be difficult to express and near impossible if you want to make a decision for multiple requests or based on what all tablet servers support instead of based on a single request to a single tablet server.
> Additionally now that we support rolling restart, we can't assume that because a single master or tablet server supports a feature that all servers in the cluster support the feature.
> Some thoughts on the feature/implementation:
> - This should be a master request in order to prevent needing to talk to all the tablet servers.
> - We could leverage server registration requests or heartbeats to aggregate the current state on the leader master. 
> - We could represent these features as "cluster" level features and indicate that some (union) or all (intersect) of the servers support a given feature.
> - If this request/response is not available in a cluster the response would indicate that feature support is unknown and the user can decide how to proceed.
> - If we want to support disabling features via runtime flags we will need to ensure we update the master, maybe via heartbeat, with changed support for a running server.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)