[jira] [Updated] (DRILL-7794) "Waiting for results" animation continues to churn after a failed query
[ https://issues.apache.org/jira/browse/DRILL-7794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Jaimes updated DRILL-7794: - Summary: "Waiting for results" animation continues to churn after a failed query (was: "Waiting for reuslts" animation continues to churn after a failed query) > "Waiting for results" animation continues to churn after a failed query > --- > > Key: DRILL-7794 > URL: https://issues.apache.org/jira/browse/DRILL-7794 > Project: Apache Drill > Issue Type: Bug > Components: Client - HTTP >Affects Versions: 1.18.0 >Reporter: Rafael Jaimes >Priority: Major > > Regression introduced into 1.18.0 RC0 > Reproduction: > Go to Query tab of the Drill web UI and type a bad query. > The next page says query failed. > Hit the back button and you will be greeted again with a "Query Submitted > Waiting for results" animation that will continue on forever. > The expected behavior is that you go back to the Query page (or Edit section > of the Profile page) so that you can fix your query, this is how 1.17.0 > worked. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (DRILL-7794) "Waiting for reuslts" animation continues to churn after a failed query
Rafael Jaimes created DRILL-7794: Summary: "Waiting for reuslts" animation continues to churn after a failed query Key: DRILL-7794 URL: https://issues.apache.org/jira/browse/DRILL-7794 Project: Apache Drill Issue Type: Bug Components: Client - HTTP Affects Versions: 1.18.0 Reporter: Rafael Jaimes Regression introduced into 1.18.0 RC0 Reproduction: Go to Query tab of the Drill web UI and type a bad query. The next page says query failed. Hit the back button and you will be greeted again with a "Query Submitted Waiting for results" animation that will continue on forever. The expected behavior is that you go back to the Query page (or Edit section of the Profile page) so that you can fix your query, this is how 1.17.0 worked. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (DRILL-7698) RDBMS Plugin Not Returning Results from Presto
[
https://issues.apache.org/jira/browse/DRILL-7698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17102077#comment-17102077
]
Rafael Jaimes edited comment on DRILL-7698 at 5/7/20, 11:35 PM:
Hi [~Paul.Rogers]. I appreciate you looking into the issue.
I didn't setup the Presto instance that I am querying. However, you might have
best luck with the image from prestosql. For all intents and purposes, it is
the canonical release with the most development and community backing it.
https://hub.docker.com/r/prestosql/presto
was (Author: rjaimes):
Hi ~[Paul.Rogers]. I appreciate you looking into the issue.
I didn't setup the Presto instance that I am querying. However, you might have
best luck with the image from prestosql. For all intents and purposes, it is
the canonical release with the most development and community backing it.
https://hub.docker.com/r/prestosql/presto
> RDBMS Plugin Not Returning Results from Presto
> --
>
> Key: DRILL-7698
> URL: https://issues.apache.org/jira/browse/DRILL-7698
> Project: Apache Drill
> Issue Type: Bug
> Components: Storage - JDBC
>Affects Versions: 1.18.0
>Reporter: Charles Givre
>Priority: Blocker
> Attachments: Screen Shot 2020-04-12 at 2.43.33 PM.png, Screen Shot
> 2020-04-12 at 2.56.10 PM.png, Screen Shot 2020-04-12 at 3.00.00 PM.png,
> Screen Shot 2020-04-12 at 3.01.37 PM.png
>
>
> Using the RDBMS storage plugin, Drill is unable to connect to Presto. More
> specifically, Drill seems to be connecting and sending queries to Presto, but
> then nothing happens with the query results.
> I verified the configuration using DBBeaver and was able to successfully
> query Presto. See screenshot below for config.
> !Screen Shot 2020-04-12 at 2.43.33 PM.png!
> Presto ships with a few sample databases as shown below, and these should be
> visible in Drill but are not.
> !Screen Shot 2020-04-12 at 2.56.10 PM.png!
> From the logs below, Presto is clearly receiving the queries from Drill, and
> the queries are returning results, but Drill seems to be dropping the
> results. While this may seem like a silly exercise, querying Presto from
> Drill, the fact that it didn't work makes me think we may have a bug in the
> JDBC Storage Plugin.
> !Screen Shot 2020-04-12 at 3.01.37 PM.png!
> !Screen Shot 2020-04-12 at 3.00.00 PM.png!
> h2. Steps to Reproduce
> 1. Download and start Docker container with Presto.
> 2. Download Presto JDBC driver (https://prestodb.io/download.html) and copy
> to Drill classpath.
> 3. Create RDBMS storage plugin instance using default config below:
> {code:java}
> {
> "type": "jdbc",
> "driver": "io.prestosql.jdbc.PrestoDriver",
> "url": "jdbc:presto://localhost:8080/tpch/sf1",
> "username": "user",
> "password": null,
> "caseInsensitiveTableNames": true,
> "sourceParameters": {},
> "enabled": true
> }
> {code}
> 4. Execute a SHOW DATABASES query and you will see that no presto related
> results are returned. Various queries to the INFORMATION SCHEMA reveal the
> same thing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (DRILL-7698) RDBMS Plugin Not Returning Results from Presto
[
https://issues.apache.org/jira/browse/DRILL-7698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17102077#comment-17102077
]
Rafael Jaimes edited comment on DRILL-7698 at 5/7/20, 11:35 PM:
Hi ~[Paul.Rogers]. I appreciate you looking into the issue.
I didn't setup the Presto instance that I am querying. However, you might have
best luck with the image from prestosql. For all intents and purposes, it is
the canonical release with the most development and community backing it.
https://hub.docker.com/r/prestosql/presto
was (Author: rjaimes):
Hi Paul Rogers. I appreciate you looking into the issue.
I didn't setup the Presto instance that I am querying. However, you might have
best luck with the image from prestosql. For all intents and purposes, it is
the canonical release with the most development and community backing it.
https://hub.docker.com/r/prestosql/presto
> RDBMS Plugin Not Returning Results from Presto
> --
>
> Key: DRILL-7698
> URL: https://issues.apache.org/jira/browse/DRILL-7698
> Project: Apache Drill
> Issue Type: Bug
> Components: Storage - JDBC
>Affects Versions: 1.18.0
>Reporter: Charles Givre
>Priority: Blocker
> Attachments: Screen Shot 2020-04-12 at 2.43.33 PM.png, Screen Shot
> 2020-04-12 at 2.56.10 PM.png, Screen Shot 2020-04-12 at 3.00.00 PM.png,
> Screen Shot 2020-04-12 at 3.01.37 PM.png
>
>
> Using the RDBMS storage plugin, Drill is unable to connect to Presto. More
> specifically, Drill seems to be connecting and sending queries to Presto, but
> then nothing happens with the query results.
> I verified the configuration using DBBeaver and was able to successfully
> query Presto. See screenshot below for config.
> !Screen Shot 2020-04-12 at 2.43.33 PM.png!
> Presto ships with a few sample databases as shown below, and these should be
> visible in Drill but are not.
> !Screen Shot 2020-04-12 at 2.56.10 PM.png!
> From the logs below, Presto is clearly receiving the queries from Drill, and
> the queries are returning results, but Drill seems to be dropping the
> results. While this may seem like a silly exercise, querying Presto from
> Drill, the fact that it didn't work makes me think we may have a bug in the
> JDBC Storage Plugin.
> !Screen Shot 2020-04-12 at 3.01.37 PM.png!
> !Screen Shot 2020-04-12 at 3.00.00 PM.png!
> h2. Steps to Reproduce
> 1. Download and start Docker container with Presto.
> 2. Download Presto JDBC driver (https://prestodb.io/download.html) and copy
> to Drill classpath.
> 3. Create RDBMS storage plugin instance using default config below:
> {code:java}
> {
> "type": "jdbc",
> "driver": "io.prestosql.jdbc.PrestoDriver",
> "url": "jdbc:presto://localhost:8080/tpch/sf1",
> "username": "user",
> "password": null,
> "caseInsensitiveTableNames": true,
> "sourceParameters": {},
> "enabled": true
> }
> {code}
> 4. Execute a SHOW DATABASES query and you will see that no presto related
> results are returned. Various queries to the INFORMATION SCHEMA reveal the
> same thing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (DRILL-7698) RDBMS Plugin Not Returning Results from Presto
[
https://issues.apache.org/jira/browse/DRILL-7698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17102077#comment-17102077
]
Rafael Jaimes commented on DRILL-7698:
--
Hi Paul Rogers. I appreciate you looking into the issue.
I didn't setup the Presto instance that I am querying. However, you might have
best luck with the image from prestosql. For all intents and purposes, it is
the canonical release with the most development and community backing it.
https://hub.docker.com/r/prestosql/presto
> RDBMS Plugin Not Returning Results from Presto
> --
>
> Key: DRILL-7698
> URL: https://issues.apache.org/jira/browse/DRILL-7698
> Project: Apache Drill
> Issue Type: Bug
> Components: Storage - JDBC
>Affects Versions: 1.18.0
>Reporter: Charles Givre
>Priority: Blocker
> Attachments: Screen Shot 2020-04-12 at 2.43.33 PM.png, Screen Shot
> 2020-04-12 at 2.56.10 PM.png, Screen Shot 2020-04-12 at 3.00.00 PM.png,
> Screen Shot 2020-04-12 at 3.01.37 PM.png
>
>
> Using the RDBMS storage plugin, Drill is unable to connect to Presto. More
> specifically, Drill seems to be connecting and sending queries to Presto, but
> then nothing happens with the query results.
> I verified the configuration using DBBeaver and was able to successfully
> query Presto. See screenshot below for config.
> !Screen Shot 2020-04-12 at 2.43.33 PM.png!
> Presto ships with a few sample databases as shown below, and these should be
> visible in Drill but are not.
> !Screen Shot 2020-04-12 at 2.56.10 PM.png!
> From the logs below, Presto is clearly receiving the queries from Drill, and
> the queries are returning results, but Drill seems to be dropping the
> results. While this may seem like a silly exercise, querying Presto from
> Drill, the fact that it didn't work makes me think we may have a bug in the
> JDBC Storage Plugin.
> !Screen Shot 2020-04-12 at 3.01.37 PM.png!
> !Screen Shot 2020-04-12 at 3.00.00 PM.png!
> h2. Steps to Reproduce
> 1. Download and start Docker container with Presto.
> 2. Download Presto JDBC driver (https://prestodb.io/download.html) and copy
> to Drill classpath.
> 3. Create RDBMS storage plugin instance using default config below:
> {code:java}
> {
> "type": "jdbc",
> "driver": "io.prestosql.jdbc.PrestoDriver",
> "url": "jdbc:presto://localhost:8080/tpch/sf1",
> "username": "user",
> "password": null,
> "caseInsensitiveTableNames": true,
> "sourceParameters": {},
> "enabled": true
> }
> {code}
> 4. Execute a SHOW DATABASES query and you will see that no presto related
> results are returned. Various queries to the INFORMATION SCHEMA reveal the
> same thing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (DRILL-7698) RDBMS Plugin Not Returning Results from Presto
[
https://issues.apache.org/jira/browse/DRILL-7698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17097627#comment-17097627
]
Rafael Jaimes commented on DRILL-7698:
--
Revelation today...
I successfully queried PrestoSQL using Drill 1.17 stable. It appears somewhere
along the lines that the JDBC generic adapter, as you suggested, developed a
bug along the 1.18 branch.
I was using a development 1.18 branch for testing but didn't think to try the
Presto query on a separate 1.17 instance. Sure enough, it works.
> RDBMS Plugin Not Returning Results from Presto
> --
>
> Key: DRILL-7698
> URL: https://issues.apache.org/jira/browse/DRILL-7698
> Project: Apache Drill
> Issue Type: Bug
> Components: Storage - JDBC
>Affects Versions: 1.18.0
>Reporter: Charles Givre
>Priority: Major
> Attachments: Screen Shot 2020-04-12 at 2.43.33 PM.png, Screen Shot
> 2020-04-12 at 2.56.10 PM.png, Screen Shot 2020-04-12 at 3.00.00 PM.png,
> Screen Shot 2020-04-12 at 3.01.37 PM.png
>
>
> Using the RDBMS storage plugin, Drill is unable to connect to Presto. More
> specifically, Drill seems to be connecting and sending queries to Presto, but
> then nothing happens with the query results.
> I verified the configuration using DBBeaver and was able to successfully
> query Presto. See screenshot below for config.
> !Screen Shot 2020-04-12 at 2.43.33 PM.png!
> Presto ships with a few sample databases as shown below, and these should be
> visible in Drill but are not.
> !Screen Shot 2020-04-12 at 2.56.10 PM.png!
> From the logs below, Presto is clearly receiving the queries from Drill, and
> the queries are returning results, but Drill seems to be dropping the
> results. While this may seem like a silly exercise, querying Presto from
> Drill, the fact that it didn't work makes me think we may have a bug in the
> JDBC Storage Plugin.
> !Screen Shot 2020-04-12 at 3.01.37 PM.png!
> !Screen Shot 2020-04-12 at 3.00.00 PM.png!
> h2. Steps to Reproduce
> 1. Download and start Docker container with Presto.
> 2. Download Presto JDBC driver (https://prestodb.io/download.html) and copy
> to Drill classpath.
> 3. Create RDBMS storage plugin instance using default config below:
> {code:java}
> {
> "type": "jdbc",
> "driver": "io.prestosql.jdbc.PrestoDriver",
> "url": "jdbc:presto://localhost:8080/tpch/sf1",
> "username": "user",
> "password": null,
> "caseInsensitiveTableNames": true,
> "sourceParameters": {},
> "enabled": true
> }
> {code}
> 4. Execute a SHOW DATABASES query and you will see that no presto related
> results are returned. Various queries to the INFORMATION SCHEMA reveal the
> same thing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (DRILL-7698) RDBMS Plugin Not Returning Results from Presto
[
https://issues.apache.org/jira/browse/DRILL-7698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17091674#comment-17091674
]
Rafael Jaimes commented on DRILL-7698:
--
I can confirm these results with a deployed Presto instance. The queries are
showing up in the Presto logs and, from what I can tell, they are executing
without error.
Drill results in the following error using the Drill web interface to execute a
query (presto3 is the name of my storage plugin):
```
UserRemoteException : VALIDATION ERROR: From line 1, column 15 to
line 1, column 21: Object 'presto3' not found
org.apache.drill.common.exceptions.UserRemoteException: VALIDATION ERROR: From
line 1, column 15 to line 1, column 21: Object 'presto3' not found
[Error Id: f900b07e-c5bd-4b14-9606-54c85ac8f8a7 ]
```
> RDBMS Plugin Not Returning Results from Presto
> --
>
> Key: DRILL-7698
> URL: https://issues.apache.org/jira/browse/DRILL-7698
> Project: Apache Drill
> Issue Type: Bug
> Components: Storage - JDBC
>Affects Versions: 1.18.0
>Reporter: Charles Givre
>Priority: Major
> Attachments: Screen Shot 2020-04-12 at 2.43.33 PM.png, Screen Shot
> 2020-04-12 at 2.56.10 PM.png, Screen Shot 2020-04-12 at 3.00.00 PM.png,
> Screen Shot 2020-04-12 at 3.01.37 PM.png
>
>
> Using the RDBMS storage plugin, Drill is unable to connect to Presto. More
> specifically, Drill seems to be connecting and sending queries to Presto, but
> then nothing happens with the query results.
> I verified the configuration using DBBeaver and was able to successfully
> query Presto. See screenshot below for config.
> !Screen Shot 2020-04-12 at 2.43.33 PM.png!
> Presto ships with a few sample databases as shown below, and these should be
> visible in Drill but are not.
> !Screen Shot 2020-04-12 at 2.56.10 PM.png!
> From the logs below, Presto is clearly receiving the queries from Drill, and
> the queries are returning results, but Drill seems to be dropping the
> results. While this may seem like a silly exercise, querying Presto from
> Drill, the fact that it didn't work makes me think we may have a bug in the
> JDBC Storage Plugin.
> !Screen Shot 2020-04-12 at 3.01.37 PM.png!
> !Screen Shot 2020-04-12 at 3.00.00 PM.png!
> h2. Steps to Reproduce
> 1. Download and start Docker container with Presto.
> 2. Download Presto JDBC driver (https://prestodb.io/download.html) and copy
> to Drill classpath.
> 3. Create RDBMS storage plugin instance using default config below:
> {code:java}
> {
> "type": "jdbc",
> "driver": "io.prestosql.jdbc.PrestoDriver",
> "url": "jdbc:presto://localhost:8080/tpch/sf1",
> "username": "user",
> "password": null,
> "caseInsensitiveTableNames": true,
> "sourceParameters": {},
> "enabled": true
> }
> {code}
> 4. Execute a SHOW DATABASES query and you will see that no presto related
> results are returned. Various queries to the INFORMATION SCHEMA reveal the
> same thing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (DRILL-7699) old javax.validation dependency causes Presto client failure
[ https://issues.apache.org/jira/browse/DRILL-7699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Jaimes updated DRILL-7699: - Summary: old javax.validation dependency causes Presto client failure (was: javax.validation dependency is old) > old javax.validation dependency causes Presto client failure > > > Key: DRILL-7699 > URL: https://issues.apache.org/jira/browse/DRILL-7699 > Project: Apache Drill > Issue Type: Bug > Components: Client - JDBC >Affects Versions: 1.17.0 >Reporter: Rafael Jaimes >Priority: Minor > Fix For: Future > > > The dependency for the validation-api being called in the pom of exec/jdbc is > quite old and causes a failure in Presto when loading the JDBC driver. Other > programs might have trouble loading the JDBC driver. Changing the version to > 2.0.1-Final fixes the problem. It might also be feasible to just not specify > the version at all. > > javax.validation > validation-api > 1.1.0.Final > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (DRILL-7699) javax.validation dependency is old
Rafael Jaimes created DRILL-7699: Summary: javax.validation dependency is old Key: DRILL-7699 URL: https://issues.apache.org/jira/browse/DRILL-7699 Project: Apache Drill Issue Type: Bug Components: Client - JDBC Affects Versions: 1.17.0 Reporter: Rafael Jaimes Fix For: Future The dependency for the validation-api being called in the pom of exec/jdbc is quite old and causes a failure in Presto when loading the JDBC driver. Other programs might have trouble loading the JDBC driver. Changing the version to 2.0.1-Final fixes the problem. It might also be feasible to just not specify the version at all. javax.validation validation-api 1.1.0.Final -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (DRILL-7234) Allow support for using Drill WebU through a Reverse Proxy server
[
https://issues.apache.org/jira/browse/DRILL-7234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17081933#comment-17081933
]
Rafael Jaimes commented on DRILL-7234:
--
This is critical for some enterprise deployments. I've seen another project fix
the issue by having two env vars, one for requests and one for routes.
> Allow support for using Drill WebU through a Reverse Proxy server
> -
>
> Key: DRILL-7234
> URL: https://issues.apache.org/jira/browse/DRILL-7234
> Project: Apache Drill
> Issue Type: Improvement
> Components: Web Server
>Affects Versions: 1.16.0
>Reporter: Kunal Khatua
>Priority: Critical
> Labels: reverse-proxy
>
> Currently, Drill's WebUI has a lot of links and references going through the
> root of the URL.
> i.e. to access the profiles listing or submitting a query, we'd need to
> access the following URL format:
> {code}
> http://localhost:8047/profiles
> http://localhost:8047/query
> {code}
> With a reverse proxy, these pages need to be accessed by:
> {code}
> http://localhost:8047/x/y/z/profiles
> http://localhost:8047/x/y/z/query
> {code}
> However, the links within these page do not include the *{{x/y/z/}}* part, as
> a result of which the visiting those links will fail.
> The WebServer should implement a mechanism that can detect this additional
> layer and modify the links within the webpage accordingly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (DRILL-7234) Allow support for using Drill WebU through a Reverse Proxy server
[
https://issues.apache.org/jira/browse/DRILL-7234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17081933#comment-17081933
]
Rafael Jaimes edited comment on DRILL-7234 at 4/12/20, 11:11 PM:
-
This is critical for some enterprise deployments. I've seen another project fix
the issue by having two env vars that let you set the pathname prefix: one for
requests and one for routes.
was (Author: rjaimes):
This is critical for some enterprise deployments. I've seen another project fix
the issue by having two env vars, one for requests and one for routes.
> Allow support for using Drill WebU through a Reverse Proxy server
> -
>
> Key: DRILL-7234
> URL: https://issues.apache.org/jira/browse/DRILL-7234
> Project: Apache Drill
> Issue Type: Improvement
> Components: Web Server
>Affects Versions: 1.16.0
>Reporter: Kunal Khatua
>Priority: Critical
> Labels: reverse-proxy
>
> Currently, Drill's WebUI has a lot of links and references going through the
> root of the URL.
> i.e. to access the profiles listing or submitting a query, we'd need to
> access the following URL format:
> {code}
> http://localhost:8047/profiles
> http://localhost:8047/query
> {code}
> With a reverse proxy, these pages need to be accessed by:
> {code}
> http://localhost:8047/x/y/z/profiles
> http://localhost:8047/x/y/z/query
> {code}
> However, the links within these page do not include the *{{x/y/z/}}* part, as
> a result of which the visiting those links will fail.
> The WebServer should implement a mechanism that can detect this additional
> layer and modify the links within the webpage accordingly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (DRILL-7695) java JDK check
Rafael Jaimes created DRILL-7695:
Summary: java JDK check
Key: DRILL-7695
URL: https://issues.apache.org/jira/browse/DRILL-7695
Project: Apache Drill
Issue Type: Improvement
Components: Documentation
Reporter: Rafael Jaimes
The 10 minute tutorial suggests 'java -version' to check if a JDK is installed.
I believe it only shows the JRE. Because OpenJDK includes a JRE variant only,
it can sometimes be confusing as to whether someone who's installed an openjdk
package actually has the full JDK or just a JRE.
I believe the better command is: '{{javac -version}}' to check for the
existence of a java compiler, which should be better represented of having a
JDK installed.
On my Red Hat 7 system, I installed java-1.8.0-openjdk-devel.x86_64
>>> javac -version
javac 1.8.0_242
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (DRILL-7695) java (JDK) check
[
https://issues.apache.org/jira/browse/DRILL-7695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rafael Jaimes updated DRILL-7695:
-
Summary: java (JDK) check (was: java JDK check)
> java (JDK) check
>
>
> Key: DRILL-7695
> URL: https://issues.apache.org/jira/browse/DRILL-7695
> Project: Apache Drill
> Issue Type: Improvement
> Components: Documentation
>Reporter: Rafael Jaimes
>Priority: Trivial
>
> The 10 minute tutorial suggests 'java -version' to check if a JDK is
> installed. I believe it only shows the JRE. Because OpenJDK includes a JRE
> variant only, it can sometimes be confusing as to whether someone who's
> installed an openjdk package actually has the full JDK or just a JRE.
> I believe the better command is: '{{javac -version}}' to check for the
> existence of a java compiler, which should be better represented of having a
> JDK installed.
> On my Red Hat 7 system, I installed java-1.8.0-openjdk-devel.x86_64
>
> >>> javac -version
> javac 1.8.0_242
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (DRILL-7563) Docker & Kubernetes Drill server container
[
https://issues.apache.org/jira/browse/DRILL-7563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17066022#comment-17066022
]
Rafael Jaimes commented on DRILL-7563:
--
Dobes - thanks. I am looking through your work now. Have you tested this with
scaling up drillbit pods?
> Docker & Kubernetes Drill server container
> --
>
> Key: DRILL-7563
> URL: https://issues.apache.org/jira/browse/DRILL-7563
> Project: Apache Drill
> Issue Type: Improvement
>Affects Versions: 1.17.0
>Reporter: Paul Rogers
>Assignee: Paul Rogers
>Priority: Major
>
> Drill provides two Docker containers:
> * [Build Drill from
> sources|https://github.com/apache/drill/blob/master/Dockerfile]
> * [Run Drill in interactive embedded
> mode|https://github.com/apache/drill/blob/master/distribution/Dockerfile]
> User feedback suggests that these are not quite the right solutions to run
> Drill in a K8s (or OpenShift) cluster. In addition, we need a container to
> run a Drill server. This ticket summarizes the tasks involved.
> h4. Container Image
> The container image should:
> * Start with the OpenJDK base image with minimal extra packages.
> * Download and install an official Drill release.
> We may then want to provide two derived images:
> The Drillbit image which:
> * Configures Drill for production and as needed in the following steps.
> * Provides entry points for the Drillbit and for Sqlline
> * Exposes Drill's four ports
> * Accept as parameters things like the ZK host IP(s).
> The Sqlline image, meant to be run in interactive mode (like the current
> embedded image) and which:
> * Accept as parameters the ZK host IP(s).
> Both should be published to the official Drill DockerHub account:
> https://hub.docker.com/r/apache/drill
> h4. Runtime Environment
> Drill has very few dependencies, but it must have a running ZK.
> * Start a [ZK container|https://hub.docker.com/_/zookeeper/].
> * A place to store logs, which can be in the container by default, stored on
> the host file system via a volume mount.
> * Access to a data source, which can be configured via a storage plugin
> stored in ZK.
> * Ensure graceful shutdown integration with the Docker shutdown mechanism.
> h4. Running Drill in Docker
> Users must run at least one Drillbit, and may run more. Users may want to run
> Sqlline.
> * The Drillbit container requires, at a minimum, the IP address of the ZK
> instance(s).
> * The Sqlline container requires only the ZK instances, from which it can
> find the Drillbit.
> Uses will want to customize some parts of Drill: at least memory, perhaps any
> of the other options. Provide a way to pass this information into the
> container to avoid the need to rebuild the container to change configuration.
> h4. Running Drill in K8s
> The containers should be usable in "plain" Docker. Today, however, many
> people use K8s to orchestrate Docker. Thus, the Drillbit (but probably not
> the Sqlline) container should be designed to work with K8s. An example set of
> K8s YAML files should illustrate:
> * Create a host-mount file system to capture Drill logs and query profiles.
> * Optionally write Drill logs to stdout, to be captured by {{fluentd}} or
> similar tools.
> * Pass Drill configuration (both HOCON and envrironment) as config maps.
> * Pass ZK as an environment variable (the value of which would, one presumes,
> come from some kind of service discovery system.)
> The result is that the user should be able to manually tinker with the YAML
> files, then use {{kubeadm}} to launch, monitor and stop Drill. The user sets
> cluster size manually by launching the desired number of Drill pods.
> h4. Helm Chart for Drill
> The next step is to wrap the YAML files in a Helm chart, with parameters
> exposed for the config options noted above.
> h4. Drill Operator for K8s
>
> Full K8s integration will require an operator to manage the Drill cluster.
> K8s operators are often written in Go, though doing so is not necessary.
> Drill already includes Drill-on-YARN which is, essential a "YARN operator."
> Repurpose this code to work with K8s as the target cluster manager rather
> than YARN. Reuse the same operations from DoY: configure, start, resize and
> stop a cluster.
> h4. Security
> The above steps provide an "MVP": minimum viable project - it will run Drill
> with standard options in the various environments. Users who chose to run
> Drill in production will likely require additional security settings. Enable
> SSL? Control ingress? We need to understand what is needed, what Drill
> offers, and how to enable Drill's security features in a containerized
> environment.
> h4. Production Deployments
> With Docker and K8s the old maxim "the devil is in the details" is true in
> spades. There are dozens of ways that Drill can
