[jira] [Comment Edited] (IMPALA-13204) MySQL setup process in _setup_mysql_test_env is flaky
[ https://issues.apache.org/jira/browse/IMPALA-13204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17866553#comment-17866553 ] gaurav singh edited comment on IMPALA-13204 at 7/17/24 3:35 PM: We observed that the setting of mysqld had issues in different environments due to third party dependancies, permissions, docker etc. Hence we skip the mysql test if the env setup is failed due to the following reasons: 1. These tests require to add the docker to be added to sudoer's group. 2. Can't connect to local MySQL server. 3. File /var/run/mysqld/mysqld.sock not found. However, once the setup is completed and we do not see the expected results, then we mark the test as "failed". We use this command in our script: testdata/bin/setup-mysql-env.sh docker run --name mysql -e MYSQL_ROOT_PASSWORD=secret -d -p 3306:3306 mysql As long as we are skipping it, we are good. if the test fails after the setup is successful (due to other reason than the ones listed above), then its a test failure. was (Author: JIRAUSER302462): We observed that the setting of mysqld had issues in different environments due to third party dependancies, permissions, docker etc. Hence we skip the mysql test if the env setup is failed due to the following reasons: 1. These tests require to add the docker to be added to sudoer's group. 2. Can't connect to local MySQL server. 3. File /var/run/mysqld/mysqld.sock not found. However, once the setup is completed and we do not see the expected results, then we mark the test as "failed". > MySQL setup process in _setup_mysql_test_env is flaky > - > > Key: IMPALA-13204 > URL: https://issues.apache.org/jira/browse/IMPALA-13204 > Project: IMPALA > Issue Type: Bug >Affects Versions: Impala 4.5.0 >Reporter: Laszlo Gaal >Assignee: gaurav singh >Priority: Major > Labels: broken-build > > A failure during setup disables some test steps dynamically; however, this > generates a JUnitXml symptom file, marking the build unstable. This shows up > on the dashboard as a failure. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Commented] (IMPALA-13204) MySQL setup process in _setup_mysql_test_env is flaky
[ https://issues.apache.org/jira/browse/IMPALA-13204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17866553#comment-17866553 ] gaurav singh commented on IMPALA-13204: --- We observed that the setting of mysqld had issues in different environments due to third party dependancies, permissions, docker etc. Hence we skip the mysql test if the env setup is failed due to the following reasons: 1. These tests require to add the docker to be added to sudoer's group. 2. Can't connect to local MySQL server. 3. File /var/run/mysqld/mysqld.sock not found. However, once the setup is completed and we do not see the expected results, then we mark the test as "failed". > MySQL setup process in _setup_mysql_test_env is flaky > - > > Key: IMPALA-13204 > URL: https://issues.apache.org/jira/browse/IMPALA-13204 > Project: IMPALA > Issue Type: Bug >Affects Versions: Impala 4.5.0 >Reporter: Laszlo Gaal >Assignee: gaurav singh >Priority: Major > Labels: broken-build > > A failure during setup disables some test steps dynamically; however, this > generates a JUnitXml symptom file, marking the build unstable. This shows up > on the dashboard as a failure. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Work started] (IMPALA-13204) MySQL setup process in _setup_mysql_test_env is flaky
[ https://issues.apache.org/jira/browse/IMPALA-13204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on IMPALA-13204 started by gaurav singh. - > MySQL setup process in _setup_mysql_test_env is flaky > - > > Key: IMPALA-13204 > URL: https://issues.apache.org/jira/browse/IMPALA-13204 > Project: IMPALA > Issue Type: Bug >Affects Versions: Impala 4.5.0 >Reporter: Laszlo Gaal >Assignee: gaurav singh >Priority: Major > Labels: broken-build > > A failure during setup disables some test steps dynamically; however, this > generates a JUnitXml symptom file, marking the build unstable. This shows up > on the dashboard as a failure. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Resolved] (IMPALA-12559) Support x5c Parameter in JSON Web Keys (JWK)
[ https://issues.apache.org/jira/browse/IMPALA-12559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] gaurav singh resolved IMPALA-12559. --- Resolution: Fixed > Support x5c Parameter in JSON Web Keys (JWK) > > > Key: IMPALA-12559 > URL: https://issues.apache.org/jira/browse/IMPALA-12559 > Project: IMPALA > Issue Type: Bug > Components: be, Security >Reporter: Jason Fehr >Assignee: gaurav singh >Priority: Critical > Labels: JWT, jwt, security > > The ["x5u"|https://datatracker.ietf.org/doc/html/rfc7517#section-4.6], > ["x5c"|https://datatracker.ietf.org/doc/html/rfc7517#section-4.7], > ["x5t"|https://datatracker.ietf.org/doc/html/rfc7517#section-4.8], and > ["x5t#S256|https://datatracker.ietf.org/doc/html/rfc7517#section-4.9] > parameters in JWKs is not supported by Impala. Implement support for this > parameter using the available methods in the [Thalhammer/jwt-cpp > library|https://github.com/Thalhammer/jwt-cpp/blob/ce1f9df3a9f861d136d6f0c93a6f811c364d1d3d/example/jwks-verify.cpp]. > Note: If the "alg" property is specified and so is "x5u" or "x5c", then the > value of the "alg" property must match the algorithm on the certificate from > the "x5u" or "x5c" property. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Created] (IMPALA-13182) Support Uploading additional JARs to CDW Impala
gaurav singh created IMPALA-13182: - Summary: Support Uploading additional JARs to CDW Impala Key: IMPALA-13182 URL: https://issues.apache.org/jira/browse/IMPALA-13182 Project: IMPALA Issue Type: Improvement Components: Backend Reporter: gaurav singh Assignee: gaurav singh Support Uploading additional JARs to CDW Impala for use cases as below - Adding Snowflake jar to connect to snowflake catalog. This to support reading remote iceberg catalog tables, snowflake catalog in this case Adding jar to connect to custom on prem S3 storages -[https://cloudera.slack.com/archives/CC9DCQ3GD/p1712826317729039] Hive LLAP Supports this today - [https://docs.cloudera.com/data-warehouse/cloud/bi-tools/topics/dw-hive-upload-additional-jars.html] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-12559) Support x5c Parameter in JSON Web Keys (JWK)
[ https://issues.apache.org/jira/browse/IMPALA-12559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] gaurav singh updated IMPALA-12559: -- Summary: Support x5c Parameter in JSON Web Keys (JWK) (was: Support x5u/x5c/x5t Parameter in JSON Web Keys (JWK)) > Support x5c Parameter in JSON Web Keys (JWK) > > > Key: IMPALA-12559 > URL: https://issues.apache.org/jira/browse/IMPALA-12559 > Project: IMPALA > Issue Type: Bug > Components: be, Security >Reporter: Jason Fehr >Assignee: gaurav singh >Priority: Critical > Labels: JWT, jwt, security > > The ["x5u"|https://datatracker.ietf.org/doc/html/rfc7517#section-4.6], > ["x5c"|https://datatracker.ietf.org/doc/html/rfc7517#section-4.7], > ["x5t"|https://datatracker.ietf.org/doc/html/rfc7517#section-4.8], and > ["x5t#S256|https://datatracker.ietf.org/doc/html/rfc7517#section-4.9] > parameters in JWKs is not supported by Impala. Implement support for this > parameter using the available methods in the [Thalhammer/jwt-cpp > library|https://github.com/Thalhammer/jwt-cpp/blob/ce1f9df3a9f861d136d6f0c93a6f811c364d1d3d/example/jwks-verify.cpp]. > Note: If the "alg" property is specified and so is "x5u" or "x5c", then the > value of the "alg" property must match the algorithm on the certificate from > the "x5u" or "x5c" property. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Comment Edited] (IMPALA-12558) JSON Web Keys (JWK) Must Not Require the Optional alg Property
[
https://issues.apache.org/jira/browse/IMPALA-12558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17830533#comment-17830533
]
gaurav singh edited comment on IMPALA-12558 at 3/25/24 3:13 PM:
Impala requires the 'alg' value in the jwks.json stored on the impala cluster
(server side) in order to construct the {*}JWKPublicKey{*}.
{code:java}
{
"keys": [
{
"kty": "RSA",
"e": "AQAB",
"use": "sig",
"kid": "WK-ahKKYNs5PtFxMiPuMRhdjeEVlHpPkQRYs62-LjF4",
"alg": "RS256",
"n":
"2nyM8JEu45EcXjnDLfM_60cWQtwBmsmKeg-ZuMTcHHAKSOkV_Q39i2RAOnv8zs7TYH_meDvlYBgdQo9hYHlx4METd3XU4mMGYoZbhp66SyUcmvcRqBhSWGRMChUyMoG9meNZT9qgT1z-47Zn9STLRa3UMVCn_Wwmp8Sk81vtfwVLb7Vec6IlGYX-KSknWX19tUhfvok0q9CdEqf3DIsuGNue8o10rRFQ_VlGaX6FD28xZPyT0ZNYs5vivvJ7h6WQIdPaaN8VpbTqiOEk8BGmYVgaMhF4O5MbFZyUUvJPAMBdulZvtHPJOxhV45IgcmIGgHWBE2Ylk2QV_3gAD9MpxQ"
}
]
}{code}
If that field is missing(since its optional), then we would have to defer the
JWKPublicKey creation until we receive first valid request from the client
which will contain the alg field in the header (mandatory field). Example below:
{code:java}
{
"jku":
"https://dw-team-env-dl-gateway.dw-team.xcu2-8y8x.dev.cldr.work/dw-team-env-dl/homepage/knoxtoken/api/v1/jwks.json;,
"kid": "WK-ahKKYNs5PtFxMiPuMRhdjeEVlHpPkQRYs62-LjF4",
"typ": "JWT",
"alg": "RS256"
}{code}
Using this alg value, we can construct the JWT Public key on the server side
and also store this value.
The only concern is that we are now depending on the client request for this
value.
Is the customer okay with this ? thoughts ?
was (Author: JIRAUSER302462):
Impala requires the 'alg' value in the jwks.json stored on the impala cluster
(server side) in order to construct the {*}JWKPublicKey{*}.
{code:java}
{
"keys": [
{
"kty": "RSA",
"e": "AQAB",
"use": "sig",
"kid": "WK-ahKKYNs5PtFxMiPuMRhdjeEVlHpPkQRYs62-LjF4",
"alg": "RS256",
"n":
"2nyM8JEu45EcXjnDLfM_60cWQtwBmsmKeg-ZuMTcHHAKSOkV_Q39i2RAOnv8zs7TYH_meDvlYBgdQo9hYHlx4METd3XU4mMGYoZbhp66SyUcmvcRqBhSWGRMChUyMoG9meNZT9qgT1z-47Zn9STLRa3UMVCn_Wwmp8Sk81vtfwVLb7Vec6IlGYX-KSknWX19tUhfvok0q9CdEqf3DIsuGNue8o10rRFQ_VlGaX6FD28xZPyT0ZNYs5vivvJ7h6WQIdPaaN8VpbTqiOEk8BGmYVgaMhF4O5MbFZyUUvJPAMBdulZvtHPJOxhV45IgcmIGgHWBE2Ylk2QV_3gAD9MpxQ"
}
]
}{code}
If that field is missing(since its optional), then we would have to defer the
JWKPublicKey creation until we receive first valid request from the client
which will contain the alg field in the header (mandatory field). Example below:
{code:java}
{
"jku":
"https://dw-team-env-dl-gateway.dw-team.xcu2-8y8x.dev.cldr.work/dw-team-env-dl/homepage/knoxtoken/api/v1/jwks.json;,
"kid": "WK-ahKKYNs5PtFxMiPuMRhdjeEVlHpPkQRYs62-LjF4",
"typ": "JWT",
"alg": "RS256"
}{code}
Using this alg value, we can construct the JWT Public key on the server side
and also store this value.
The only concern is that we are now depending on the client request for this
value.
Any thoughts on this ?
> JSON Web Keys (JWK) Must Not Require the Optional alg Property
> --
>
> Key: IMPALA-12558
> URL: https://issues.apache.org/jira/browse/IMPALA-12558
> Project: IMPALA
> Issue Type: Bug
> Components: be, Security
>Reporter: Jason Fehr
>Assignee: gaurav singh
>Priority: Critical
> Labels: JWT, jwt, security
>
> According to the [JWK
> RFC|https://datatracker.ietf.org/doc/html/rfc7517#section-4.4], the "alg"
> property is optional on JWKs.
> Update Impala so that the "alg" property is no longer required on the JWKs.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Comment Edited] (IMPALA-12558) JSON Web Keys (JWK) Must Not Require the Optional alg Property
[
https://issues.apache.org/jira/browse/IMPALA-12558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17830533#comment-17830533
]
gaurav singh edited comment on IMPALA-12558 at 3/25/24 3:13 PM:
Impala requires the 'alg' value in the jwks.json stored on the impala cluster
(server side) in order to construct the {*}JWKPublicKey{*}.
{code:java}
{
"keys": [
{
"kty": "RSA",
"e": "AQAB",
"use": "sig",
"kid": "WK-ahKKYNs5PtFxMiPuMRhdjeEVlHpPkQRYs62-LjF4",
"alg": "RS256",
"n":
"2nyM8JEu45EcXjnDLfM_60cWQtwBmsmKeg-ZuMTcHHAKSOkV_Q39i2RAOnv8zs7TYH_meDvlYBgdQo9hYHlx4METd3XU4mMGYoZbhp66SyUcmvcRqBhSWGRMChUyMoG9meNZT9qgT1z-47Zn9STLRa3UMVCn_Wwmp8Sk81vtfwVLb7Vec6IlGYX-KSknWX19tUhfvok0q9CdEqf3DIsuGNue8o10rRFQ_VlGaX6FD28xZPyT0ZNYs5vivvJ7h6WQIdPaaN8VpbTqiOEk8BGmYVgaMhF4O5MbFZyUUvJPAMBdulZvtHPJOxhV45IgcmIGgHWBE2Ylk2QV_3gAD9MpxQ"
}
]
}{code}
If that field is missing(since its optional), then we would have to defer the
JWKPublicKey creation until we receive first valid request from the client
which will contain the alg field in the header (mandatory field). Example below:
{code:java}
{
"jku":
"https://dw-team-env-dl-gateway.dw-team.xcu2-8y8x.dev.cldr.work/dw-team-env-dl/homepage/knoxtoken/api/v1/jwks.json;,
"kid": "WK-ahKKYNs5PtFxMiPuMRhdjeEVlHpPkQRYs62-LjF4",
"typ": "JWT",
"alg": "RS256"
}{code}
Using this alg value, we can construct the JWT Public key on the server side
and also store this value.
The only concern is that we are now depending on the client request for this
value.
Any thoughts on this ?
was (Author: JIRAUSER302462):
Impala requires the 'alg' value in the jwks.json stored on the impala cluster
(server side) in order to construct the {*}JWKPublicKey{*}.
{code:java}
{
"keys": [
{
"kty": "RSA",
"e": "AQAB",
"use": "sig",
"kid": "WK-ahKKYNs5PtFxMiPuMRhdjeEVlHpPkQRYs62-LjF4",
"alg": "RS256",
"n":
"2nyM8JEu45EcXjnDLfM_60cWQtwBmsmKeg-ZuMTcHHAKSOkV_Q39i2RAOnv8zs7TYH_meDvlYBgdQo9hYHlx4METd3XU4mMGYoZbhp66SyUcmvcRqBhSWGRMChUyMoG9meNZT9qgT1z-47Zn9STLRa3UMVCn_Wwmp8Sk81vtfwVLb7Vec6IlGYX-KSknWX19tUhfvok0q9CdEqf3DIsuGNue8o10rRFQ_VlGaX6FD28xZPyT0ZNYs5vivvJ7h6WQIdPaaN8VpbTqiOEk8BGmYVgaMhF4O5MbFZyUUvJPAMBdulZvtHPJOxhV45IgcmIGgHWBE2Ylk2QV_3gAD9MpxQ"
}
]
}{code}
If that field is missing, then we would have to defer the JWKPublicKey creation
until we receive first valid request from the client which will contain the alg
field in the header (mandatory field). Example below:
{code:java}
{
"jku":
"https://dw-team-env-dl-gateway.dw-team.xcu2-8y8x.dev.cldr.work/dw-team-env-dl/homepage/knoxtoken/api/v1/jwks.json;,
"kid": "WK-ahKKYNs5PtFxMiPuMRhdjeEVlHpPkQRYs62-LjF4",
"typ": "JWT",
"alg": "RS256"
}{code}
Using this alg value, we can construct the JWT Public key on the server side
and also store this value.
The only concern is that we are now depending on the client request for this
value.
Any thoughts on this ?
> JSON Web Keys (JWK) Must Not Require the Optional alg Property
> --
>
> Key: IMPALA-12558
> URL: https://issues.apache.org/jira/browse/IMPALA-12558
> Project: IMPALA
> Issue Type: Bug
> Components: be, Security
>Reporter: Jason Fehr
>Assignee: gaurav singh
>Priority: Critical
> Labels: JWT, jwt, security
>
> According to the [JWK
> RFC|https://datatracker.ietf.org/doc/html/rfc7517#section-4.4], the "alg"
> property is optional on JWKs.
> Update Impala so that the "alg" property is no longer required on the JWKs.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Commented] (IMPALA-12558) JSON Web Keys (JWK) Must Not Require the Optional alg Property
[
https://issues.apache.org/jira/browse/IMPALA-12558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17830533#comment-17830533
]
gaurav singh commented on IMPALA-12558:
---
Impala requires the 'alg' value in the jwks.json stored on the impala cluster
(server side) in order to construct the {*}JWKPublicKey{*}.
{code:java}
{
"keys": [
{
"kty": "RSA",
"e": "AQAB",
"use": "sig",
"kid": "WK-ahKKYNs5PtFxMiPuMRhdjeEVlHpPkQRYs62-LjF4",
"alg": "RS256",
"n":
"2nyM8JEu45EcXjnDLfM_60cWQtwBmsmKeg-ZuMTcHHAKSOkV_Q39i2RAOnv8zs7TYH_meDvlYBgdQo9hYHlx4METd3XU4mMGYoZbhp66SyUcmvcRqBhSWGRMChUyMoG9meNZT9qgT1z-47Zn9STLRa3UMVCn_Wwmp8Sk81vtfwVLb7Vec6IlGYX-KSknWX19tUhfvok0q9CdEqf3DIsuGNue8o10rRFQ_VlGaX6FD28xZPyT0ZNYs5vivvJ7h6WQIdPaaN8VpbTqiOEk8BGmYVgaMhF4O5MbFZyUUvJPAMBdulZvtHPJOxhV45IgcmIGgHWBE2Ylk2QV_3gAD9MpxQ"
}
]
}{code}
If that field is missing, then we would have to defer the JWKPublicKey creation
until we receive first valid request from the client which will contain the alg
field in the header (mandatory field). Example below:
{code:java}
{
"jku":
"https://dw-team-env-dl-gateway.dw-team.xcu2-8y8x.dev.cldr.work/dw-team-env-dl/homepage/knoxtoken/api/v1/jwks.json;,
"kid": "WK-ahKKYNs5PtFxMiPuMRhdjeEVlHpPkQRYs62-LjF4",
"typ": "JWT",
"alg": "RS256"
}{code}
Using this alg value, we can construct the JWT Public key on the server side
and also store this value.
The only concern is that we are now depending on the client request for this
value.
Any thoughts on this ?
> JSON Web Keys (JWK) Must Not Require the Optional alg Property
> --
>
> Key: IMPALA-12558
> URL: https://issues.apache.org/jira/browse/IMPALA-12558
> Project: IMPALA
> Issue Type: Bug
> Components: be, Security
>Reporter: Jason Fehr
>Assignee: gaurav singh
>Priority: Critical
> Labels: JWT, jwt, security
>
> According to the [JWK
> RFC|https://datatracker.ietf.org/doc/html/rfc7517#section-4.4], the "alg"
> property is optional on JWKs.
> Update Impala so that the "alg" property is no longer required on the JWKs.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Work started] (IMPALA-12874) Identify Catalog HA and StateStore HA from the web debug endpoint
[
https://issues.apache.org/jira/browse/IMPALA-12874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on IMPALA-12874 started by gaurav singh.
-
> Identify Catalog HA and StateStore HA from the web debug endpoint
> -
>
> Key: IMPALA-12874
> URL: https://issues.apache.org/jira/browse/IMPALA-12874
> Project: IMPALA
> Issue Type: Improvement
> Components: Backend
>Reporter: gaurav singh
>Assignee: gaurav singh
>Priority: Major
>
> Identify which Catalog and Statestore instance is active from the web debug
> endpoint.
> For the HA, we should improve the label on catalog and statestore web
> response to indicate "Active" instance.
> On the main page we could indicate "Status: Active" or "Status: Stand-by". We
> could probably add the status at the top of the main page before *"Version"*
> . The current details as output of a curl request on port 25020:
> {code:java}
> Version
> catalogd version 4.0.0.2024.0.18.0-61 RELEASE (build
> 82901f3f83fa4c25b318ebf825a1505d89209356)
> Built on Fri Mar 1 20:13:09 UTC 2024
> Build Flags: is_ndebug=true cmake_build_type=RELEASE
> library_link_type=STATIC
>
> Process Start Time
> ..
> {code}
> Corresponding curl request on statestored on 25010:
> {code:java}
> Version
> statestored version 4.0.0.2024.0.18.0-61 RELEASE
> (build 82901f3f83fa4c25b318ebf825a1505d89209356)
> Built on Fri Mar 1 20:13:09 UTC 2024
> Build Flags: is_ndebug=true cmake_build_type=RELEASE
> library_link_type=STATIC
>
> Process Start Time
> {code}
> Catalogd active status can be figured out using the catalogd metric:
> "catalog-server.active-status"
> Statestored active status we probably don't have a metric so should add a
> similar metric and use that to determine status.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-12874) Identify Catalog HA and StateStore HA from the web debug endpoint
[
https://issues.apache.org/jira/browse/IMPALA-12874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
gaurav singh updated IMPALA-12874:
--
Description:
Identify which Catalog and Statestore instance is active from the web debug
endpoint.
For the HA, we should improve the label on catalog and statestore web response
to indicate "Active" instance.
On the main page we could indicate "Status: Active" or "Status: Stand-by". We
could probably add the status at the top of the main page before *"Version"* .
The current details as output of a curl request on port 25020:
{code:java}
Version
catalogd version 4.0.0.2024.0.18.0-61 RELEASE (build
82901f3f83fa4c25b318ebf825a1505d89209356)
Built on Fri Mar 1 20:13:09 UTC 2024
Build Flags: is_ndebug=true cmake_build_type=RELEASE library_link_type=STATIC
Process Start Time
..
{code}
Corresponding curl request on statestored on 25010:
{code:java}
Version
statestored version 4.0.0.2024.0.18.0-61 RELEASE (build
82901f3f83fa4c25b318ebf825a1505d89209356)
Built on Fri Mar 1 20:13:09 UTC 2024
Build Flags: is_ndebug=true cmake_build_type=RELEASE library_link_type=STATIC
Process Start Time
{code}
Catalogd active status can be figured out using the catalogd metric:
"catalog-server.active-status"
Statestored active status we probably don't have a metric so should add a
similar metric and use that to determine status.
was:
Identify which Catalog and Statestore daemon is active from the web debug
endpoint.
For the HA, we should improve the label on catalog and statestore web response
to indicate "Active" instance.
On the main page we could indicate "Status: Active" or "Status: Stand-by". We
could probably add the status at the top of the main page before *"Version"* .
The current details as output of a curl request on port 25020:
{code:java}
Version
catalogd version 4.0.0.2024.0.18.0-61 RELEASE (build
82901f3f83fa4c25b318ebf825a1505d89209356)
Built on Fri Mar 1 20:13:09 UTC 2024
Build Flags: is_ndebug=true cmake_build_type=RELEASE library_link_type=STATIC
Process Start Time
..
{code}
Corresponding curl request on statestored on 25010:
{code:java}
Version
statestored version 4.0.0.2024.0.18.0-61 RELEASE (build
82901f3f83fa4c25b318ebf825a1505d89209356)
Built on Fri Mar 1 20:13:09 UTC 2024
Build Flags: is_ndebug=true cmake_build_type=RELEASE library_link_type=STATIC
Process Start Time
{code}
Catalogd active status can be figured out using the catalogd metric:
"catalog-server.active-status"
Statestored active status we probably don't have a metric so should add a
similar metric and use that to determine status.
> Identify Catalog HA and StateStore HA from the web debug endpoint
> -
>
> Key: IMPALA-12874
> URL: https://issues.apache.org/jira/browse/IMPALA-12874
> Project: IMPALA
> Issue Type: Improvement
> Components: Backend
>Reporter: gaurav singh
>Assignee: gaurav singh
>Priority: Major
>
> Identify which Catalog and Statestore instance is active from the web debug
> endpoint.
> For the HA, we should improve the label on catalog and statestore web
> response to indicate "Active" instance.
> On the main page we could indicate "Status: Active" or "Status: Stand-by". We
> could probably add the status at the top of the main page before *"Version"*
> . The current details as output of a curl request on port 25020:
> {code:java}
> Version
> catalogd version 4.0.0.2024.0.18.0-61 RELEASE (build
> 82901f3f83fa4c25b318ebf825a1505d89209356)
> Built on Fri Mar 1 20:13:09 UTC 2024
> Build Flags: is_ndebug=true cmake_build_type=RELEASE
> library_link_type=STATIC
>
> Process Start Time
> ..
> {code}
> Corresponding curl request on statestored on 25010:
> {code:java}
> Version
> statestored version 4.0.0.2024.0.18.0-61 RELEASE
> (build 82901f3f83fa4c25b318ebf825a1505d89209356)
> Built on Fri Mar 1 20:13:09 UTC 2024
> Build Flags: is_ndebug=true cmake_build_type=RELEASE
> library_link_type=STATIC
>
> Process Start Time
> {code}
> Catalogd active status can be figured out using the catalogd metric:
> "catalog-server.active-status"
> Statestored active status we probably don't have a metric so should add a
> similar metric and use that to determine status.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-12874) Identify Catalog HA and StateStore HA from the web debug endpoint
[
https://issues.apache.org/jira/browse/IMPALA-12874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
gaurav singh updated IMPALA-12874:
--
Description:
Identify which Catalog and Statestore daemon is active from the web debug
endpoint.
For the HA, we should improve the label on catalog and statestore web response
to indicate "Active" instance.
On the main page we could indicate "Status: Active" or "Status: Stand-by". We
could probably add the status at the top of the main page before *"Version"* .
The current details as output of a curl request on port 25020:
{code:java}
Version
catalogd version 4.0.0.2024.0.18.0-61 RELEASE (build
82901f3f83fa4c25b318ebf825a1505d89209356)
Built on Fri Mar 1 20:13:09 UTC 2024
Build Flags: is_ndebug=true cmake_build_type=RELEASE library_link_type=STATIC
Process Start Time
..
{code}
Corresponding curl request on statestored on 25010:
{code:java}
Version
statestored version 4.0.0.2024.0.18.0-61 RELEASE (build
82901f3f83fa4c25b318ebf825a1505d89209356)
Built on Fri Mar 1 20:13:09 UTC 2024
Build Flags: is_ndebug=true cmake_build_type=RELEASE library_link_type=STATIC
Process Start Time
{code}
Catalogd active status can be figured out using the catalogd metric:
"catalog-server.active-status"
Statestored active status we probably don't have a metric so should add a
similar metric and use that to determine status.
was:
Identify which Catalog and Statestore pod is active from the web debug endpoint.
For the HA, we should improve the label on catalog and statestore web response
to indicate "Active" instance.
On the main page we could indicate "Status: Active" or "Status: Stand-by". We
could probably add the status at the top of the main page before *"Version"* .
The current details as output of a curl request on port 25020:
{code:java}
Version
catalogd version 4.0.0.2024.0.18.0-61 RELEASE (build
82901f3f83fa4c25b318ebf825a1505d89209356)
Built on Fri Mar 1 20:13:09 UTC 2024
Build Flags: is_ndebug=true cmake_build_type=RELEASE library_link_type=STATIC
Process Start Time
..
{code}
Corresponding curl request on statestored on 25010:
{code:java}
Version
statestored version 4.0.0.2024.0.18.0-61 RELEASE (build
82901f3f83fa4c25b318ebf825a1505d89209356)
Built on Fri Mar 1 20:13:09 UTC 2024
Build Flags: is_ndebug=true cmake_build_type=RELEASE library_link_type=STATIC
Process Start Time
{code}
Catalogd active status can be figured out using the catalogd metric:
"catalog-server.active-status"
Statestored active status we probably don't have a metric so should add a
similar metric and use that to determine status.
> Identify Catalog HA and StateStore HA from the web debug endpoint
> -
>
> Key: IMPALA-12874
> URL: https://issues.apache.org/jira/browse/IMPALA-12874
> Project: IMPALA
> Issue Type: Improvement
> Components: Backend
>Reporter: gaurav singh
>Assignee: gaurav singh
>Priority: Major
>
> Identify which Catalog and Statestore daemon is active from the web debug
> endpoint.
> For the HA, we should improve the label on catalog and statestore web
> response to indicate "Active" instance.
> On the main page we could indicate "Status: Active" or "Status: Stand-by". We
> could probably add the status at the top of the main page before *"Version"*
> . The current details as output of a curl request on port 25020:
> {code:java}
> Version
> catalogd version 4.0.0.2024.0.18.0-61 RELEASE (build
> 82901f3f83fa4c25b318ebf825a1505d89209356)
> Built on Fri Mar 1 20:13:09 UTC 2024
> Build Flags: is_ndebug=true cmake_build_type=RELEASE
> library_link_type=STATIC
>
> Process Start Time
> ..
> {code}
> Corresponding curl request on statestored on 25010:
> {code:java}
> Version
> statestored version 4.0.0.2024.0.18.0-61 RELEASE
> (build 82901f3f83fa4c25b318ebf825a1505d89209356)
> Built on Fri Mar 1 20:13:09 UTC 2024
> Build Flags: is_ndebug=true cmake_build_type=RELEASE
> library_link_type=STATIC
>
> Process Start Time
> {code}
> Catalogd active status can be figured out using the catalogd metric:
> "catalog-server.active-status"
> Statestored active status we probably don't have a metric so should add a
> similar metric and use that to determine status.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Closed] (IMPALA-12875) Identify Coordinator HA from the web debug endpoint
[
https://issues.apache.org/jira/browse/IMPALA-12875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
gaurav singh closed IMPALA-12875.
-
Resolution: Abandoned
> Identify Coordinator HA from the web debug endpoint
> ---
>
> Key: IMPALA-12875
> URL: https://issues.apache.org/jira/browse/IMPALA-12875
> Project: IMPALA
> Issue Type: Improvement
> Components: Backend
>Reporter: gaurav singh
>Assignee: gaurav singh
>Priority: Major
>
> Identify which Coordinator pod is active from the web debug endpoint.
> For the HA, we should improve the label on coordinator web response to
> indicate "Active" instance.
> On the main page we could indicate "Status: Active" or "Status: Stand-by". We
> could probably add the status at the top of the main page before *"Version"*
> . The current details as output of a curl request on port 25000:
> {code:java}
> Impala Server Mode: Coordinator
> (Local Catalog Mode)
>
> Version
> impalad version 4.0.0.2024.0.18.0-61 RELEASE (build
> 82901f3f83fa4c25b318ebf825a1505d89209356)
> Built on Fri Mar 1 20:13:09 UTC 2024
> Build Flags: is_ndebug=true cmake_build_type=RELEASE
> library_link_type=STATIC
> Process Start Time
> 2024-03-05 17:09:09.007435000 {code}
> Coordinator active detection is a bit tricky as that's handled on K8s side.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Work stopped] (IMPALA-12722) Add test cases for MySQL and Postgres to set additional properties with jdbc.properties
[ https://issues.apache.org/jira/browse/IMPALA-12722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on IMPALA-12722 stopped by gaurav singh. - > Add test cases for MySQL and Postgres to set additional properties with > jdbc.properties > --- > > Key: IMPALA-12722 > URL: https://issues.apache.org/jira/browse/IMPALA-12722 > Project: IMPALA > Issue Type: Sub-task > Components: Frontend >Affects Versions: Impala 4.4.0 >Reporter: Wenzhe Zhou >Assignee: gaurav singh >Priority: Major > > IMPALA-12642 added supporting query options for Impala external JDBC table. > It uses JDBC connection string to apply query options to the Impala server by > setting the properties in "jdbc.properties" when creating JDBC external > DataSource table. > jdbc.properties can be used for other databases like Postgres and MySQL > to set additional properties. We need to add test cases for Postgres and > MySQL to verify if the settings take effect. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-12875) Identify Coordinator HA from the web debug endpoint
[
https://issues.apache.org/jira/browse/IMPALA-12875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
gaurav singh updated IMPALA-12875:
--
Description:
Identify which Coordinator pod is active from the web debug endpoint.
For the HA, we should improve the label on coordinator web response to indicate
"Active" instance.
On the main page we could indicate "Status: Active" or "Status: Stand-by". We
could probably add the status at the top of the main page before *"Version"* .
The current details as output of a curl request on port 25000:
{code:java}
Impala Server Mode: Coordinator
(Local Catalog Mode)
Version
impalad version 4.0.0.2024.0.18.0-61 RELEASE (build
82901f3f83fa4c25b318ebf825a1505d89209356)
Built on Fri Mar 1 20:13:09 UTC 2024
Build Flags: is_ndebug=true cmake_build_type=RELEASE library_link_type=STATIC
Process Start Time
2024-03-05 17:09:09.007435000 {code}
Coordinator active detection is a bit tricky as that's handled on K8s side.
was:
Identify which Catalog and Statestore pod is active from the web debug endpoint.
For the HA, we should improve the label on catalog and statestore web response
to indicate "Active" instance.
On the main page we could indicate "Status: Active" or "Status: Stand-by". We
could probably add the status at the top of the main page before *"Version"* .
The current details as output of a curl request on port 25020:
{code:java}
Version
catalogd version 4.0.0.2024.0.18.0-61 RELEASE (build
82901f3f83fa4c25b318ebf825a1505d89209356)
Built on Fri Mar 1 20:13:09 UTC 2024
Build Flags: is_ndebug=true cmake_build_type=RELEASE library_link_type=STATIC
Process Start Time
..
{code}
Corresponding curl request on statestored on 25010:
{code:java}
Version
statestored version 4.0.0.2024.0.18.0-61 RELEASE (build
82901f3f83fa4c25b318ebf825a1505d89209356)
Built on Fri Mar 1 20:13:09 UTC 2024
Build Flags: is_ndebug=true cmake_build_type=RELEASE library_link_type=STATIC
Process Start Time
{code}
Catalogd active status can be figured out using the catalogd metric:
"catalog-server.active-status"
Statestored active status we probably don't have a metric so should add a
similar metric and use that to determine status.
> Identify Coordinator HA from the web debug endpoint
> ---
>
> Key: IMPALA-12875
> URL: https://issues.apache.org/jira/browse/IMPALA-12875
> Project: IMPALA
> Issue Type: Improvement
> Components: Backend
>Reporter: gaurav singh
>Assignee: gaurav singh
>Priority: Major
>
> Identify which Coordinator pod is active from the web debug endpoint.
> For the HA, we should improve the label on coordinator web response to
> indicate "Active" instance.
> On the main page we could indicate "Status: Active" or "Status: Stand-by". We
> could probably add the status at the top of the main page before *"Version"*
> . The current details as output of a curl request on port 25000:
> {code:java}
> Impala Server Mode: Coordinator
> (Local Catalog Mode)
>
> Version
> impalad version 4.0.0.2024.0.18.0-61 RELEASE (build
> 82901f3f83fa4c25b318ebf825a1505d89209356)
> Built on Fri Mar 1 20:13:09 UTC 2024
> Build Flags: is_ndebug=true cmake_build_type=RELEASE
> library_link_type=STATIC
> Process Start Time
> 2024-03-05 17:09:09.007435000 {code}
> Coordinator active detection is a bit tricky as that's handled on K8s side.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-12874) Identify Catalog HA and StateStore HA from the web debug endpoint
[
https://issues.apache.org/jira/browse/IMPALA-12874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
gaurav singh updated IMPALA-12874:
--
Description:
Identify which Catalog and Statestore pod is active from the web debug endpoint.
For the HA, we should improve the label on catalog and statestore web response
to indicate "Active" instance.
On the main page we could indicate "Status: Active" or "Status: Stand-by". We
could probably add the status at the top of the main page before *"Version"* .
The current details as output of a curl request on port 25020:
{code:java}
Version
catalogd version 4.0.0.2024.0.18.0-61 RELEASE (build
82901f3f83fa4c25b318ebf825a1505d89209356)
Built on Fri Mar 1 20:13:09 UTC 2024
Build Flags: is_ndebug=true cmake_build_type=RELEASE library_link_type=STATIC
Process Start Time
..
{code}
Corresponding curl request on statestored on 25010:
{code:java}
Version
statestored version 4.0.0.2024.0.18.0-61 RELEASE (build
82901f3f83fa4c25b318ebf825a1505d89209356)
Built on Fri Mar 1 20:13:09 UTC 2024
Build Flags: is_ndebug=true cmake_build_type=RELEASE library_link_type=STATIC
Process Start Time
{code}
Catalogd active status can be figured out using the catalogd metric:
"catalog-server.active-status"
Statestored active status we probably don't have a metric so should add a
similar metric and use that to determine status.
was:
Identify which Catalog and Statestore pod is active from the debug endpoint.
We should improve the label on catalog and statestore web ui to indicate
"Active" instance.
On the main page we could indicate "Status: Active" or "Status: Stand-by". We
could probably add the status at the top of the main page before *"Version"* .
The current details as output of a curl request on port 25020:
{code:java}
Version
catalogd version 4.0.0.2024.0.18.0-61 RELEASE (build
82901f3f83fa4c25b318ebf825a1505d89209356)
Built on Fri Mar 1 20:13:09 UTC 2024
Build Flags: is_ndebug=true cmake_build_type=RELEASE library_link_type=STATIC
Process Start Time
..
{code}
Corresponding curl request on statestored on 25010:
{code:java}
Version
statestored version 4.0.0.2024.0.18.0-61 RELEASE (build
82901f3f83fa4c25b318ebf825a1505d89209356)
Built on Fri Mar 1 20:13:09 UTC 2024
Build Flags: is_ndebug=true cmake_build_type=RELEASE library_link_type=STATIC
Process Start Time
{code}
Catalogd active status can be figured out using the catalogd metric:
"catalog-server.active-status"
Statestored active status we probably don't have a metric so should add a
similar metric and use that to determine status.
> Identify Catalog HA and StateStore HA from the web debug endpoint
> -
>
> Key: IMPALA-12874
> URL: https://issues.apache.org/jira/browse/IMPALA-12874
> Project: IMPALA
> Issue Type: Improvement
> Components: Backend
>Reporter: gaurav singh
>Assignee: gaurav singh
>Priority: Major
>
> Identify which Catalog and Statestore pod is active from the web debug
> endpoint.
> For the HA, we should improve the label on catalog and statestore web
> response to indicate "Active" instance.
> On the main page we could indicate "Status: Active" or "Status: Stand-by". We
> could probably add the status at the top of the main page before *"Version"*
> . The current details as output of a curl request on port 25020:
> {code:java}
> Version
> catalogd version 4.0.0.2024.0.18.0-61 RELEASE (build
> 82901f3f83fa4c25b318ebf825a1505d89209356)
> Built on Fri Mar 1 20:13:09 UTC 2024
> Build Flags: is_ndebug=true cmake_build_type=RELEASE
> library_link_type=STATIC
>
> Process Start Time
> ..
> {code}
> Corresponding curl request on statestored on 25010:
> {code:java}
> Version
> statestored version 4.0.0.2024.0.18.0-61 RELEASE
> (build 82901f3f83fa4c25b318ebf825a1505d89209356)
> Built on Fri Mar 1 20:13:09 UTC 2024
> Build Flags: is_ndebug=true cmake_build_type=RELEASE
> library_link_type=STATIC
>
> Process Start Time
> {code}
> Catalogd active status can be figured out using the catalogd metric:
> "catalog-server.active-status"
> Statestored active status we probably don't have a metric so should add a
> similar metric and use that to determine status.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Created] (IMPALA-12875) Identify Coordinator HA from the web debug endpoint
gaurav singh created IMPALA-12875:
-
Summary: Identify Coordinator HA from the web debug endpoint
Key: IMPALA-12875
URL: https://issues.apache.org/jira/browse/IMPALA-12875
Project: IMPALA
Issue Type: Improvement
Components: Backend
Reporter: gaurav singh
Assignee: gaurav singh
Identify which Catalog and Statestore pod is active from the web debug endpoint.
For the HA, we should improve the label on catalog and statestore web response
to indicate "Active" instance.
On the main page we could indicate "Status: Active" or "Status: Stand-by". We
could probably add the status at the top of the main page before *"Version"* .
The current details as output of a curl request on port 25020:
{code:java}
Version
catalogd version 4.0.0.2024.0.18.0-61 RELEASE (build
82901f3f83fa4c25b318ebf825a1505d89209356)
Built on Fri Mar 1 20:13:09 UTC 2024
Build Flags: is_ndebug=true cmake_build_type=RELEASE library_link_type=STATIC
Process Start Time
..
{code}
Corresponding curl request on statestored on 25010:
{code:java}
Version
statestored version 4.0.0.2024.0.18.0-61 RELEASE (build
82901f3f83fa4c25b318ebf825a1505d89209356)
Built on Fri Mar 1 20:13:09 UTC 2024
Build Flags: is_ndebug=true cmake_build_type=RELEASE library_link_type=STATIC
Process Start Time
{code}
Catalogd active status can be figured out using the catalogd metric:
"catalog-server.active-status"
Statestored active status we probably don't have a metric so should add a
similar metric and use that to determine status.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-12874) Identify Catalog HA and StateStore HA from the web debug endpoint
[
https://issues.apache.org/jira/browse/IMPALA-12874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
gaurav singh updated IMPALA-12874:
--
Summary: Identify Catalog HA and StateStore HA from the web debug endpoint
(was: Identify Catalog HA and StateStore HA from the debug endpoint)
> Identify Catalog HA and StateStore HA from the web debug endpoint
> -
>
> Key: IMPALA-12874
> URL: https://issues.apache.org/jira/browse/IMPALA-12874
> Project: IMPALA
> Issue Type: Improvement
> Components: Backend
>Reporter: gaurav singh
>Assignee: gaurav singh
>Priority: Major
>
> Identify which Catalog and Statestore pod is active from the debug endpoint.
> We should improve the label on catalog and statestore web ui to indicate
> "Active" instance.
> On the main page we could indicate "Status: Active" or "Status: Stand-by". We
> could probably add the status at the top of the main page before *"Version"*
> . The current details as output of a curl request on port 25020:
>
> {code:java}
> Version
> catalogd version 4.0.0.2024.0.18.0-61 RELEASE (build
> 82901f3f83fa4c25b318ebf825a1505d89209356)
> Built on Fri Mar 1 20:13:09 UTC 2024
> Build Flags: is_ndebug=true cmake_build_type=RELEASE
> library_link_type=STATIC
>
> Process Start Time
> ..
> {code}
>
> Corresponding curl request on statestored on 25010:
>
> {code:java}
> Version
> statestored version 4.0.0.2024.0.18.0-61 RELEASE
> (build 82901f3f83fa4c25b318ebf825a1505d89209356)
> Built on Fri Mar 1 20:13:09 UTC 2024
> Build Flags: is_ndebug=true cmake_build_type=RELEASE
> library_link_type=STATIC
>
> Process Start Time
> {code}
>
> Catalogd active status can be figured out using the catalogd metric:
> "catalog-server.active-status"
> Statestored active status we probably don't have a metric so should add a
> similar metric and use that to determine status.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Created] (IMPALA-12874) Identify Catalog HA and StateStore HA from the debug endpoint
gaurav singh created IMPALA-12874:
-
Summary: Identify Catalog HA and StateStore HA from the debug
endpoint
Key: IMPALA-12874
URL: https://issues.apache.org/jira/browse/IMPALA-12874
Project: IMPALA
Issue Type: Improvement
Components: Backend
Reporter: gaurav singh
Assignee: gaurav singh
Identify which Catalog and Statestore pod is active from the debug endpoint.
We should improve the label on catalog and statestore web ui to indicate
"Active" instance.
On the main page we could indicate "Status: Active" or "Status: Stand-by". We
could probably add the status at the top of the main page before *"Version"* .
The current details as output of a curl request on port 25020:
{code:java}
Version
catalogd version 4.0.0.2024.0.18.0-61 RELEASE (build
82901f3f83fa4c25b318ebf825a1505d89209356)
Built on Fri Mar 1 20:13:09 UTC 2024
Build Flags: is_ndebug=true cmake_build_type=RELEASE library_link_type=STATIC
Process Start Time
..
{code}
Corresponding curl request on statestored on 25010:
{code:java}
Version
statestored version 4.0.0.2024.0.18.0-61 RELEASE (build
82901f3f83fa4c25b318ebf825a1505d89209356)
Built on Fri Mar 1 20:13:09 UTC 2024
Build Flags: is_ndebug=true cmake_build_type=RELEASE library_link_type=STATIC
Process Start Time
{code}
Catalogd active status can be figured out using the catalogd metric:
"catalog-server.active-status"
Statestored active status we probably don't have a metric so should add a
similar metric and use that to determine status.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Work started] (IMPALA-12722) Add test cases for MySQL and Postgres to set additional properties with jdbc.properties
[ https://issues.apache.org/jira/browse/IMPALA-12722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on IMPALA-12722 started by gaurav singh. - > Add test cases for MySQL and Postgres to set additional properties with > jdbc.properties > --- > > Key: IMPALA-12722 > URL: https://issues.apache.org/jira/browse/IMPALA-12722 > Project: IMPALA > Issue Type: Sub-task > Components: Frontend >Affects Versions: Impala 4.4.0 >Reporter: Wenzhe Zhou >Assignee: gaurav singh >Priority: Major > > IMPALA-12642 added supporting query options for Impala external JDBC table. > It uses JDBC connection string to apply query options to the Impala server by > setting the properties in "jdbc.properties" when creating JDBC external > DataSource table. > jdbc.properties can be used for other databases like Postgres and MySQL > to set additional properties. We need to add test cases for Postgres and > MySQL to verify if the settings take effect. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-12503) Support date data type for predicates for external data source table
[ https://issues.apache.org/jira/browse/IMPALA-12503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] gaurav singh updated IMPALA-12503: -- Summary: Support date data type for predicates for external data source table (was: Support date and timestamp data type for predicates for external data source table) > Support date data type for predicates for external data source table > > > Key: IMPALA-12503 > URL: https://issues.apache.org/jira/browse/IMPALA-12503 > Project: IMPALA > Issue Type: Sub-task > Components: Backend, Frontend >Reporter: Wenzhe Zhou >Assignee: gaurav singh >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Work started] (IMPALA-12815) Support timestamp data type for predicates for external data source table
[ https://issues.apache.org/jira/browse/IMPALA-12815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on IMPALA-12815 started by gaurav singh. - > Support timestamp data type for predicates for external data source table > - > > Key: IMPALA-12815 > URL: https://issues.apache.org/jira/browse/IMPALA-12815 > Project: IMPALA > Issue Type: Sub-task > Components: Backend, Frontend >Reporter: gaurav singh >Assignee: gaurav singh >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Resolved] (IMPALA-12503) Support date data type for predicates for external data source table
[ https://issues.apache.org/jira/browse/IMPALA-12503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] gaurav singh resolved IMPALA-12503. --- Resolution: Fixed > Support date data type for predicates for external data source table > > > Key: IMPALA-12503 > URL: https://issues.apache.org/jira/browse/IMPALA-12503 > Project: IMPALA > Issue Type: Sub-task > Components: Backend, Frontend >Reporter: Wenzhe Zhou >Assignee: gaurav singh >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Created] (IMPALA-12815) Support timestamp data type for predicates for external data source table
gaurav singh created IMPALA-12815: - Summary: Support timestamp data type for predicates for external data source table Key: IMPALA-12815 URL: https://issues.apache.org/jira/browse/IMPALA-12815 Project: IMPALA Issue Type: Sub-task Components: Backend, Frontend Reporter: gaurav singh Assignee: gaurav singh -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Resolved] (IMPALA-12470) Support different schemes for jdbc driver url when creating external jdbc table
[
https://issues.apache.org/jira/browse/IMPALA-12470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
gaurav singh resolved IMPALA-12470.
---
Fix Version/s: Impala 4.4.0
Resolution: Fixed
> Support different schemes for jdbc driver url when creating external jdbc
> table
> ---
>
> Key: IMPALA-12470
> URL: https://issues.apache.org/jira/browse/IMPALA-12470
> Project: IMPALA
> Issue Type: Sub-task
> Components: Frontend
>Reporter: Wenzhe Zhou
>Assignee: gaurav singh
>Priority: Major
> Fix For: Impala 4.4.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> jdbc driver url is specified as table property 'driver.url' when creating a
> external jdbc table, like the sample below:
> {code:java}
> CREATE TABLE test_postgres (
> id INT,
> string_col STRING)
> PRODUCED BY DATA SOURCE JdbcDataSource(
> '{"database.type":"POSTGRES",
> "jdbc.url":"jdbc:postgresql://localhost:5432/functional",
> "jdbc.driver":"org.postgresql.Driver",
> "driver.url":"hdfs://localhost:20500/test-warehouse/data-sources/jdbc-driver/postgresql-jdbc.jar",
> "dbcp.username":"hiveuser",
> "dbcp.password":"password",
> "table":"alltypes"}');
> {code}
> In the initial patch, we only support to download the driver jar files from
> hdfs. We need to support different storage type, like 'file://', 's3a://',
> etc.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Assigned] (IMPALA-12471) Scripts to run unit-tests of external jdbc table for MySQL
[ https://issues.apache.org/jira/browse/IMPALA-12471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] gaurav singh reassigned IMPALA-12471: - Assignee: gaurav singh > Scripts to run unit-tests of external jdbc table for MySQL > -- > > Key: IMPALA-12471 > URL: https://issues.apache.org/jira/browse/IMPALA-12471 > Project: IMPALA > Issue Type: Sub-task >Reporter: Wenzhe Zhou >Assignee: gaurav singh >Priority: Major > > Need to write scripts to run unit-tests of external jdbc table for MySQL. > These scripts could be used as references to run-unit for other SQL servers, > like MSSql, Oracle, etc. > Including: >download, install and start MySQL server >create user >create table and load data >download jdbc driver and copy driver jar file to hdfs >write sqls to create Impala external data source and external jdbc table >run sqls from impala-shell command line -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Assigned] (IMPALA-12470) Support different schemes for jdbc driver url when creating external jdbc table
[
https://issues.apache.org/jira/browse/IMPALA-12470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
gaurav singh reassigned IMPALA-12470:
-
Assignee: gaurav singh
> Support different schemes for jdbc driver url when creating external jdbc
> table
> ---
>
> Key: IMPALA-12470
> URL: https://issues.apache.org/jira/browse/IMPALA-12470
> Project: IMPALA
> Issue Type: Sub-task
> Components: Frontend
>Reporter: Wenzhe Zhou
>Assignee: gaurav singh
>Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> jdbc driver url is specified as table property 'driver.url' when creating a
> external jdbc table, like the sample below:
> {code:java}
> CREATE TABLE test_postgres (
> id INT,
> string_col STRING)
> PRODUCED BY DATA SOURCE JdbcDataSource(
> '{"database.type":"POSTGRES",
> "jdbc.url":"jdbc:postgresql://localhost:5432/functional",
> "jdbc.driver":"org.postgresql.Driver",
> "driver.url":"hdfs://localhost:20500/test-warehouse/data-sources/jdbc-driver/postgresql-jdbc.jar",
> "dbcp.username":"hiveuser",
> "dbcp.password":"password",
> "table":"alltypes"}');
> {code}
> In the initial patch, we only support to download the driver jar files from
> hdfs. We need to support different storage type, like 'file://', 's3a://',
> etc.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
