accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-1585) Provide option for FQDN/verbatim data from config files of servers to be stored in ZooKeeper rather than resolved IP
Date Wed, 23 Oct 2013 02:43:42 GMT


ASF subversion and git services commented on ACCUMULO-1585:

Commit 839d689f67a53e1b34e01d69a989232d289c8bf8 in branch refs/heads/master from [~keith_turner]
[;h=839d689 ]

ACCUMULO-1585 add guava to

> Provide option for FQDN/verbatim data from config files of servers to be stored in ZooKeeper
rather than resolved IP
> --------------------------------------------------------------------------------------------------------------------
>                 Key: ACCUMULO-1585
>                 URL:
>             Project: Accumulo
>          Issue Type: Improvement
>          Components: tserver
>         Environment: All
>            Reporter: Basit Mustafa
>            Assignee: Eric Newton
>            Priority: Minor
>             Fix For: 1.6.0
>   Original Estimate: 12h
>  Remaining Estimate: 12h
> There are some situations (esp in virtualized/cloud environments) where "hardwiring"
the IP into ZooKeeper can create reachability issues and an FQDN (or, better/also, the verbatim
string/line from the concerned config file) would fix this problem. 
> For example, hostname specified in configuration files resolves to
an Amazon EC2 *internal* IP of (internal on virtualized network). Externally (e.g.
from your dev machine, your offsite/non-VPN/non-VPCed data center, other client machines on
different networks/clouds), will resolve to a public IP (e.g. Amazon Elastic
IP, etc) of something more routeable, like 
> Accumulo currently stores in ZooKeeper based on this resolution, but, if you
try to connect to Accumulo from outside these machines/machines in the same cloud/vitualized
network/non routeable network, and the same FQDN ( resolves to the public
address now (, you will not be able to connect, because the Accumulo client will
have pulled the resolved, and from here, unreachable, IP of
> Using the FQDN (or in some other way allowing for client-side name resolution/address
translation, although this seems kludgy) would fix this issue in a relatively standard way.
Ideally, this would not incur a performance issue beyond the first resolution assuming the
TCP/IP stack is doing its job and caching stuff effectively (I assume). 
> This doesn't really hurt/break things if you give an option in some config, and, really,
taking the literal from the file allows you to use whatever you want, the ultimate in flexibility.

> See discussion
for more details and others having the same issue. 
> I will look into creating a patch for this as soon as I have some time to find/look at
relevant code portions (I need to find where accumulo is making these writes to ZK and if
the read FQDNs would need any resolution/their use further down the line expects strictly
IP or is in host or IP safe API calls, etc). Any suggestions on where I can begin this are
always appreciated. Otherwise, I'll try and submit a patch when I can. 
> Figure I'd open this issue to at least provide a discussion on what more experienced
Accumulo devs and users think and what a solution based on the style/patterns accepted for
Accumulo development/configuration are. I can read the guidelines myself, of course, and will,
but someone suggested opening an issue, so I am...

This message was sent by Atlassian JIRA

View raw message