[jira] [Commented] (CASSANDRA-15048) Upgrade Netty to support TLS 1.3
[
https://issues.apache.org/jira/browse/CASSANDRA-15048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17679261#comment-17679261
]
Scott Guminy commented on CASSANDRA-15048:
--
Thanks. I was able to get it to start with {_}protocol: TLSv1.3{_}. Didn't
get any errors on startup. I scanned the port with a tool and it was able to
detect TLSv1.3 correctly. Seems like it might "just work".
> 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
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15048) Upgrade Netty to support TLS 1.3
[
https://issues.apache.org/jira/browse/CASSANDRA-15048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17679177#comment-17679177
]
Scott Guminy commented on CASSANDRA-15048:
--
Soon we will have a mandate to support TLS 1.3. I see the Netty has been
upgraded to 4.1.58 in Cassandra 4.0.7. Does Cassandra officially support TLS
1.3 at this point?
> 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
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-9602) EACH_QUORUM READ support needed
[ https://issues.apache.org/jira/browse/CASSANDRA-9602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14619137#comment-14619137 ] Scott Guminy commented on CASSANDRA-9602: - Thanks [~mshuler] what's the timeline for 3.0? > EACH_QUORUM READ support needed > --- > > Key: CASSANDRA-9602 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9602 > Project: Cassandra > Issue Type: Improvement >Reporter: Scott Guminy >Assignee: Tyler Hobbs > Fix For: 3.x > > > EACH_QUORUM consistency for READ should be added. > This bug https://issues.apache.org/jira/browse/CASSANDRA-3272 says it is not > needed ever, however I have a use case where I need it. I think the decision > made was incorrect. Here's why... > > My application has two key pieces: > > # *End user actions* which add/modify data in the system. End users > typically access the application from only one Data Center and only see their > own data > # *Scheduled business logic tasks* which run from any node in any data > center. These tasks process data added by the end users in an asynchronous > way > > *End user actions must have the highest degree of availability.* Users must > always be able to add data to the system. The data will be processed later. > To support this, end user actions will use *LOCAL_QUORUM Read and Write > Consistency*. > > Scheduled tasks don't need to have a high degree of availability but MUST > operate on the most up to date data. *The tasks will run with EACH_QUORUM* > to ensure that no matter how many data centers we have, we always READ the > latest data. This approach allows us some amount of fault tolerance. > > The problem is that EACH_QUORUM is not a valid READ consistency level. This > mean I have no alternative but to use ALL. ALL will work, but is not the > best since it offers support for ZERO failures. I would prefer EACH_QUORUM > since it can support some failures in each data center. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9602) EACH_QUORUM READ support needed
[ https://issues.apache.org/jira/browse/CASSANDRA-9602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14618947#comment-14618947 ] Scott Guminy commented on CASSANDRA-9602: - Ideally I'd like this in 2.0.15 since I have an immediate need for it there (in the next month). > EACH_QUORUM READ support needed > --- > > Key: CASSANDRA-9602 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9602 > Project: Cassandra > Issue Type: Improvement >Reporter: Scott Guminy >Assignee: Tyler Hobbs > Fix For: 3.x > > > EACH_QUORUM consistency for READ should be added. > This bug https://issues.apache.org/jira/browse/CASSANDRA-3272 says it is not > needed ever, however I have a use case where I need it. I think the decision > made was incorrect. Here's why... > > My application has two key pieces: > > # *End user actions* which add/modify data in the system. End users > typically access the application from only one Data Center and only see their > own data > # *Scheduled business logic tasks* which run from any node in any data > center. These tasks process data added by the end users in an asynchronous > way > > *End user actions must have the highest degree of availability.* Users must > always be able to add data to the system. The data will be processed later. > To support this, end user actions will use *LOCAL_QUORUM Read and Write > Consistency*. > > Scheduled tasks don't need to have a high degree of availability but MUST > operate on the most up to date data. *The tasks will run with EACH_QUORUM* > to ensure that no matter how many data centers we have, we always READ the > latest data. This approach allows us some amount of fault tolerance. > > The problem is that EACH_QUORUM is not a valid READ consistency level. This > mean I have no alternative but to use ALL. ALL will work, but is not the > best since it offers support for ZERO failures. I would prefer EACH_QUORUM > since it can support some failures in each data center. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-9602) EACH_QUORUM READ support needed
[ https://issues.apache.org/jira/browse/CASSANDRA-9602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Guminy updated CASSANDRA-9602: Description: EACH_QUORUM consistency for READ should be added. This bug https://issues.apache.org/jira/browse/CASSANDRA-3272 says it is not needed ever, however I have a use case where I need it. I think the decision made was incorrect. Here's why... My application has two key pieces: # *End user actions* which add/modify data in the system. End users typically access the application from only one Data Center and only see their own data # *Scheduled business logic tasks* which run from any node in any data center. These tasks process data added by the end users in an asynchronous way *End user actions must have the highest degree of availability.* Users must always be able to add data to the system. The data will be processed later. To support this, end user actions will use *LOCAL_QUORUM Read and Write Consistency*. Scheduled tasks don't need to have a high degree of availability but MUST operate on the most up to date data. *The tasks will run with EACH_QUORUM* to ensure that no matter how many data centers we have, we always READ the latest data. This approach allows us some amount of fault tolerance. The problem is that EACH_QUORUM is not a valid READ consistency level. This mean I have no alternative but to use ALL. ALL will work, but is not the best since it offers support for ZERO failures. I would prefer EACH_QUORUM since it can support some failures in each data center. was: EACH_QUORUM consistency for READ should be added. This bug https://issues.apache.org/jira/browse/CASSANDRA-3272 says it is not needed ever, however I have a use case where I need it. I think the decision made in this defect is incorrect. Here's why... My application has two key pieces: # *End user actions* which add/modify data in the system. End users typically access the application from only one Data Center and only see their own data # *Scheduled business logic tasks* which run from any node in any data center. These tasks process data added by the end users in an asynchronous way *End user actions must have the highest degree of availability.* Users must always be able to add data to the system. The data will be processed later. To support this, end user actions will use *LOCAL_QUORUM Read and Write Consistency*. Scheduled tasks don't need to have a high degree of availability but MUST operate on the most up to date data. *The tasks will run with EACH_QUORUM* to ensure that no matter how many data centers we have, we always READ the latest data. This approach allows us some amount of fault tolerance. The problem is that EACH_QUORUM is not a valid READ consistency level. This mean I have no alternative but to use ALL. ALL will work, but is not the best since it offers support for ZERO failures. I would prefer EACH_QUORUM since it can support some failures in each data center. > EACH_QUORUM READ support needed > --- > > Key: CASSANDRA-9602 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9602 > Project: Cassandra > Issue Type: Bug >Reporter: Scott Guminy > > EACH_QUORUM consistency for READ should be added. > This bug https://issues.apache.org/jira/browse/CASSANDRA-3272 says it is not > needed ever, however I have a use case where I need it. I think the decision > made was incorrect. Here's why... > > My application has two key pieces: > > # *End user actions* which add/modify data in the system. End users > typically access the application from only one Data Center and only see their > own data > # *Scheduled business logic tasks* which run from any node in any data > center. These tasks process data added by the end users in an asynchronous > way > > *End user actions must have the highest degree of availability.* Users must > always be able to add data to the system. The data will be processed later. > To support this, end user actions will use *LOCAL_QUORUM Read and Write > Consistency*. > > Scheduled tasks don't need to have a high degree of availability but MUST > operate on the most up to date data. *The tasks will run with EACH_QUORUM* > to ensure that no matter how many data centers we have, we always READ the > latest data. This approach allows us some amount of fault tolerance. > > The problem is that EACH_QUORUM is not a valid READ consistency level. This > mean I have no alternative but to use ALL. ALL will work, but is not the > best since it offers support for ZERO failures. I would prefer EACH_QUORUM > since it can support some failures in each data center. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-9602) EACH_QUORUM READ support needed
Scott Guminy created CASSANDRA-9602: --- Summary: EACH_QUORUM READ support needed Key: CASSANDRA-9602 URL: https://issues.apache.org/jira/browse/CASSANDRA-9602 Project: Cassandra Issue Type: Bug Reporter: Scott Guminy EACH_QUORUM consistency for READ should be added. This bug https://issues.apache.org/jira/browse/CASSANDRA-3272 says it is not needed ever, however I have a use case where I need it. I think the decision made in this defect is incorrect. Here's why... My application has two key pieces: # *End user actions* which add/modify data in the system. End users typically access the application from only one Data Center and only see their own data # *Scheduled business logic tasks* which run from any node in any data center. These tasks process data added by the end users in an asynchronous way *End user actions must have the highest degree of availability.* Users must always be able to add data to the system. The data will be processed later. To support this, end user actions will use *LOCAL_QUORUM Read and Write Consistency*. Scheduled tasks don't need to have a high degree of availability but MUST operate on the most up to date data. *The tasks will run with EACH_QUORUM* to ensure that no matter how many data centers we have, we always READ the latest data. This approach allows us some amount of fault tolerance. The problem is that EACH_QUORUM is not a valid READ consistency level. This mean I have no alternative but to use ALL. ALL will work, but is not the best since it offers support for ZERO failures. I would prefer EACH_QUORUM since it can support some failures in each data center. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
