Why is a wildcard certificate a problem? They are quite common. One just needs 
all of the Drillbits to share a common domain for the wildcard to be easy and 
thus avoid having to list individual hosts.

Are you saying that you can't use hostnames and must use IPs?

In case I'm not clear, here's an example of what I'm saying.

this is good with wildcards: 
drill1.mydrill.corp.com<http://drill1.mydrill.corp.com>, 
drill2.mydrill.corp.com<http://drill2.mydrill.corp.com>, 
drill3.mydrill.corp.com<http://drill3.mydrill.corp.com>, 
drill4.mydrill.corp.com<http://drill4.mydrill.corp.com>,
this is bad with wildcards: drill1, drill2, drill3, drill4


Keys
_______________________________
Keys Botzum
MapR Technologies



On Jun 22, 2017, at 8:24 PM, John Omernik 
<[email protected]<mailto:[email protected]>> wrote:

Would there be interest in finding a way to globalize this? This is
challenging for me and others that may run drill with multi Tennant
orchestrators.  In my particular setup, each node running drill gets added
to an a record automatically giving me HA and distribution of Rest API
queries.  It also allows me to have a single certificate for my cluster
rather than managing certificates on a individual basis.   I set things up
to connect via IP but then I had certificate mismatch warnings. My goal is
to find a way to connect to the rest API , while maintaining a session to
single node, with out sacrificing HA and balancing and with compromising
ssl security.   I know it's a tall order, but if there I ideas outside of a
global state management I am all ears.

Note some ideas I've also considered:

1.  using a load balancer that would allow me to pin connections.  Not
ideal because it's another service to manage but it would work.

2. There may be a way to hack things with a wild card cert but it's seems
complicated and fragile.

On Jun 22, 2017 5:47 PM, "Sorabh Hamirwasia" 
<[email protected]<mailto:[email protected]>> wrote:

Hi John,
As Paul mentioned session ID's are not global. Each session is part of the
BitToUserConnection instance created for a connection between Drillbit and
client. Hence it's local to that Drillbit only and the lifetime of the
session is tied to lifetime of the connection. You can find the code here<
https://github.com/apache/drill/blob/master/exec/
java-exec/src/main/java/org/apache/drill/exec/rpc/user/
UserServer.java#L102>.

Thanks,
Sorabh

________________________________
From: Paul Rogers <[email protected]>
Sent: Thursday, June 22, 2017 2:19:50 PM
To: [email protected]
Subject: Re: Drill Session ID between Nodes

Hi John,

I do not believe that session IDs are global. Each Drillbit maintains its
own concept of sessions. A global session would require some centralized
registry of sessions, which Drill does not have.

Would be great if someone can confirm…

- Paul

On Jun 22, 2017, at 12:14 PM, John Omernik <[email protected]> wrote:

When I log onto a drill node, and get Session Id, if I connect to another
drill node in the cluster will the session id be valid?

I am guessing not, but want to validate.

My conumdrum, I have my Drill cluster running in such a way that the
connections to the nodes are load balanced via DNS. However, if I get a
DNS
IP while in session it appears to invalidate, and thus forces me to log
on...



Reply via email to