[jira] [Comment Edited] (CASSANDRA-14361) Allow SimpleSeedProvider to resolve multiple IPs per DNS name

2018-04-04 Thread Ben Bromhead (JIRA)

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

Ben Bromhead edited comment on CASSANDRA-14361 at 4/4/18 4:30 PM:
--

I would argue that you need to be intentional about your DNS records, but I'm 
willing to concede that it moves config further away from the system which can 
hide the reason for behavior.

Would it be worth adding some info/debug level logging around what IPs got 
resolved for each time getSeeds() gets called?

At least that way the behavior of what gets looked up is observable and the 
answer to any potential WTFs is in the logs. 


was (Author: benbromhead):
I would argue you need to be intentional about your DNS records, but I'm 
willing to concede that it moves config further away from the system which can 
hide the reason for behavior.

Would it be worth adding some info/debug level logging around what IPs got 
resolved for each time getSeeds() gets called?

At least that way the behavior of what gets looked up is observable and the 
answer to any potential WTFs is in the logs. 

> Allow SimpleSeedProvider to resolve multiple IPs per DNS name
> -
>
> Key: CASSANDRA-14361
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14361
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: Ben Bromhead
>Assignee: Ben Bromhead
>Priority: Minor
> Fix For: 4.0
>
>
> Currently SimpleSeedProvider can accept a comma separated string of IPs or 
> hostnames as the set of Cassandra seeds. hostnames are resolved via 
> InetAddress.getByName, which will only return the first IP associated with an 
> A,  or CNAME record.
> By changing to InetAddress.getAllByName, existing behavior is preserved, but 
> now Cassandra can discover multiple IP address per record, allowing seed 
> discovery by DNS to be a little easier.
> Some examples of improved workflows with this change include: 
>  * specify the DNS name of a headless service in Kubernetes which will 
> resolve to all IP addresses of pods within that service. 
>  * seed discovery for multi-region clusters via AWS route53, AzureDNS etc
>  * Other common DNS service discovery mechanisms.
> The only behavior this is likely to impact would be where users are relying 
> on the fact that getByName only returns a single IP address.
> I can't imagine any scenario where that is a sane choice. Even when that 
> choice has been made, it only impacts the first startup of Cassandra and 
> would not be on any critical path.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Comment Edited] (CASSANDRA-14361) Allow SimpleSeedProvider to resolve multiple IPs per DNS name

2018-04-04 Thread Jon Haddad (JIRA)

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

Jon Haddad edited comment on CASSANDRA-14361 at 4/4/18 3:31 PM:


I agree with you, you could *explicitly* put 1000 seeds in there.  Would you 
expect there to be 1000 potential seeds in your gossip list by putting 1 thing 
in the seed list?  People don't even mostly know about this behavior.  I'm not 
sure it's optimal, and I'm not arguing against changing it, I'm just pointing 
it out and saying it's worth a discussion.  A point against it being, the new 
behavior might be a bit surprising (and maybe it doesn't actually change at all)


was (Author: rustyrazorblade):
I agree with you, you could *explicitly* put 1000 seeds in there.  Would you 
expect there to be 1000 potential seeds in your gossip list by putting 1 thing 
in the seed list?  People don't even mostly know about this behavior.  I'm not 
sure it's optimal, and I'm not arguing against changing it, I'm just pointing 
it out and saying it's worth a discussion.  A point against it being, the new 
behavior might be a bit surprising.

> Allow SimpleSeedProvider to resolve multiple IPs per DNS name
> -
>
> Key: CASSANDRA-14361
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14361
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: Ben Bromhead
>Assignee: Ben Bromhead
>Priority: Minor
> Fix For: 4.0
>
>
> Currently SimpleSeedProvider can accept a comma separated string of IPs or 
> hostnames as the set of Cassandra seeds. hostnames are resolved via 
> InetAddress.getByName, which will only return the first IP associated with an 
> A,  or CNAME record.
> By changing to InetAddress.getAllByName, existing behavior is preserved, but 
> now Cassandra can discover multiple IP address per record, allowing seed 
> discovery by DNS to be a little easier.
> Some examples of improved workflows with this change include: 
>  * specify the DNS name of a headless service in Kubernetes which will 
> resolve to all IP addresses of pods within that service. 
>  * seed discovery for multi-region clusters via AWS route53, AzureDNS etc
>  * Other common DNS service discovery mechanisms.
> The only behavior this is likely to impact would be where users are relying 
> on the fact that getByName only returns a single IP address.
> I can't imagine any scenario where that is a sane choice. Even when that 
> choice has been made, it only impacts the first startup of Cassandra and 
> would not be on any critical path.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Comment Edited] (CASSANDRA-14361) Allow SimpleSeedProvider to resolve multiple IPs per DNS name

2018-04-04 Thread Ben Bromhead (JIRA)

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

Ben Bromhead edited comment on CASSANDRA-14361 at 4/4/18 3:15 PM:
--

{quote}JVM property {{networkaddress.cache.ttl}} must be set otherwise 
operators will have to do a rolling restart of the cluster each time the seed 
list changes (unless default is not {{-1}} on their platforms).
{quote}
Caching behavior remains the same, given operators relying on hostnames in the 
seed list would need to be aware of this anyway, whether it looks up one IP or 
multiple. Also the JVM will only cache forever by default if a security manager 
is installed. If a security manager is not installed each specific JVM 
implementations can have a potentially different TTL, but a defined TTL 
nonetheless. See 
[https://docs.oracle.com/javase/8/docs/technotes/guides/net/properties.html].
{quote}This would also affect the third gossip round: 
[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/gms/Gossiper.java#L185]
{quote}
Ah, of course.

If you are already using hostnames in the seed list, the behavior would still 
be the same? Other than your list of seeds potentially containing seed IPs you 
might not expect, if you are returning multiple IPs per A record, but not 
relying on the behavior. Resulting in potentially more gossip rounds to hit the 
IP you used to expect?

I've marked this as a 4.0 patch, so I think a change in behavior would be fine. 
I've created another ticket 
https://issues.apache.org/jira/browse/CASSANDRA-14364 to document seed behavior 
with relation to the third gossip round and DNS (including caching) behavior.  


was (Author: benbromhead):
{quote}JVM property {{networkaddress.cache.ttl}} must be set otherwise 
operators will have to do a rolling restart of the cluster each time the seed 
list changes (unless default is not {{-1}} on their platforms).
{quote}
Caching behavior remains the same, given operators relying on hostnames in the 
seed list would need to be aware of this anyway, whether it looks up one IP or 
multiple. Also the JVM will only cache forever by default if a security manager 
is installed. If a security manager is not installed each specific JVM 
implementations can have a potentially different TTL, but a defined TTL 
nonetheless. See 
[https://docs.oracle.com/javase/8/docs/technotes/guides/net/properties.html].
{quote}This would also affect the third gossip round: 
[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/gms/Gossiper.java#L185]
{quote}
Ah, of course.

If you are already using hostnames in the seed list, the behavior would still 
be the same? Other than your list of seeds potentially containing seed IPs you 
might not expect, if you are returning multiple IPs per A record, but not 
relying on the behavior. Resulting in potentially more gossip rounds to hit the 
IP you used to expect?

I've marked this as a 4.0 patch, so I think a change in behavior would be fine. 
I've created another ticket 
https://issues.apache.org/jira/browse/CASSANDRA-14364 to document seed behavior 
with relation to the third gossip round and DNS (including caching) behavior. 

 

 

 

 

> Allow SimpleSeedProvider to resolve multiple IPs per DNS name
> -
>
> Key: CASSANDRA-14361
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14361
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: Ben Bromhead
>Assignee: Ben Bromhead
>Priority: Minor
> Fix For: 4.0
>
>
> Currently SimpleSeedProvider can accept a comma separated string of IPs or 
> hostnames as the set of Cassandra seeds. hostnames are resolved via 
> InetAddress.getByName, which will only return the first IP associated with an 
> A,  or CNAME record.
> By changing to InetAddress.getAllByName, existing behavior is preserved, but 
> now Cassandra can discover multiple IP address per record, allowing seed 
> discovery by DNS to be a little easier.
> Some examples of improved workflows with this change include: 
>  * specify the DNS name of a headless service in Kubernetes which will 
> resolve to all IP addresses of pods within that service. 
>  * seed discovery for multi-region clusters via AWS route53, AzureDNS etc
>  * Other common DNS service discovery mechanisms.
> The only behavior this is likely to impact would be where users are relying 
> on the fact that getByName only returns a single IP address.
> I can't imagine any scenario where that is a sane choice. Even when that 
> choice has been made, it only impacts the first startup of Cassandra and 
> would not be on any critical path.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Comment Edited] (CASSANDRA-14361) Allow SimpleSeedProvider to resolve multiple IPs per DNS name

2018-04-04 Thread Ben Bromhead (JIRA)

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

Ben Bromhead edited comment on CASSANDRA-14361 at 4/4/18 2:52 PM:
--

{quote}JVM property {{networkaddress.cache.ttl}} must be set otherwise 
operators will have to do a rolling restart of the cluster each time the seed 
list changes (unless default is not {{-1}} on their platforms).
{quote}
Caching behavior remains the same, given operators relying on hostnames in the 
seed list would need to be aware of this anyway, whether it looks up one IP or 
multiple. Also the JVM will only cache forever by default if a security manager 
is installed. If a security manager is not installed each specific JVM 
implementations can have a potentially different TTL, but a defined TTL 
nonetheless. See 
[https://docs.oracle.com/javase/8/docs/technotes/guides/net/properties.html].
{quote}This would also affect the third gossip round: 
[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/gms/Gossiper.java#L185]
{quote}
Ah, of course.

If you are already using hostnames in the seed list, the behavior would still 
be the same? Other than your list of seeds potentially containing seed IPs you 
might not expect, if you are returning multiple IPs per A record, but not 
relying on the behavior. Resulting in potentially more gossip rounds to hit the 
IP you used to expect?

I've marked this as a 4.0 patch, so I think a change in behavior would be fine. 
I've created another ticket 
https://issues.apache.org/jira/browse/CASSANDRA-14364 to document seed behavior 
with relation to the third gossip round and DNS (including caching) behavior. 

 

 

 

 


was (Author: benbromhead):
{quote}

JVM property networkaddress.cache.ttl must be set otherwise operators 
will have to do a rolling restart of the cluster each time the seed list 
changes (unless default is not -1 on their platforms).

{quote}

Caching behavior remains the same, given operators relying on hostnames in the 
seed list would need to be aware of this anyway, whether it looks up one IP or 
multiple. Also the JVM will only cache forever by default if a security manager 
is installed. If a security manager is not installed each specific JVM 
implementations can have a potentially different TTL, but a defined TTL 
nonetheless. See 
[https://docs.oracle.com/javase/8/docs/technotes/guides/net/properties.html].

{quote}

This would also affect the third gossip round: 
[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/gms/Gossiper.java#L185]

{quote}

Ah, of course.

If you are already using hostnames in the seed list, the behavior would still 
be the same? Other than your list of seeds potentially containing seed IPs you 
might not expect, if you are returning multiple IPs per A record, but not 
relying on the behavior. Resulting in potentially more gossip rounds to hit the 
IP you used to expect?

I've marked this as a 4.0 patch, so I think a change in behavior would be fine. 
I've created another ticket 
https://issues.apache.org/jira/browse/CASSANDRA-14364 to document seed behavior 
with relation to the third gossip round and DNS (including caching) behavior. 

 

 

 

 

> Allow SimpleSeedProvider to resolve multiple IPs per DNS name
> -
>
> Key: CASSANDRA-14361
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14361
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: Ben Bromhead
>Assignee: Ben Bromhead
>Priority: Minor
> Fix For: 4.0
>
>
> Currently SimpleSeedProvider can accept a comma separated string of IPs or 
> hostnames as the set of Cassandra seeds. hostnames are resolved via 
> InetAddress.getByName, which will only return the first IP associated with an 
> A,  or CNAME record.
> By changing to InetAddress.getAllByName, existing behavior is preserved, but 
> now Cassandra can discover multiple IP address per record, allowing seed 
> discovery by DNS to be a little easier.
> Some examples of improved workflows with this change include: 
>  * specify the DNS name of a headless service in Kubernetes which will 
> resolve to all IP addresses of pods within that service. 
>  * seed discovery for multi-region clusters via AWS route53, AzureDNS etc
>  * Other common DNS service discovery mechanisms.
> The only behavior this is likely to impact would be where users are relying 
> on the fact that getByName only returns a single IP address.
> I can't imagine any scenario where that is a sane choice. Even when that 
> choice has been made, it only impacts the first startup of Cassandra and 
> would not be on any critical path.



--
This message was sent by Atlassian