[
https://issues.apache.org/jira/browse/KUDU-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16409810#comment-16409810
]
Adar Dembo commented on KUDU-1372:
----------------------------------
{quote}you still think there's something we should do here, given the various
improvements over the last two years?
{quote}
Yes and no.
On the one hand, the original Jira was somewhat vague in what it was asking
for, and vague Jiras are generally unproductive.
On the other hand, we've always had a steady trickle of new users who show up
with either a client-side exception or a server-side log message and ask us to
tell them what's going on. Often times they've deployed in a toy environment,
maybe just one machine, maybe within VMs, maybe using /etc/hosts for name
resolution, etc. The original Jira mentioned metrics/logs/dashboards, but I'm
starting to think that a CLI tool would be an ideal way to deal with this. If
we had a one-stop cluster-wide connectivity checking tool (like ksck, or
perhaps even ksck itself), that would help supporting these cases significantly.
> Verify cluster-wide master and tserver connectivity
> ---------------------------------------------------
>
> Key: KUDU-1372
> URL: https://issues.apache.org/jira/browse/KUDU-1372
> Project: Kudu
> Issue Type: Improvement
> Components: ops-tooling, supportability
> Affects Versions: 0.7.1
> Reporter: Adar Dembo
> Priority: Major
>
> Kudu clusters need full-duplex connectivity inside of Raft configurations
> (masters or tservers), as well as between masters and tservers themselves. No
> doubt users will run into all sorts of issues with only partially configured
> firewalls.
> Let's do what we can to surface connectivity failures, be they inside of a
> Raft configuration or between a particular master and tserver. Metrics, log
> output, and web UI dashboards are all good places to surface these failures.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
