[ 
https://issues.apache.org/jira/browse/KAFKA-1092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roger Hoover updated KAFKA-1092:
--------------------------------

    Attachment: KAFKA-1092.patch

> Add server config parameter to separate bind address and ZK hostname
> --------------------------------------------------------------------
>
>                 Key: KAFKA-1092
>                 URL: https://issues.apache.org/jira/browse/KAFKA-1092
>             Project: Kafka
>          Issue Type: New Feature
>          Components: config
>    Affects Versions: 0.8.1
>            Reporter: Roger Hoover
>         Attachments: KAFKA-1092.patch
>
>
> Currently, in server.properties, you can configure host.name which gets used 
> for two purposes: 1) to bind the socket 2) to publish the broker details to 
> ZK for clients to use.
> There are times when these two settings need to be different.  Here's an 
> example.  I want to setup Kafka brokers on OpenStack virtual machines in a 
> private cloud but I need producers to connect from elsewhere on the internal 
> corporate network.  With OpenStack, the virtual machines are only exposed to 
> DHCP addresses (typically RFC 1918 private addresses).  You can assign 
> "floating ips" to a virtual machine but it's forwarded using Network Address 
> Translation and not exposed directly to the VM.  Also, there's typically no 
> DNS to provide hostname lookup.  Hosts have names like "fubar.novalocal" that 
> are not externally routable.
> Here's what I want.  I want the broker to bind to the VM's private network IP 
> but I want it to publish it's floating IP to ZooKeeper so that producers can 
> publish to it.
> I propose a new optional parameter, "listen", which would allow you to 
> specify the socket address to listen on.  If not set, the parameter would 
> default to host.name, which is the current behavior.
> #Publish the externally routable IP in ZK
> host.name = <floating ip>
> #Accept connections from any interface the VM knows about
> listen = *



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Reply via email to