[jira] [Commented] (CASSANDRA-15103) Add Failure Detection Documentation
[ https://issues.apache.org/jira/browse/CASSANDRA-15103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16856158#comment-16856158 ] Jeremy Hanna commented on CASSANDRA-15103: -- Perhaps we could put a reference to the phi accrual paper as a footnote or something like that - http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.80.7427=rep1=pdf ? > Add Failure Detection Documentation > --- > > Key: CASSANDRA-15103 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15103 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Elijah Augustin >Assignee: Elijah Augustin >Priority: Normal > Labels: documentation, pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > Topics/Concepts To Cover > * Why Failure Detection is needed and used > * State tracking with Gossip > * Typical Reasons for Node Failure -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15122) cqlshrc ssl userkey and ssl usercert cannot be encrypted
[ https://issues.apache.org/jira/browse/CASSANDRA-15122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Hanna updated CASSANDRA-15122: - Component/s: Feature/Encryption > cqlshrc ssl userkey and ssl usercert cannot be encrypted > > > Key: CASSANDRA-15122 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15122 > Project: Cassandra > Issue Type: Bug > Components: Feature/Encryption >Reporter: seaside >Priority: Normal > > cqlshrc ssl userkey and ssl usercert is provided when require_client_auth = > true，but I did not find a way to encrypt the certificate file? -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15127) Add compression performance metrics
[ https://issues.apache.org/jira/browse/CASSANDRA-15127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Hanna updated CASSANDRA-15127: - Component/s: Feature/Compression > Add compression performance metrics > --- > > Key: CASSANDRA-15127 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15127 > Project: Cassandra > Issue Type: Task > Components: Feature/Compression, Observability/Metrics >Reporter: Michael >Priority: Normal > > When doing some bulk load into my cluster I notice almost 100% CPU usage. > As I am using DeflateCompressor, I assume that the data > compression/decompression contributes a lot to overall CPU load. > Unfortunately cassandra doesn't seem to have any metrics explaining how much > CPU time has been required for that. > So I guess it would be useful to introduce cumulative times for compression > and decompression, breaking down by each supported compression algorithm. > Then by comparing how much does each specific value increase per minute, with > number of processed requests and their cumulative times, it would be easy to > conclude how costly is the compression. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15146) Transitional TLS server configuration options are overly complex
[
https://issues.apache.org/jira/browse/CASSANDRA-15146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeremy Hanna updated CASSANDRA-15146:
-
Component/s: Feature/Encryption
> Transitional TLS server configuration options are overly complex
>
>
> Key: CASSANDRA-15146
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15146
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Encryption, Local/Config
>Reporter: Joseph Lynch
>Assignee: Joseph Lynch
>Priority: Normal
>
> It appears as part of the port from transitional client TLS to transitional
> server TLS in CASSANDRA-10404 (the ability to switch a cluster to using
> {{internode_encryption}} without listening on two ports and without downtime)
> we carried the {{enabled}} setting over from the client implementation. I
> believe that the {{enabled}} option is redundant to {{internode_encryption}}
> and {{optional}} and it should therefore be removed prior to the 4.0 release
> where we will have to start respecting that interface.
> Current trunk yaml:
> {noformat}
> server_encryption_options:
>
> # set to true for allowing secure incoming connections
>
> enabled: false
>
> # If enabled and optional are both set to true, encrypted and unencrypted
> connections are handled on the storage_port
> optional: false
>
>
>
>
> # if enabled, will open up an encrypted listening socket on
> ssl_storage_port. Should be used
> # during upgrade to 4.0; otherwise, set to false.
>
> enable_legacy_ssl_storage_port: false
>
> # on outbound connections, determine which type of peers to securely
> connect to. 'enabled' must be set to true.
> internode_encryption: none
>
> keystore: conf/.keystore
>
> keystore_password: cassandra
>
> truststore: conf/.truststore
>
> truststore_password: cassandra
> {noformat}
> I propose we eliminate {{enabled}} and just use {{optional}} and
> {{internode_encryption}} to determine the listener setup. I also propose we
> change the default of {{optional}} to true. We could also re-name
> {{optional}} since it's a new option but I think it's good to stay consistent
> with the client and use {{optional}}.
> ||optional||internode_encryption||description||
> |true|none|(default) No encryption is used but if a server reaches out with
> it we'll use it|
> |false|dc|Encryption is required for inter-dc communication, but not intra-dc|
> |false|all|Encryption is required for all communication|
> |false|none|We only listen for unencrypted connections|
> |true|dc|Encryption is used for inter-dc communication but is not required|
> |true|all|Encryption is used for all communication but is not required|
> From these states it is clear when we should be accepting TLS connections
> (all except for false and none) as well as when we must enforce it.
> To transition without downtime from an un-encrypted cluster to an encrypted
> cluster the user would do the following:
> 1. After adding valid truststores, change {{internode_encryption}} to the
> desired level of encryption (recommended {{all}}) and restart Cassandra
> 2. Change {{optional=false}} and restart Cassandra to enforce #1
> If {{optional}} defaulted to {{false}} as it does right now we'd need a third
> restart to first change {{optional}} to {{true}}, which given my
> understanding of the OptionalSslHandler isn't really relevant.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15150) Update the contact us/community page to point to Slack rather than IRC
[ https://issues.apache.org/jira/browse/CASSANDRA-15150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Hanna updated CASSANDRA-15150: - Test and Documentation Plan: Perhaps just double check that the link works and there aren't any typos. Status: Patch Available (was: Open) > Update the contact us/community page to point to Slack rather than IRC > -- > > Key: CASSANDRA-15150 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15150 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: Jeremy Hanna >Assignee: Jeremy Hanna >Priority: Low > Attachments: CASSANDRA-15150.txt > > > Update the contact us/community page to point to ASF Slack rather than IRC. > We can remove cassandra-builds. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15150) Update the contact us/community page to point to Slack rather than IRC
[ https://issues.apache.org/jira/browse/CASSANDRA-15150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Hanna updated CASSANDRA-15150: - Attachment: CASSANDRA-15150.txt > Update the contact us/community page to point to Slack rather than IRC > -- > > Key: CASSANDRA-15150 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15150 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: Jeremy Hanna >Assignee: Jeremy Hanna >Priority: Low > Attachments: CASSANDRA-15150.txt > > > Update the contact us/community page to point to ASF Slack rather than IRC. > We can remove cassandra-builds. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15150) Update the contact us/community page to point to Slack rather than IRC
[ https://issues.apache.org/jira/browse/CASSANDRA-15150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Hanna updated CASSANDRA-15150: - Complexity: Low Hanging Fruit Change Category: Semantic Status: Open (was: Triage Needed) > Update the contact us/community page to point to Slack rather than IRC > -- > > Key: CASSANDRA-15150 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15150 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: Jeremy Hanna >Assignee: Jeremy Hanna >Priority: Low > Attachments: CASSANDRA-15150.txt > > > Update the contact us/community page to point to ASF Slack rather than IRC. > We can remove cassandra-builds. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15150) Update the contact us/community page to point to Slack rather than IRC
[ https://issues.apache.org/jira/browse/CASSANDRA-15150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Hanna updated CASSANDRA-15150: - Priority: Low (was: Normal) > Update the contact us/community page to point to Slack rather than IRC > -- > > Key: CASSANDRA-15150 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15150 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: Jeremy Hanna >Assignee: Jeremy Hanna >Priority: Low > > Update the contact us/community page to point to ASF Slack rather than IRC. > We can remove cassandra-builds. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-15150) Update the contact us/community page to point to Slack rather than IRC
Jeremy Hanna created CASSANDRA-15150: Summary: Update the contact us/community page to point to Slack rather than IRC Key: CASSANDRA-15150 URL: https://issues.apache.org/jira/browse/CASSANDRA-15150 Project: Cassandra Issue Type: Improvement Components: Documentation/Website Reporter: Jeremy Hanna Assignee: Jeremy Hanna Update the contact us/community page to point to ASF Slack rather than IRC. We can remove cassandra-builds. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15071) Materialized View Inconsistent With Base Table Update After Migrating To New DC
[ https://issues.apache.org/jira/browse/CASSANDRA-15071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Hanna updated CASSANDRA-15071: - Description: We've recently completed a successful migration between two data centers in our Cassandra cluster. After adding the new DC nodes onto the existing cluster, and setting the keyspaces to replicate to both DCs and rebuilding the new DC nodes from the old one, we've cut-over the applications using those keyspaces o start using the new DC exclusively by connecting to its end-points and performing `LOCAL_` consistency level requests there (DCAwareRoundRobinPolicy on LOCAL DC). We noticed that once the apps started to read data from the materialized views in the new DC, that an inconsistency emerged, which wasn't there in the original DC from which we've migrated. I.e - source/old DC had the materialized view reflecting the column update on the base table, while target/new DC didn't (the column value in the MV remained the same as it was in the base table, prior to the update). We only found out about it being logged with a support ticket, and for now, mitigated it by simply recreating the materialized view. Looking for a root cause for such behavior, is this expected, is this somewhat of a requirement which wasn't fulfilled yet for the MV mechanism, such as the ones mentioned in CASSANDRA-13826? Thanks, Avi K was: We've recently completed a successful migration between two data centers in our Cassandra cluster. After adding the new DC nodes onto the existing cluster, and setting the keyspaces to replicate to both DCs and rebuilding the new DC nodes from the old one, we've cut-over the applications using those keyspaces o start using the new DC exclusively by connecting to its end-points and performing `LOCAL_` consistency level requests there (DCAwareRoundRobinPolicy on LOCAL DC). We noticed that once the apps started to read data from the materialized views in the new DC, that an inconsistency emerged, which wasn't there in the original DC from which we've migrated. I.e - source/old DC had the materialized view reflecting the column update on the base table, while target/new DC didn't (the column value in the MV remained the same as it was in the base table, prior to the update). We only found out about it being logged with a support ticket, and for now, mitigated it by simply recreating the materialized view. Looking for a root cause for such behavior, is this expected, is this somewhat of a requirement which wasn't fulfilled yet for the MV mechanism, such as the ones mentioned in https://issues.apache.org/jira/browse/CASSANDRA-13826? Thanks, Avi K > Materialized View Inconsistent With Base Table Update After Migrating To New > DC > --- > > Key: CASSANDRA-15071 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15071 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Bootstrap and Decommission, > Feature/Materialized Views >Reporter: Avraham Kalvo >Priority: High > Labels: cassandra, materializedviews, rebuilding > > We've recently completed a successful migration between two data centers in > our Cassandra cluster. > After adding the new DC nodes onto the existing cluster, and setting the > keyspaces to replicate to both DCs and rebuilding the new DC nodes from the > old one, we've cut-over the applications using those keyspaces o start using > the new DC exclusively by connecting to its end-points and performing > `LOCAL_` consistency level requests there (DCAwareRoundRobinPolicy on LOCAL > DC). > We noticed that once the apps started to read data from the materialized > views in the new DC, that an inconsistency emerged, which wasn't there in the > original DC from which we've migrated. > I.e - source/old DC had the materialized view reflecting the column update on > the base table, while target/new DC didn't (the column value in the MV > remained the same as it was in the base table, prior to the update). > We only found out about it being logged with a support ticket, and for now, > mitigated it by simply recreating the materialized view. > Looking for a root cause for such behavior, is this expected, is this > somewhat of a requirement which wasn't fulfilled yet for the MV mechanism, > such as the ones mentioned in CASSANDRA-13826? > Thanks, > Avi K -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15095) Split Gossiper into separate interfaces
[ https://issues.apache.org/jira/browse/CASSANDRA-15095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Hanna updated CASSANDRA-15095: - Component/s: Cluster/Gossip > Split Gossiper into separate interfaces > --- > > Key: CASSANDRA-15095 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15095 > Project: Cassandra > Issue Type: Improvement > Components: Cluster/Gossip >Reporter: Blake Eggleston >Priority: Normal > > As [~aweisberg] suggests > [here|https://issues.apache.org/jira/browse/CASSANDRA-15059?focusedCommentId=16802986=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16802986], > a better way to encourage Gossiper threadsafety would be to split it into > interfaces depending on which methods are safe to be called from where. At > minimum, one for outside the gossiper stage, on for inside. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15071) Materialized View Inconsistent With Base Table Update After Migrating To New DC
[ https://issues.apache.org/jira/browse/CASSANDRA-15071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Hanna updated CASSANDRA-15071: - Component/s: Feature/Materialized Views > Materialized View Inconsistent With Base Table Update After Migrating To New > DC > --- > > Key: CASSANDRA-15071 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15071 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Bootstrap and Decommission, > Feature/Materialized Views >Reporter: Avraham Kalvo >Priority: High > Labels: cassandra, materializedviews, rebuilding > > We've recently completed a successful migration between two data centers in > our Cassandra cluster. > After adding the new DC nodes onto the existing cluster, and setting the > keyspaces to replicate to both DCs and rebuilding the new DC nodes from the > old one, we've cut-over the applications using those keyspaces o start using > the new DC exclusively by connecting to its end-points and performing > `LOCAL_` consistency level requests there (DCAwareRoundRobinPolicy on LOCAL > DC). > We noticed that once the apps started to read data from the materialized > views in the new DC, that an inconsistency emerged, which wasn't there in the > original DC from which we've migrated. > I.e - source/old DC had the materialized view reflecting the column update on > the base table, while target/new DC didn't (the column value in the MV > remained the same as it was in the base table, prior to the update). > We only found out about it being logged with a support ticket, and for now, > mitigated it by simply recreating the materialized view. > Looking for a root cause for such behavior, is this expected, is this > somewhat of a requirement which wasn't fulfilled yet for the MV mechanism, > such as the ones mentioned in > https://issues.apache.org/jira/browse/CASSANDRA-13826? > Thanks, > Avi K -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15082) SASI SPARSE mode 5 limit
[ https://issues.apache.org/jira/browse/CASSANDRA-15082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Hanna updated CASSANDRA-15082: - Component/s: Feature/SASI > SASI SPARSE mode 5 limit > > > Key: CASSANDRA-15082 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15082 > Project: Cassandra > Issue Type: Improvement > Components: Feature/SASI >Reporter: Edward Capriolo >Priority: Normal > > I do not know what the "improvement" should be here, but I ran into this: > [https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/index/sasi/disk/OnDiskIndexBuilder.java#L585] > Term '55.3' belongs to more than 5 keys in sparse mode, which is not allowed. > The only reference I can find to the limit is here: > [http://www.doanduyhai.com/blog/?p=2058] > Why is it 5? Could it be a variable? Could it be an option when creating the > table? Why or why not? > This seems awkward. A user can insert more then 5 rows into a table, and it > "works". IE you can write and you can query that table getting more than 5 > results, but the index will not flush to disk. It throws an IOException. > Maybe I am misunderstanding, but this seems impossible to support, if users > inserts the same value 5 times, the entire index will not flush to disk? -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15149) Change the text and link for low hanging fruit tickets to include the LHF ticket complexity
[ https://issues.apache.org/jira/browse/CASSANDRA-15149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Hanna updated CASSANDRA-15149: - Test and Documentation Plan: Just double check the doc change. (was: Simple patch to change the text/link.) > Change the text and link for low hanging fruit tickets to include the LHF > ticket complexity > --- > > Key: CASSANDRA-15149 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15149 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: Jeremy Hanna >Assignee: Jeremy Hanna >Priority: Normal > Attachments: CASSANDRA-15149.txt > > > Right now in the docs for how to contribute, it points to the lhf (low > hanging fruit) label which is how things were marked before the Jira flow > evolution. We should note the complexity field in there and include both the > label and the complexity field in the associated link. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15149) Change the text and link for low hanging fruit tickets to include the LHF ticket complexity
[ https://issues.apache.org/jira/browse/CASSANDRA-15149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Hanna updated CASSANDRA-15149: - Test and Documentation Plan: Simple patch to change the text/link. Status: Patch Available (was: Open) > Change the text and link for low hanging fruit tickets to include the LHF > ticket complexity > --- > > Key: CASSANDRA-15149 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15149 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: Jeremy Hanna >Assignee: Jeremy Hanna >Priority: Normal > Attachments: CASSANDRA-15149.txt > > > Right now in the docs for how to contribute, it points to the lhf (low > hanging fruit) label which is how things were marked before the Jira flow > evolution. We should note the complexity field in there and include both the > label and the complexity field in the associated link. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15149) Change the text and link for low hanging fruit tickets to include the LHF ticket complexity
[ https://issues.apache.org/jira/browse/CASSANDRA-15149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Hanna updated CASSANDRA-15149: - Complexity: Low Hanging Fruit Change Category: Semantic Status: Open (was: Triage Needed) > Change the text and link for low hanging fruit tickets to include the LHF > ticket complexity > --- > > Key: CASSANDRA-15149 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15149 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: Jeremy Hanna >Assignee: Jeremy Hanna >Priority: Normal > Attachments: CASSANDRA-15149.txt > > > Right now in the docs for how to contribute, it points to the lhf (low > hanging fruit) label which is how things were marked before the Jira flow > evolution. We should note the complexity field in there and include both the > label and the complexity field in the associated link. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15149) Change the text and link for low hanging fruit tickets to include the LHF ticket complexity
[ https://issues.apache.org/jira/browse/CASSANDRA-15149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Hanna updated CASSANDRA-15149: - Status: Triage Needed (was: Awaiting Feedback) > Change the text and link for low hanging fruit tickets to include the LHF > ticket complexity > --- > > Key: CASSANDRA-15149 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15149 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: Jeremy Hanna >Assignee: Jeremy Hanna >Priority: Normal > Attachments: CASSANDRA-15149.txt > > > Right now in the docs for how to contribute, it points to the lhf (low > hanging fruit) label which is how things were marked before the Jira flow > evolution. We should note the complexity field in there and include both the > label and the complexity field in the associated link. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15149) Change the text and link for low hanging fruit tickets to include the LHF ticket complexity
[ https://issues.apache.org/jira/browse/CASSANDRA-15149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Hanna updated CASSANDRA-15149: - Status: Awaiting Feedback (was: Triage Needed) > Change the text and link for low hanging fruit tickets to include the LHF > ticket complexity > --- > > Key: CASSANDRA-15149 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15149 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: Jeremy Hanna >Assignee: Jeremy Hanna >Priority: Normal > Attachments: CASSANDRA-15149.txt > > > Right now in the docs for how to contribute, it points to the lhf (low > hanging fruit) label which is how things were marked before the Jira flow > evolution. We should note the complexity field in there and include both the > label and the complexity field in the associated link. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15149) Change the text and link for low hanging fruit tickets to include the LHF ticket complexity
[ https://issues.apache.org/jira/browse/CASSANDRA-15149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Hanna updated CASSANDRA-15149: - Attachment: (was: CASSANDRA-15149.txt) > Change the text and link for low hanging fruit tickets to include the LHF > ticket complexity > --- > > Key: CASSANDRA-15149 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15149 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: Jeremy Hanna >Assignee: Jeremy Hanna >Priority: Normal > Attachments: CASSANDRA-15149.txt > > > Right now in the docs for how to contribute, it points to the lhf (low > hanging fruit) label which is how things were marked before the Jira flow > evolution. We should note the complexity field in there and include both the > label and the complexity field in the associated link. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15149) Change the text and link for low hanging fruit tickets to include the LHF ticket complexity
[ https://issues.apache.org/jira/browse/CASSANDRA-15149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Hanna updated CASSANDRA-15149: - Attachment: CASSANDRA-15149.txt > Change the text and link for low hanging fruit tickets to include the LHF > ticket complexity > --- > > Key: CASSANDRA-15149 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15149 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: Jeremy Hanna >Assignee: Jeremy Hanna >Priority: Normal > Attachments: CASSANDRA-15149.txt > > > Right now in the docs for how to contribute, it points to the lhf (low > hanging fruit) label which is how things were marked before the Jira flow > evolution. We should note the complexity field in there and include both the > label and the complexity field in the associated link. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-15149) Change the text and link for low hanging fruit tickets to include the LHF ticket complexity
[ https://issues.apache.org/jira/browse/CASSANDRA-15149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Hanna reassigned CASSANDRA-15149: Assignee: Jeremy Hanna > Change the text and link for low hanging fruit tickets to include the LHF > ticket complexity > --- > > Key: CASSANDRA-15149 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15149 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: Jeremy Hanna >Assignee: Jeremy Hanna >Priority: Normal > Attachments: CASSANDRA-15149.txt > > > Right now in the docs for how to contribute, it points to the lhf (low > hanging fruit) label which is how things were marked before the Jira flow > evolution. We should note the complexity field in there and include both the > label and the complexity field in the associated link. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15149) Change the text and link for low hanging fruit tickets to include the LHF ticket complexity
[ https://issues.apache.org/jira/browse/CASSANDRA-15149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Hanna updated CASSANDRA-15149: - Attachment: CASSANDRA-15149.txt > Change the text and link for low hanging fruit tickets to include the LHF > ticket complexity > --- > > Key: CASSANDRA-15149 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15149 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: Jeremy Hanna >Assignee: Jeremy Hanna >Priority: Normal > Attachments: CASSANDRA-15149.txt > > > Right now in the docs for how to contribute, it points to the lhf (low > hanging fruit) label which is how things were marked before the Jira flow > evolution. We should note the complexity field in there and include both the > label and the complexity field in the associated link. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-15149) Change the text and link for low hanging fruit tickets to include the LHF ticket complexity
Jeremy Hanna created CASSANDRA-15149: Summary: Change the text and link for low hanging fruit tickets to include the LHF ticket complexity Key: CASSANDRA-15149 URL: https://issues.apache.org/jira/browse/CASSANDRA-15149 Project: Cassandra Issue Type: Improvement Components: Documentation/Website Reporter: Jeremy Hanna Right now in the docs for how to contribute, it points to the lhf (low hanging fruit) label which is how things were marked before the Jira flow evolution. We should note the complexity field in there and include both the label and the complexity field in the associated link. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15046) Add a "history" command to cqlsh. Perhaps "show history"?
[ https://issues.apache.org/jira/browse/CASSANDRA-15046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Hanna updated CASSANDRA-15046: - Complexity: Low Hanging Fruit > Add a "history" command to cqlsh. Perhaps "show history"? > -- > > Key: CASSANDRA-15046 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15046 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter >Reporter: Wes Peters >Priority: Low > Labels: lhf > > I was trying to capture some create key space and create table commands from > a running cqlsh, and found there was no equivalent to the '\s' history > command in Postgres' psql shell. It's a great tool for figuring out what you > were doing yesterday. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15048) Upgrade Netty to support TLS 1.3
[
https://issues.apache.org/jira/browse/CASSANDRA-15048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeremy Hanna updated CASSANDRA-15048:
-
Component/s: Feature/Encryption
> Upgrade Netty to support TLS 1.3
>
>
> Key: CASSANDRA-15048
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15048
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption
>Reporter: Michaël Figuière
>Priority: Low
>
> TLS 1.3 support has been [added to Netty
> 4.1.31|https://netty.io/news/2018/10/30/4-1-31-Final.html]. As the Cassandra
> trunk is already relying on Netty 4.1.28, it would take a patch version
> upgrade and a \{{SslContext}} configuration change for Cassandra 4.0 to
> support TLS 1.3.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15046) Add a "history" command to cqlsh. Perhaps "show history"?
[ https://issues.apache.org/jira/browse/CASSANDRA-15046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Hanna updated CASSANDRA-15046: - Labels: lhf (was: ) > Add a "history" command to cqlsh. Perhaps "show history"? > -- > > Key: CASSANDRA-15046 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15046 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter >Reporter: Wes Peters >Priority: Low > Labels: lhf > > I was trying to capture some create key space and create table commands from > a running cqlsh, and found there was no equivalent to the '\s' history > command in Postgres' psql shell. It's a great tool for figuring out what you > were doing yesterday. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14305) Use $CASSANDRA_CONF not $CASSANDRA_HOME/conf in cassandra-env.sh
[ https://issues.apache.org/jira/browse/CASSANDRA-14305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mck updated CASSANDRA-14305: Test and Documentation Plan: manual testing dtest: mx_auth_test.TestJMXAuth.test_basic_auth was:manual testing Status: Patch Available (was: Open) > Use $CASSANDRA_CONF not $CASSANDRA_HOME/conf in cassandra-env.sh > - > > Key: CASSANDRA-14305 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14305 > Project: Cassandra > Issue Type: Improvement > Components: Local/Config >Reporter: Angelo Polo >Assignee: Angelo Polo >Priority: Low > Labels: pull-request-available > Fix For: 3.11.5, 4.0 > > Attachments: conf_cassandra-env.sh.patch > > Time Spent: 10m > Remaining Estimate: 0h > > CASSANDRA_CONF should be used uniformly in conf/cassandra-env.sh to reference > the configuration path. Currently, jaas users will have to modify the default > path provided for cassandra-jaas.config if their $CASSANDRA_CONF differs from > $CASSANDRA_HOME/conf. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14305) Use $CASSANDRA_CONF not $CASSANDRA_HOME/conf in cassandra-env.sh
[ https://issues.apache.org/jira/browse/CASSANDRA-14305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16855405#comment-16855405 ] mck commented on CASSANDRA-14305: - Fix is in https://github.com/apache/cassandra-dtest/pull/51 dtest run at https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/673/ > Use $CASSANDRA_CONF not $CASSANDRA_HOME/conf in cassandra-env.sh > - > > Key: CASSANDRA-14305 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14305 > Project: Cassandra > Issue Type: Improvement > Components: Local/Config >Reporter: Angelo Polo >Assignee: Angelo Polo >Priority: Low > Labels: pull-request-available > Fix For: 3.11.5, 4.0 > > Attachments: conf_cassandra-env.sh.patch > > Time Spent: 10m > Remaining Estimate: 0h > > CASSANDRA_CONF should be used uniformly in conf/cassandra-env.sh to reference > the configuration path. Currently, jaas users will have to modify the default > path provided for cassandra-jaas.config if their $CASSANDRA_CONF differs from > $CASSANDRA_HOME/conf. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14305) Use $CASSANDRA_CONF not $CASSANDRA_HOME/conf in cassandra-env.sh
[ https://issues.apache.org/jira/browse/CASSANDRA-14305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CASSANDRA-14305: --- Labels: pull-request-available (was: ) > Use $CASSANDRA_CONF not $CASSANDRA_HOME/conf in cassandra-env.sh > - > > Key: CASSANDRA-14305 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14305 > Project: Cassandra > Issue Type: Improvement > Components: Local/Config >Reporter: Angelo Polo >Assignee: Angelo Polo >Priority: Low > Labels: pull-request-available > Fix For: 3.11.5, 4.0 > > Attachments: conf_cassandra-env.sh.patch > > > CASSANDRA_CONF should be used uniformly in conf/cassandra-env.sh to reference > the configuration path. Currently, jaas users will have to modify the default > path provided for cassandra-jaas.config if their $CASSANDRA_CONF differs from > $CASSANDRA_HOME/conf. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
