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

["Edward Capriolo (JIRA)" <ji...@apache.org>]

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

Edward Capriolo edited comment on CASSANDRA-12627 at 11/4/16 8:02 PM:
----------------------------------------------------------------------

PropertyOrEnvironmentSeedProvider 

{quote}
muck about with the yaml anyways
{quote}

Operators should not actually need to muck around with the yaml file anyway. In the old cassandra days we ONLY had the configuration file to find seeds. Now the known hosts are stored in system tables anyway. Thus the seeds defined in the yaml file are fairly useless after initialization just like the tokens. We should break free of maintaining this. 

NeighborSeedProvider you are correct to say that this implementation is not useful in a cloud environment with random IP allocation. However in non-cloud environments machines are typically given IP addresses in a subnet and for large networks and administrator will pre-allocate a subnet.

For example, an administrator will say we are going to use the network 10.1.1.0/255.255.255.0 as a class C network for Cassandra servers. Given our own IP address we can know where the others will be. 

In general you can argue the merits of each provider. The next logical question is why is the configuration so obtuse and plugable if only one implementation exists?


was (Author: appodictic):
PropertyOrEnvironmentSeedProvider 

{quote}
muck about with the yaml anyways
{quote}

Operators should not actually need to muck around with the yaml file anyway. In the old cassandra days we ONLY had the configuration file to find seeds. Now the known hosts are stored in system tables anyway. Thus the seeds defined in the yaml file are fairly useless after initialization just like the tokens. We should break free of maintaining this. 

NeighborSeedProvider you are correct to say that this implementation is not useful in a cloud environment with random IP allocation. However in non-cloud environments machines are typically given IP addresses in a subnet and they for large networks and administrator will pre-allocate a subnet.

For example, an administrator will say we are going to use the network 10.1.1.0/255.255.255.0 as a class C network for Cassandra servers. Given our own IP address we can know where the others will be. 

In general you can argue the merits of each provider. The next logical question is why is the configuration so obtuse and plugable if only one implementation exists?

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