[jira] [Commented] (KUDU-3207) Standardize RSA private key format
[
https://issues.apache.org/jira/browse/KUDU-3207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17281507#comment-17281507
]
Grant Henke commented on KUDU-3207:
---
I don't have a lot of background or context on the formats and encodings and
their purpose or benefits. I found this post to be super helpful for context
and sharing here in case anyone else could benefit from it:
https://stackoverflow.com/a/48960291
> Standardize RSA private key format
> --
>
> Key: KUDU-3207
> URL: https://issues.apache.org/jira/browse/KUDU-3207
> Project: Kudu
> Issue Type: Improvement
>Reporter: Attila Bukor
>Priority: Minor
> Labels: OpenSSL, security
>
> Currently, Kudu stores RSA private keys in PEM format using
> PEM_write_bio_RSAPrivateKey(), which doesn't specify the format in which the
> key is stored. It expects it to be PKCS #1 (BEGIN/END RSA PRIVATE KEY), but
> it seems there are some OpenSSL versions (CryptoComply) that use PKCS #8
> instead (BEGIN/END PRIVATE KEY). {{CryptoTest.RsaPrivateKeyInputOutputPEM}}
> fails due to this, as it compares the private key to an expected string,
> which is in PKCS #1 format. The read functions are explicitly said to handle
> any known format, so this shouldn't cause any issues, but it would still be
> nice to standardize on a single format (probably PKCS #8).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (KUDU-2181) Multi-master config change support
[ https://issues.apache.org/jira/browse/KUDU-2181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17281420#comment-17281420 ] ASF subversion and git services commented on KUDU-2181: --- Commit 3c363d499ec5c0d675d78d871712e579d966548c in kudu's branch refs/heads/master from Bankim Bhavsar [ https://gitbox.apache.org/repos/asf?p=kudu.git;h=3c363d4 ] [master] KUDU-2181 Raft ChangeConfig request to remove a master This change adds RPC to request removal of an existing master from a cluster. It builds on top of earlier change 9fc6c77 to add master. Added tests for removal of non-leader master whether it's up or down. Change-Id: I76c03b8850faef60b65f85184c0a4db7cc6759ee Reviewed-on: http://gerrit.cloudera.org:8080/16936 Reviewed-by: Alexey Serbin Tested-by: Bankim Bhavsar > Multi-master config change support > -- > > Key: KUDU-2181 > URL: https://issues.apache.org/jira/browse/KUDU-2181 > Project: Kudu > Issue Type: Improvement > Components: consensus, master >Reporter: Mike Percy >Assignee: Bankim Bhavsar >Priority: Major > Labels: roadmap-candidate > > It would be very useful to add support to the Kudu master for dynamic config > change. The current procedure for replacing a failed master is fairly arduous. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (KUDU-2490) implement Kudu DataSourceV2 and related classes
[ https://issues.apache.org/jira/browse/KUDU-2490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Henke reassigned KUDU-2490: - Assignee: Mayank Asthana (was: Grant Henke) > implement Kudu DataSourceV2 and related classes > --- > > Key: KUDU-2490 > URL: https://issues.apache.org/jira/browse/KUDU-2490 > Project: Kudu > Issue Type: Improvement > Components: spark >Reporter: Andrew Wong >Assignee: Mayank Asthana >Priority: Major > Labels: roadmap-candidate > > The current Kudu-Spark bindings implement a DefaultSource that extends a > RelationProvider, which provides BaseRelations to Spark, which, as I > understand it, are physical units of query execution and represent sets of > rows. The Kudu BaseRelation (the KuduRelation) implements a couple of traits > to fit into Spark: PrunedFilteredScan, which allows predicates to be pushed > into Kudu, and InsertableRelation, which allows writes to be pushed into > Kudu. An issue with these bindings is that, while they provide interfaces to > insert/get data, they do not provide interfaces to push details to Spark that > might be useful to optimizing a Kudu query. > Among other things, this is inconvenient for all datasources that might want > to take such optimizations into their own hands, and the Spark community > appears to be making efforts in revamping their DataSource APIs in the form > of DataSourceV2, and as it pertains to read support, the v2 DataSourceReader. > This new world order provides a clear path towards implementing various > optimizations that are currently unavailable with the current Spark bindings, > without pushing changes to Spark itself. > Of note, the v2 DataSourceReader can be extended with > SupportsReportStatistics, which could allow Kudu to expose statistics to Kudu > without having to rely on HMS (although pushing stats to HMS isn't an > unreasonable approach either). More traits and details about the API can be > found > [here|https://spark.apache.org/docs/2.3.0/api/java/org/apache/spark/sql/sources/v2/reader/DataSourceReader.html]. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (KUDU-2490) implement Kudu DataSourceV2 and related classes
[ https://issues.apache.org/jira/browse/KUDU-2490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Henke reassigned KUDU-2490: - Assignee: Grant Henke > implement Kudu DataSourceV2 and related classes > --- > > Key: KUDU-2490 > URL: https://issues.apache.org/jira/browse/KUDU-2490 > Project: Kudu > Issue Type: Improvement > Components: spark >Reporter: Andrew Wong >Assignee: Grant Henke >Priority: Major > Labels: roadmap-candidate > > The current Kudu-Spark bindings implement a DefaultSource that extends a > RelationProvider, which provides BaseRelations to Spark, which, as I > understand it, are physical units of query execution and represent sets of > rows. The Kudu BaseRelation (the KuduRelation) implements a couple of traits > to fit into Spark: PrunedFilteredScan, which allows predicates to be pushed > into Kudu, and InsertableRelation, which allows writes to be pushed into > Kudu. An issue with these bindings is that, while they provide interfaces to > insert/get data, they do not provide interfaces to push details to Spark that > might be useful to optimizing a Kudu query. > Among other things, this is inconvenient for all datasources that might want > to take such optimizations into their own hands, and the Spark community > appears to be making efforts in revamping their DataSource APIs in the form > of DataSourceV2, and as it pertains to read support, the v2 DataSourceReader. > This new world order provides a clear path towards implementing various > optimizations that are currently unavailable with the current Spark bindings, > without pushing changes to Spark itself. > Of note, the v2 DataSourceReader can be extended with > SupportsReportStatistics, which could allow Kudu to expose statistics to Kudu > without having to rely on HMS (although pushing stats to HMS isn't an > unreasonable approach either). More traits and details about the API can be > found > [here|https://spark.apache.org/docs/2.3.0/api/java/org/apache/spark/sql/sources/v2/reader/DataSourceReader.html]. -- This message was sent by Atlassian Jira (v8.3.4#803005)
