[jira] [Comment Edited] (DRILL-4543) Advertise Drill-bit ports, status, capabilities in ZooKeeper

["John Omernik (JIRA)" <ji...@apache.org>]

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

John Omernik edited comment on DRILL-4543 at 3/27/16 1:23 PM:
--------------------------------------------------------------


I think we should move the ports into ENV Variables as those settings are per bit.  This would allow Yarn or Mesos to set the ports explicitly on start.  If those settings are NOT in the drill-env (or ENV collection is more accurate), then we should default to values in drill-override at a cluster level. The Drill bit would still be registering it' ports with Zookeeper, it would just get the ports from drill-override.  If they are not explicitly set in drill-override or in the ENV variables, then you use the defaults.  I think this would give us the most granularity with user installations on Yarn and Mesos while not being a breaking change for any other clusters that are already working. 

The only other thing to this that I think needs to be added is making the port represented in the webui  as "Data Port" explicit.  What I mean by this, is in my testing, I found that the port for the web-ui I could set with "drill.exec.http.port".  The port in the web ui labeled as "User Port" was controlled by "drill.exec.rpc.user.server.port", the port in the web ui as "Control Port" was controlled by the setting "drill.exec.rpc.bit.server.port"  However, the port in the UI "Data Port" was not set able in the drill-override (or I didn't know what the setting was) instead it's controlled by "drill.exec.rpc.bit.server.port" + 1. For both Mesos and Yarn, the ability to set this explicitly would be preferred, as the ports may not be allocated to a executor (Mesos terms) in order, thus we need the ability to have all 4 ports be random and explicitly configurable.   





was (Author: mandoskippy):
First point: 

I think we should move the ports into ENV Variables as those settings are per bit.  This would allow Yarn or Mesos to set the ports explicitly on start.  If those settings are NOT in the drill-env (or ENV collection is more accurate), then we should default to values in drill-override at a cluster level. The Drill bit would still be registering it' ports with Zookeeper, it would just get the ports from drill-override.  If they are not explicitly set in drill-override or in the ENV variables, then you use the defaults.  I think this would give us the most granularity with user installations on Yarn and Mesos while not being a breaking change for any other clusters that are already working. 

The only other thing to this that I think needs to be added is making the port represented in the webui  as "Data Port" explicit.  What I mean by this, is in my testing, I found that the port for the web-ui I could set with "drill.exec.http.port".  The port in the web ui labeled as "User Port" was controlled by "drill.exec.rpc.user.server.port", the port in the web ui as "Control Port" was controlled by the setting "drill.exec.rpc.bit.server.port"  However, the port in the UI "Data Port" was not set able in the drill-override (or I didn't know what the setting was) instead it's controlled by "drill.exec.rpc.bit.server.port" + 1. For both Mesos and Yarn, the ability to set this explicitly would be preferred, as the ports may not be allocated to a executor (Mesos terms) in order, thus we need the ability to have all 4 ports be random and explicitly configurable.   




> Advertise Drill-bit ports, status, capabilities in ZooKeeper
> ------------------------------------------------------------
>
>                 Key: DRILL-4543
>                 URL: https://issues.apache.org/jira/browse/DRILL-4543
>             Project: Apache Drill
>          Issue Type: Improvement
>          Components:  Server
>            Reporter: Paul Rogers
>             Fix For: 2.0.0
>
>
> Today Drill uses ZooKeeper (ZK) to advertise the existence of a Drill-bit, providing just the host name/IP Address of the Drill-bit. All other information (ports, status, capabilities) are assumed to be the same across all Drill-bits in the cluster as specified in the Drill config file.
> Moving forward, as Drill becomes more sophisticated, Drill should advertise the specifics of each Drill-bit so that one Drill bit can differ from another.
> For example, when running on YARN, we need a way for Drill to gracefully shut down. Advertising a status of Ready or Unavailable will help. Ready is the normal state. Unavailable means the Drill-bit will finish in-flight queries, but won't accept new ones. (The actual status is a separate enhancement.)
> In a YARN cluster, Drill should take advantage of machines with more memory, but live with machines with less. (Perhaps some are newer, some are older or more heavily loaded.) Drill should use ZK to identify its available memory and CPUs so that the planner can use them. (Use of the info is a separate enhancement.)
> There may be times when two drill bits run on a single machine. If so, they must use separate ports. So, each Drill-bit should advertise its ports in ZK.
> For backward compatibility, the information is optional; if not present, the receiver should assume the information defaults to that in the config file.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)