cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Brown (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-12627) Provide new seed providers
Date Fri, 04 Nov 2016 23:57:58 GMT

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

Jason Brown commented on CASSANDRA-12627:
-----------------------------------------

bq. Operators should not actually need to muck around with the yaml file anyway

Well, you already need to edit the yaml in order to define the {{SeedProdvider}}, let alone
setting addresses, ports, and the like. For better or worse, operators will need to deal with
the yaml. Thus, I'm -1 on {[PropertyOrEnvironmentSeedProvider}}.

{{NeighborSeedProvider}} gets into equally an unexpected space, as well. By naively setting
the {{scan.distance}} too wide, we'd include nodes in the list that do not exist or are not
c* nodes. In {{Gossiper}}, we will try to connect and gossip with those nodes as seeds ({{Gossiper#maybeGossipToSeed()}}).
That means extra unix sockets (really not a problem), but also extra threads due to the existing
internode messaging service implementation (see {{OutboundTcpConnectionPool}}). Those extra
threads are expensive in large clusters. I'm not convinced that setting explicit addresses
as the seed(s) is more difficult or requires more config understanding than defining a {{scan.distance}}.
Again, I'm -1 on {{NeighborSeedProvider}}

bq. why is the configuration so obtuse and plugable if only one implementation exists?

For the record, there are other provider implementations, some public (like [Priam|https://github.com/Netflix/Priam/blob/master/priam-cass-extensions/src/main/java/com/netflix/priam/cassandra/extensions/NFSeedProvider.java]),
some private. In those cases, special functionality is needed, and the space to plug it in
is provided. The trade off, of course, is an increased config complexity that affects all
users, in some small way.

I agree that the yaml config is non-trivial, but even that is pluggable. If we want to entertain
a "config-lite" for new users/operator to get something stood up quickly, that might be a
great thing - but outside the scope of this ticket.


> Provide new seed providers
> --------------------------
>
>                 Key: CASSANDRA-12627
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-12627
>             Project: Cassandra
>          Issue Type: New Feature
>            Reporter: Edward Capriolo
>            Assignee: Edward Capriolo
>
> SeedProvider is plugable, however only one implementation exists.
> Changes:
> * Create a SeedProvider that reads properties from System properties or env
> * Provide a SeedProvider that scans ranges of IP addresses to find peers.
> * Refactor interface to abstract class because all seed providers must provide a constructor
that accepts Map<String,String> 
> * correct error messages
> * Do not catch Exception use MultiCatch and catch typed exceptions



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message