You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Jason Brown (JIRA)" <ji...@apache.org> on 2016/11/04 17:52:58 UTC

[jira] [Commented] (CASSANDRA-12627) Provide new seed providers

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

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

Thanks for the patch , [~appodictic]. Here's my initial thoughts:

- {{SeedProvider}}, I agree that anyone wanting to implement their own provider would need to know (and probably trip up on) that we require a constructor that takes a {{Map<String, String>}} as an argument. That change makes sense.

- {{PropertyOrEnvironmentSeedProvider}}, I'm trying to understand the upside value of this. Sure, it's hypothetically "simpler" to pass in a {{-D}} prop or set an env variable, but won't operators already need to muck about with the yaml anyways, for other values? By introducing this new seed provider, do we just spread out the configuration burden to more places?

- {{NeighborSeedProvider}}, can you explain what the value is of this class? It appears to naively add a range of {{InetAddress}} centered around the current node's address - and then use those as seeds. That seed list would only be visible on that node as we don't have a shared, distributed notion of what nodes are "seeds". I'm trying to imagine where {{NeighborSeedProvider}} would be useful, especially in a "cloud environment", where IP address assignment, at least from my previous EC2 experience, is largely random.

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