[jira] [Updated] (KUDU-3084) Multiple time sources with fallback behavior between them

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

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

Grant Henke updated KUDU-3084:
------------------------------
    Labels: clock roadmap-candidate usability  (was: clock)

> Multiple time sources with fallback behavior between them
> ---------------------------------------------------------
>
>                 Key: KUDU-3084
>                 URL: https://issues.apache.org/jira/browse/KUDU-3084
>             Project: Kudu
>          Issue Type: Improvement
>          Components: master, tserver
>            Reporter: Alexey Serbin
>            Priority: Major
>              Labels: clock, roadmap-candidate, usability
>
> [~tlipcon] suggested an alternative approach to configure and select HybridClock's time source.
> Kudu servers could maintain multiple time sources and switch between them with a fallback behavior.  The default or preferred time source might be any of the existing ones (e.g., the built-in client), but when it's not available, another available time source is selected (e.g., {{system}} -- the NTP-synchronized local clock).  Switching between time sources can be done:
> * only upon startup/initialization
> * upon startup/initialization and later during normal run time
> The advantages are:
> * easier deployment and configuration of Kudu clusters
> * simplified upgrade path from older releases using {{system}} time source to newer releases using {{builtin}} time source by default
> There are downsides, though.  Since the new way of maintaining time source is more dynamic, it can:
> * mask various configuration or network issues
> * result in different time source within the same Kudu cluster due to transient issues
> * introduce extra startup delay



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