[jira] [Updated] (KUDU-1883) Support Ruby 2.4 in make docs task
[ https://issues.apache.org/jira/browse/KUDU-1883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Henke updated KUDU-1883: -- Description: While walking through the building Kudu steps I found my local ruby version broke the 'make docs' task. It looks like the ruby json gem doesn't support 2.4 until version 1.8.5+. An example of another project with this issue for context is [here|https://github.com/rails/rails/issues/27450] Additionally my macOS environment ran into an issue with the libv8 gem. It looks like xcode 7.3+ is not supported until version 3.16.14.14+. An example of another project with this issue for context is [here|https://github.com/cowboyd/therubyracer/issues/403]. I would usually put this change in a separate jira but since its so small I figured it makes sense to just have 1 change. Happy to break it out if needed. was: While walking through the building Kudu steps I found my local ruby version broke the 'make docs' task. It looks like the ruby json gem doesn't support 3.4 until version 1.8.5+. An example of another project with this issue for context is [here|https://github.com/rails/rails/issues/27450] Additionally my macOS environment ran into an issue with the libv8 gem. It looks like xcode 7.3+ is not supported until version 3.16.14.14+. An example of another project with this issue for context is [here|https://github.com/cowboyd/therubyracer/issues/403]. I would usually put this change in a separate jira but since its so small I figured it makes sense to just have 1 change. Happy to break it out if needed. > Support Ruby 2.4 in make docs task > -- > > Key: KUDU-1883 > URL: https://issues.apache.org/jira/browse/KUDU-1883 > Project: Kudu > Issue Type: Bug > Components: documentation >Reporter: Grant Henke >Assignee: Grant Henke >Priority: Trivial > > While walking through the building Kudu steps I found my local ruby version > broke the 'make docs' task. > It looks like the ruby json gem doesn't support 2.4 until version 1.8.5+. An > example of another project with this issue for context is > [here|https://github.com/rails/rails/issues/27450] > Additionally my macOS environment ran into an issue with the libv8 gem. It > looks like xcode 7.3+ is not supported until version 3.16.14.14+. An example > of another project with this issue for context is > [here|https://github.com/cowboyd/therubyracer/issues/403]. I would usually > put this change in a separate jira but since its so small I figured it makes > sense to just have 1 change. Happy to break it out if needed. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (KUDU-1882) Configuration improvements for Flume Kudu Sink regexp operations producer
[
https://issues.apache.org/jira/browse/KUDU-1882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Percy updated KUDU-1882:
-
Description:
The RegexpKuduOperationsProducer currently has the following configuration
options that could be improved:
||Property Name || Default || Required? || Description ||
| {code}producer.skipMissingColumn{code} | {code}false{code} | No | What to do
if a column in the Kudu table has no corresponding capture group. If set to
true, a warning message is logged and the operation is still attempted. If set
to false, an exception is thrown and the sink will not process the Event,
causing a Flume Channel rollback.|
| {code}producer.skipBadColumnValue{code} | {code}false{code} | No | What to do
if a value in the pattern match cannot be coerced to the required type. If set
to true, a warning message is logged and the operation is still attempted. If
set to false, an exception is thrown and the sink will not process the Event,
causing a Flume Channel rollback. |
| {code}producer.warnUnmatchedRows{code} | {code}true{code} | No | Whether to
log a warning about payloads that do not match the pattern. If set to false,
event bodies with no matches will be silently dropped. |
It would be an improvement if each of these concepts had the the following
options: {{warn}}, {{ignore}}, {{reject}}
Where {{warn}} would log a warning to the Flume log and continue processing,
{{ignore}} would attempt to continue processing without issuing a warning, and
{{reject}} would throw an exception.
It may be that some fields are nullable or have defaults, potentially due to an
ALTER TABLE, and we don't want to fill the Flume logs with useless warnings.
Users may also want to reject any Events that don't match their regex so they
can correct the configuration and restart Flume without losing those Events.
was:
The RegexpKuduOperationsProducer currently has the following configuration
options that could be improved:
||Property Name || Default || Required? || Description ||
| {{producer.skipMissingColumn}} | {{false}} | No | What to do if a column in
the Kudu table has no corresponding capture group. If set to true, a warning
message is logged and the operation is still attempted. If set to false, an
exception is thrown and the sink will not process the Event, causing a Flume
Channel rollback.|
| {{producer.skipBadColumnValue}} | {{false}} | No | What to do if a value in
the pattern match cannot be coerced to the required type. If set to true, a
warning message is logged and the operation is still attempted. If set to
false, an exception is thrown and the sink will not process the Event, causing
a Flume Channel rollback. |
| {{producer.warnUnmatchedRows}} | {{true}} | No | Whether to log a warning
about payloads that do not match the pattern. If set to false, event bodies
with no matches will be silently dropped. |
It would be an improvement if each of these concepts had the the following
options: {{warn}}, {{ignore}}, {{reject}}
Where {{warn}} would log a warning to the Flume log and continue processing,
{{ignore}} would attempt to continue processing without issuing a warning, and
{{reject}} would throw an exception.
It may be that some fields are nullable or have defaults, potentially due to an
ALTER TABLE, and we don't want to fill the Flume logs with useless warnings.
Users may also want to reject any Events that don't match their regex so they
can correct the configuration and restart Flume without losing those Events.
> Configuration improvements for Flume Kudu Sink regexp operations producer
> -
>
> Key: KUDU-1882
> URL: https://issues.apache.org/jira/browse/KUDU-1882
> Project: Kudu
> Issue Type: Bug
> Components: flume-sink, integration
>Affects Versions: 1.2.0
>Reporter: Mike Percy
>
> The RegexpKuduOperationsProducer currently has the following configuration
> options that could be improved:
> ||Property Name || Default || Required? || Description ||
> | {code}producer.skipMissingColumn{code} | {code}false{code} | No | What to
> do if a column in the Kudu table has no corresponding capture group. If set
> to true, a warning message is logged and the operation is still attempted. If
> set to false, an exception is thrown and the sink will not process the Event,
> causing a Flume Channel rollback.|
> | {code}producer.skipBadColumnValue{code} | {code}false{code} | No | What to
> do if a value in the pattern match cannot be coerced to the required type. If
> set to true, a warning message is logged and the operation is still
> attempted. If set to false, an exception is thrown and the sink will not
> process the Event, causing a Flume Channel rollback. |
> | {code}producer.warnUnmatchedRows{code} | {code}true{code} | No | Whether to
>
[jira] [Updated] (KUDU-1882) Configuration improvements for Flume Kudu Sink regexp operations producer
[
https://issues.apache.org/jira/browse/KUDU-1882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Percy updated KUDU-1882:
-
Description:
The RegexpKuduOperationsProducer currently has the following configuration
options that could be improved:
||Property Name || Default || Required? || Description ||
| {{producer.skipMissingColumn}} | {{false}} | No | What to do if a column in
the Kudu table has no corresponding capture group. If set to true, a warning
message is logged and the operation is still attempted. If set to false, an
exception is thrown and the sink will not process the Event, causing a Flume
Channel rollback.|
| {{producer.skipBadColumnValue}} | {{false}} | No | What to do if a value in
the pattern match cannot be coerced to the required type. If set to true, a
warning message is logged and the operation is still attempted. If set to
false, an exception is thrown and the sink will not process the Event, causing
a Flume Channel rollback. |
| {{producer.warnUnmatchedRows}} | {{true}} | No | Whether to log a warning
about payloads that do not match the pattern. If set to false, event bodies
with no matches will be silently dropped. |
It would be an improvement if each of these concepts had the the following
options: {{warn}}, {{ignore}}, {{reject}}
Where {{warn}} would log a warning to the Flume log and continue processing,
{{ignore}} would attempt to continue processing without issuing a warning, and
{{reject}} would throw an exception.
It may be that some fields are nullable or have defaults, potentially due to an
ALTER TABLE, and we don't want to fill the Flume logs with useless warnings.
Users may also want to reject any Events that don't match their regex so they
can correct the configuration and restart Flume without losing those Events.
was:
The RegexpKuduOperationsProducer currently has the following configuration
options that could be improved:
||Property Name || Default || Required? || Description ||
| producer.skipMissingColumn | false | No | What to do if a column in the
Kudu table has no corresponding capture group. If set to true, a warning
message is logged and the operation is still attempted. If set to false, an
exception is thrown and the sink will not process the Event, causing a Flume
Channel rollback.|
| producer.skipBadColumnValue | false | No | What to do if a value in the
pattern match cannot be coerced to the required type. If set to true, a warning
message is logged and the operation is still attempted. If set to false, an
exception is thrown and the sink will not process the Event, causing a Flume
Channel rollback. |
| producer.warnUnmatchedRows | true | No | Whether to log a warning about
payloads that do not match the pattern. If set to false, event bodies with no
matches will be silently dropped. |
It would be an improvement if each of these concepts had the the following
options: {{warn}}, {{ignore}}, {{reject}}
Where {{warn}} would log a warning to the Flume log and continue processing,
{{ignore}} would attempt to continue processing without issuing a warning, and
{{reject}} would throw an exception.
It may be that some fields are nullable or have defaults, potentially due to an
ALTER TABLE, and we don't want to fill the Flume logs with useless warnings.
Users may also want to reject any Events that don't match their regex so they
can correct the configuration and restart Flume without losing those Events.
> Configuration improvements for Flume Kudu Sink regexp operations producer
> -
>
> Key: KUDU-1882
> URL: https://issues.apache.org/jira/browse/KUDU-1882
> Project: Kudu
> Issue Type: Bug
> Components: flume-sink, integration
>Affects Versions: 1.2.0
>Reporter: Mike Percy
>
> The RegexpKuduOperationsProducer currently has the following configuration
> options that could be improved:
> ||Property Name || Default || Required? || Description ||
> | {{producer.skipMissingColumn}} | {{false}} | No | What to do if a column in
> the Kudu table has no corresponding capture group. If set to true, a warning
> message is logged and the operation is still attempted. If set to false, an
> exception is thrown and the sink will not process the Event, causing a Flume
> Channel rollback.|
> | {{producer.skipBadColumnValue}} | {{false}} | No | What to do if a value in
> the pattern match cannot be coerced to the required type. If set to true, a
> warning message is logged and the operation is still attempted. If set to
> false, an exception is thrown and the sink will not process the Event,
> causing a Flume Channel rollback. |
> | {{producer.warnUnmatchedRows}} | {{true}} | No | Whether to log a warning
> about payloads that do not match the pattern. If set to false, event bodies
> with no matches will
[jira] [Assigned] (KUDU-1883) Support Ruby 3.4 in make docs task
[ https://issues.apache.org/jira/browse/KUDU-1883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Henke reassigned KUDU-1883: - Assignee: Grant Henke > Support Ruby 3.4 in make docs task > -- > > Key: KUDU-1883 > URL: https://issues.apache.org/jira/browse/KUDU-1883 > Project: Kudu > Issue Type: Bug > Components: documentation >Reporter: Grant Henke >Assignee: Grant Henke >Priority: Trivial > > While walking through the building Kudu steps I found my local ruby version > broke the 'make docs' task. > It looks like the ruby json gem doesn't support 3.4 until version 1.8.5+. An > example of another project with this issue for context is > [here|https://github.com/rails/rails/issues/27450] > Additionally my macOS environment ran into an issue with the libv8 gem. It > looks like xcode 7.3+ is not supported until version 3.16.14.14+. An example > of another project with this issue for context is > [here|https://github.com/cowboyd/therubyracer/issues/403]. I would usually > put this change in a separate jira but since its so small I figured it makes > sense to just have 1 change. Happy to break it out if needed. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (KUDU-1883) Support Ruby 3.4 in make docs task
Grant Henke created KUDU-1883: - Summary: Support Ruby 3.4 in make docs task Key: KUDU-1883 URL: https://issues.apache.org/jira/browse/KUDU-1883 Project: Kudu Issue Type: Bug Components: documentation Reporter: Grant Henke Priority: Trivial While walking through the building Kudu steps I found my local ruby version broke the 'make docs' task. It looks like the ruby json gem doesn't support 3.4 until version 1.8.5+. An example of another project with this issue for context is [here|https://github.com/rails/rails/issues/27450] Additionally my macOS environment ran into an issue with the libv8 gem. It looks like xcode 7.3+ is not supported until version 3.16.14.14+. An example of another project with this issue for context is [here|https://github.com/cowboyd/therubyracer/issues/403]. I would usually put this change in a separate jira but since its so small I figured it makes sense to just have 1 change. Happy to break it out if needed. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (KUDU-1855) Kudu file UNIX permissions are inconsistent
[
https://issues.apache.org/jira/browse/KUDU-1855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Todd Lipcon updated KUDU-1855:
--
Resolution: Fixed
Fix Version/s: 1.3.0
Status: Resolved (was: In Review)
> Kudu file UNIX permissions are inconsistent
> ---
>
> Key: KUDU-1855
> URL: https://issues.apache.org/jira/browse/KUDU-1855
> Project: Kudu
> Issue Type: Bug
> Components: security
>Affects Versions: 1.3.0
>Reporter: Adar Dembo
>Assignee: Todd Lipcon
>Priority: Blocker
> Fix For: 1.3.0
>
>
> Right now the access modes of Kudu files on disk are quite inconsistent. For
> example:
> {noformat}
> 6942960 drwxr-xr-x 4 kudu kudu 27 Jun 21 2016
> /data/1/kudu/tablet
> 21501102670 drwxr-xr-x 5 kudu kudu 71 Jan 17 17:42
> /data/1/kudu/tablet/data
> 21501241274 -rw--- 1 kudu kudu 665 Jun 21 2016
> /data/1/kudu/tablet/data/instance
> 702851 16 drwxr-xr-x 2 kudu kudu12288 Jan 31 14:02
> /data/1/kudu/tablet/data/tablet-meta
> 702894 12 -rw--- 1 kudu kudu 9501 Jan 22 13:38
> /data/1/kudu/tablet/data/tablet-meta/33cc61001d1442048a588f930d973464
> ...
> 21538687298 -rw--- 1 kudu kudu 8109 Jan 12 22:26
> /data/1/kudu/tablet/data/consensus-meta/83a2f75a88bd48f5a8ec28f8328af481
> 702854 152 drwxr-xr-x 2 kudu kudu 110592 Jan 23 16:59
> /data/1/kudu/tablet/data/data
> 15456410 -rw-r--r-- 1 kudu kudu 10743091200 Jan 9 13:06
> /data/1/kudu/tablet/data/data/bdf6d87c2ba34d598327b0b9e159a5ea.data
> 7056904 -rw--- 1 kudu kudu 990 Jun 21 2016
> /data/1/kudu/tablet/data/data/block_manager_instance
> 278147 652 -rw-r--r-- 1 kudu kudu 660084 Aug 15 00:09
> /data/1/kudu/tablet/data/data/3917e1185471419786f59ad72bb7ba63.metadata
> 2905870 -rw-r--r-- 1 kudu kudu 10746855424 Jan 9 13:05
> /data/1/kudu/tablet/data/data/3917e1185471419786f59ad72bb7ba63.data
> 291129 672 -rw-r--r-- 1 kudu kudu 681669 Aug 15 00:09
> /data/1/kudu/tablet/data/data/756bd793f0c24188853e096f835ba7b4.metadata
> {noformat}
> I suspect it's due to the difference of "files opened as temp files and
> renamed into place" and "files opened directly". The former have permissions
> that are even more restrictive than the umask (022), while the latter adhere
> to the umask.
> I don't know whether more restrictive or less restrictive modes should be
> used, but I don't see any reason why all files in Kudu's filesystem layout
> shouldn't have the same permissions.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (KUDU-1882) Configuration improvements for Flume Kudu Sink regexp operations producer
Mike Percy created KUDU-1882:
Summary: Configuration improvements for Flume Kudu Sink regexp
operations producer
Key: KUDU-1882
URL: https://issues.apache.org/jira/browse/KUDU-1882
Project: Kudu
Issue Type: Bug
Components: flume-sink, integration
Affects Versions: 1.2.0
Reporter: Mike Percy
The RegexpKuduOperationsProducer currently has the following configuration
options that could be improved:
||Property Name || Default || Required? || Description ||
| producer.skipMissingColumn | false | No | What to do if a column in the
Kudu table has no corresponding capture group. If set to true, a warning
message is logged and the operation is still attempted. If set to false, an
exception is thrown and the sink will not process the Event, causing a Flume
Channel rollback.|
| producer.skipBadColumnValue | false | No | What to do if a value in the
pattern match cannot be coerced to the required type. If set to true, a warning
message is logged and the operation is still attempted. If set to false, an
exception is thrown and the sink will not process the Event, causing a Flume
Channel rollback. |
| producer.warnUnmatchedRows | true | No | Whether to log a warning about
payloads that do not match the pattern. If set to false, event bodies with no
matches will be silently dropped. |
It would be an improvement if each of these concepts had the the following
options: {{warn}}, {{ignore}}, {{reject}}
Where {{warn}} would log a warning to the Flume log and continue processing,
{{ignore}} would attempt to continue processing without issuing a warning, and
{{reject}} would throw an exception.
It may be that some fields are nullable or have defaults, potentially due to an
ALTER TABLE, and we don't want to fill the Flume logs with useless warnings.
Users may also want to reject any Events that don't match their regex so they
can correct the configuration and restart Flume without losing those Events.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (KUDU-1881) Deserializing scan token should check nullability of column
[ https://issues.apache.org/jira/browse/KUDU-1881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15868519#comment-15868519 ] Dan Burkert commented on KUDU-1881: --- The missing check is here: https://github.com/apache/kudu/blob/master/src/kudu/client/scan_token-internal.cc#L91-L104. I imagine there is an equivalent missing check in the Java client as well. > Deserializing scan token should check nullability of column > --- > > Key: KUDU-1881 > URL: https://issues.apache.org/jira/browse/KUDU-1881 > Project: Kudu > Issue Type: Bug > Components: client >Affects Versions: 1.2.0 >Reporter: Matthew Jacobs >Assignee: Dan Burkert >Priority: Critical > Fix For: 1.3.0 > > > When deserializing a scan token, the projection schema must be validated > against that of the table to ensure projected columns haven't been changed. > While the data types are validated, the nullability of those columns is not. > If a column 's' with nullable=false is dropped and then add 's' with > nullable='true' (or visa-versa), clients will expect tuples to have the wrong > memory layout. Systems like Impala that memcpy the tuples directly can crash > as a result. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (KUDU-1881) Deserializing scan token should check nullability of column
[ https://issues.apache.org/jira/browse/KUDU-1881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15868509#comment-15868509 ] Todd Lipcon commented on KUDU-1881: --- When you say "deserializing a scan token", I'm not sure quite what you mean. Deserialization doesn't talk to the server, does it? Should the check be when the scanner is opened? Keep in mind that the schema could change in between when we call OpenTable and when we call Open on the scanner -- so maybe we're missing a check in that latter part? > Deserializing scan token should check nullability of column > --- > > Key: KUDU-1881 > URL: https://issues.apache.org/jira/browse/KUDU-1881 > Project: Kudu > Issue Type: Bug > Components: client >Affects Versions: 1.2.0 >Reporter: Matthew Jacobs >Assignee: Dan Burkert >Priority: Critical > Fix For: 1.3.0 > > > When deserializing a scan token, the projection schema must be validated > against that of the table to ensure projected columns haven't been changed. > While the data types are validated, the nullability of those columns is not. > If a column 's' with nullable=false is dropped and then add 's' with > nullable='true' (or visa-versa), clients will expect tuples to have the wrong > memory layout. Systems like Impala that memcpy the tuples directly can crash > as a result. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (KUDU-1881) Deserializing scan token should check nullability of column
Matthew Jacobs created KUDU-1881: Summary: Deserializing scan token should check nullability of column Key: KUDU-1881 URL: https://issues.apache.org/jira/browse/KUDU-1881 Project: Kudu Issue Type: Bug Components: client Affects Versions: 1.2.0 Reporter: Matthew Jacobs Assignee: Dan Burkert Priority: Critical Fix For: 1.3.0 When deserializing a scan token, the projection schema must be validated against that of the table to ensure projected columns haven't been changed. While the data types are validated, the nullability of those columns is not. If a column 's' with nullable=false is dropped and then add 's' with nullable='true' (or visa-versa), clients will expect tuples to have the wrong memory layout. Systems like Impala that memcpy the tuples directly can crash as a result. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (KUDU-1880) IS NULL predicates eliminate some NULL values
[ https://issues.apache.org/jira/browse/KUDU-1880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Todd Lipcon reassigned KUDU-1880: - Assignee: Andrew Wong > IS NULL predicates eliminate some NULL values > - > > Key: KUDU-1880 > URL: https://issues.apache.org/jira/browse/KUDU-1880 > Project: Kudu > Issue Type: Bug >Affects Versions: 1.3.0 >Reporter: Joe McDonnell >Assignee: Andrew Wong >Priority: Blocker > > Impala is implementing IS NULL/IS NOT NULL Kudu predicates as part of > IMPALA-4859 (see review: https://gerrit.cloudera.org/#/c/5958/ ). In testing, > Kudu IS NULL is eliminating valid NULL values from results returned. > Here is an example: > select id, float_col from functional_kudu.alltypesagg where id < 10; > | id | float_col | > | 3 | 3.29952316284 | > | 7 | 7.69809265137 | > | 0 | NULL | > | 6 | 6.59904632568 | > | 8 | 8.80190734863 | > | 9 | 9.89618530273 | > | 0 | NULL | > | 1 | 1.10023841858 | > | 2 | 2.20047683716 | > | 4 | 4.40095367432 | > | 5 | 5.5 | > Fetched 11 row(s) in 0.57s > When adding an IS NULL condition on float_col, this does not return any rows. > select id, float_col from functional_kudu.alltypesagg where id < 10 and > float_col is null; > Fetched 0 row(s) in 0.25s > This is also true for other tables, such as functional_kudu.nulltable. > select * from functional_kudu.nulltable; > | a | b | c| d| e| f | g | > | a | | NULL | NULL | NULL | ab | | > Fetched 1 row(s) in 0.49s > The following SQLs return no rows: > select * from functional_kudu.nulltable where c is null; > select * from functional_kudu.nulltable where d is null; > select * from functional_kudu.nulltable where e is null; > Impala statistics indicate that Kudu is not returning any rows. IS NOT NULL > seems to work correctly. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (KUDU-1878) Java openTable() call eagerly connects to all tablets
[ https://issues.apache.org/jira/browse/KUDU-1878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Todd Lipcon updated KUDU-1878: -- Component/s: java > Java openTable() call eagerly connects to all tablets > - > > Key: KUDU-1878 > URL: https://issues.apache.org/jira/browse/KUDU-1878 > Project: Kudu > Issue Type: Bug > Components: client, impala, java, perf >Affects Versions: 1.2.0 >Reporter: Todd Lipcon > > In a secure cluster, I noticed that every time I run an Impala query, it > issues new service tickets for every tablet server on the coordinator node. > It seems like it is creating a new connection to each tablet server, despite > not actually needing to access any data. This is probably a big part of why > planning is slow for larger clusters. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (KUDU-1877) When webserver TLS is enabled, webui links should use https
[ https://issues.apache.org/jira/browse/KUDU-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Todd Lipcon updated KUDU-1877: -- Resolution: Fixed Fix Version/s: 1.3.0 Status: Resolved (was: In Review) > When webserver TLS is enabled, webui links should use https > --- > > Key: KUDU-1877 > URL: https://issues.apache.org/jira/browse/KUDU-1877 > Project: Kudu > Issue Type: Bug > Components: security >Affects Versions: 1.3.0 >Reporter: Adar Dembo >Assignee: Todd Lipcon > Fix For: 1.3.0 > > > I noticed that when webserver TLS is enabled, the links in the masters' > /tablet-servers page still use http:// prefixing. > If there's no way to detect whether a given tserver has a TLS-enabled webui, > we could probably fall back to matching the master's configuration: if the > master is using TLS, it's likely the tservers are too. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
