[jira] [Commented] (CASSANDRA-8110) Make streaming forward & backwards compatible
[ https://issues.apache.org/jira/browse/CASSANDRA-8110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17641705#comment-17641705 ] Yuki Morishita commented on CASSANDRA-8110: --- I'd like to propose a possible solution to achieve the goal to allow streaming in the cluster with mixed versions of nodes, which typically happens when rolling upgrading the cluster. The current consensus of the node failure during the upgrade process is to continue upgrading the cluster and perform the node replacement after the nodes are in the same version, since the streaming across the different versions are prevented/not guaranteed to work. This behavior makes a large cluster upgrade that requires high availability nearly impossible, since rolling upgrades can create downtime with failed nodes. To achieve this goal, I propose the following changes to Apache Cassandra: * Use the same (old) SSTable version in the upgraded node to write SSTables, until all the nodes in the cluster are in the same Cassandra version * SSTable version has been in gossip state (SSTABLE_VERSIONS) since CASSANDRA-15897. We can use this to determine which SSTable version to use in the upgraded node. * We need to bring back old SSTableWriter implementations or implement versioned serialization to SSTableWriter. * The nodes in the cluster can switch to a new SSTable version using Cassandra Version (RELEASE_VERSION) in gossip state. * Accept the stream from older version * Right now, the streaming protocol version needs to be the same in sender and receiver. We need to relax this constraint. These two can be worked on separately. SSTable version fixation alone can allow mixed version streaming using the *current* streaming protocol version. For example, if SSTable version is updated with this feature in 5.0, and still use the same streaming protocol version, Cassandra 4.0/4.1 and 5.0 can still perform streaming (forward compatibility). If we want to extend this feature to older versions of Cassandra (backward compatibility), we need to add a streaming protocol compatible layer to understand previous versions of streaming protocol (if any). I'd like to hear opinions about this approach from the community, and if it seems feasible, I'd like to start implementing this change. > Make streaming forward & backwards compatible > - > > Key: CASSANDRA-8110 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8110 > Project: Cassandra > Issue Type: New Feature > Components: Legacy/Streaming and Messaging >Reporter: Marcus Eriksson >Priority: Normal > Labels: gsoc2016, mentor > > To be able to seamlessly upgrade clusters we need to make it possible to > stream files between nodes with different StreamMessage.CURRENT_VERSION -- 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-18023) Add option to print level with getsstables output
[ https://issues.apache.org/jira/browse/CASSANDRA-18023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17641621#comment-17641621 ] Jordan West commented on CASSANDRA-18023: - Tests on the most recent trunk: [j8|https://app.circleci.com/pipelines/github/jrwest/cassandra/122/workflows/b510c3f0-3d15-40a5-b377-dd4671fbc534] [j11|https://app.circleci.com/pipelines/github/jrwest/cassandra/122/workflows/ad1cab37-a8f5-48b7-8c30-099e9a33dad6] Still a few failures that I don't believe are related / due to flaky tests. > Add option to print level with getsstables output > - > > Key: CASSANDRA-18023 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18023 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Jordan West >Assignee: Jordan West >Priority: Normal > > A common operation is to pipe getsstables output to sstablemetadata to > determine the level. This adds friction to operations. Add an optional flag > to getsstables to print the level with data file path. -- 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] [Assigned] (CASSANDRA-17992) Upgrade Netty on 4.x(current trunk)
[ https://issues.apache.org/jira/browse/CASSANDRA-17992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova reassigned CASSANDRA-17992: --- Assignee: Ekaterina Dimitrova > Upgrade Netty on 4.x(current trunk) > --- > > Key: CASSANDRA-17992 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17992 > Project: Cassandra > Issue Type: Task > Components: Dependencies >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Low > Fix For: 4.x > > > I haven't been able to identify from the Netty docs which was the lowest > version where JDK17 was added but we are about 40 versions behind in netty 4 > so I suspect we better update. > We need to consider there was an issue with class cast exceptions when > building with JDK17 with newer versions of netty (the newest available in > March 2022). For the record, we didn't see those when running CI on JDK8 and > JDK11. We also need to carefully revise the changes between the netty > versions. > Upgrading will cover also a fix in netty that was discussed in > [this|https://the-asf.slack.com/archives/CK23JSY2K/p1665567660202989] ASF > Slack thread. > CC [~benedict] , [~aleksey] -- 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-17918) DESCRIBE output does not quote column names using reserved keywords
[
https://issues.apache.org/jira/browse/CASSANDRA-17918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17641586#comment-17641586
]
Bernardo Botella Corbi commented on CASSANDRA-17918:
Adding circle links
trunk:
(Java11)
https://app.circleci.com/pipelines/github/bbotella/cassandra/57/workflows/2ecb86fa-c7cb-4768-91a2-4d14657bdd0b/jobs/56
(Java8)
https://app.circleci.com/pipelines/github/bbotella/cassandra/57/workflows/680a80b7-dc28-4527-a5d9-01b87020675f/jobs/57
4.0:
(Java11)
https://app.circleci.com/pipelines/github/bbotella/cassandra/62/workflows/4a7b1b07-e65b-4220-bb46-85657f16a23c/jobs/51
(Java8)
https://app.circleci.com/pipelines/github/bbotella/cassandra/62/workflows/d8586f28-0bee-47f2-95db-ed7a7f655dfd/jobs/55
4.1:
(Java11)
https://app.circleci.com/pipelines/github/bbotella/cassandra/63/workflows/5ff4002d-3fe1-481a-8929-c7b721dcf139/jobs/50
(Java8)
https://app.circleci.com/pipelines/github/bbotella/cassandra/63/workflows/db9f99b0-0f6a-4fa2-a5c4-b0234b07c306/jobs/52
> DESCRIBE output does not quote column names using reserved keywords
> ---
>
> Key: CASSANDRA-17918
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17918
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: Yifan Cai
>Assignee: Bernardo Botella Corbi
>Priority: Normal
> Fix For: 4.0.x, 4.1.x
>
>
> The DESCRIBE output of the column names that using reserved keywords are not
> quoted for UDTs. The following test reproduces. Reading the code, it looks
> like that the such columns names are not quoted in materialized view, UDF and
> user defined aggregation.
> The impact of the bug is that schema described cannot be imported due to the
> usage of reserved keywords as column names.
>
> {code:java}
> @Test
> public void testUsingReservedInCreateType() throws Throwable
> {
> String type = createType(KEYSPACE_PER_TEST, "CREATE TYPE %s
> (\"token\" text, \"desc\" text);");
> assertRowsNet(executeDescribeNet(KEYSPACE_PER_TEST, "DESCRIBE TYPE " + type),
> row(KEYSPACE_PER_TEST, "type", type, "CREATE TYPE " +
> KEYSPACE_PER_TEST + "." + type + " (\n" +
> " \"token\" text,\n" +
> " \"desc\" text\n" +
> ");"));
> } {code}
> +Additional information for newcomers:+
> * Unit tests for DESCRIBE statements are in {{DescribeStatementTest}}
> * The statement implementation is in {{DescribeStatement and fetch the
> create statement from the different schema element using
> SchemaElement.toCqlString}}
--
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-18042) Implement a guardrail for not having zero default ttl on tables with TWCS
[
https://issues.apache.org/jira/browse/CASSANDRA-18042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17641585#comment-17641585
]
Josh McKenzie commented on CASSANDRA-18042:
---
I see it being differently vague with the _warned case:
{code}
sai_indexes_take_snapshots_warned: true
sai_indexes_take_snapshots: false
sai_indexes_warned: true
sai_indexes_enabled: false
{code}
In the above example, would we allow sai indexes and warn when used? Would we
disallow them and not warn?
Whatever form we take, if we say the warning is contingent on the feature being
enabled that's different than our other guardrails where we have an assumption
that all features are enabled but they warn and fail at certain thresholds.
This new paradigm (warning on feature flagged things) is overloading the notion
of "warned" to something who's state is _dependent_ on another configuration
option if I'm not mistaken.
So in the above example, if we're saying "sai_indexes will not be configured
and the _warned option is dead unless the _enabled is flipped", there's an
undocumented coupling between them that's also divergent from how the other
guardrails use _warn and _fail.
{code}
sai_indexes_take_snapshots_if_enabled
{code}
I wasn't advocating for this format. Only specifically for "warn_if_enabled"
for feature flags implemented through guardrails.
So, all this said: not a hill I'm willing to die on. I think we're kind of
bikeshedding between a bunch of dissatisfying options here as we try to bolt
something on to a feature (guardrails as feature flag) that was never intended
to have the notion of "optionally warn if someone takes the extra step to turn
this feature on".
> Implement a guardrail for not having zero default ttl on tables with TWCS
> -
>
> Key: CASSANDRA-18042
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18042
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Guardrails, Legacy/Core
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 3h
> Remaining Estimate: 0h
>
> A user was surprised that his data have not started to expire after 90 days
> on his TWCS, he noticed that default_time_to_live on the table was set to 0
> (by accident from his side) and inserts were using TTL = 0 too.
> It is questionable why it it possible to create a table with TWCS and enable
> a user to specify default_time_to_live to be zero.
> On the other hand, I would argue that having default_time_to_live set to 0 on
> TWCS does not necessarily mean that such combination is illegal. It is about
> people just using that with advantage very often so tables are compacted away
> nicely. However, that does not have to mean that they could not use it with
> 0. But I yet have to see a use-case where TWCS was used and default ttl was
> set to 0 on purpose. Merely looking into Cassandra codebase, there are only
> cases when this parameter is not 0.
> There are three approaches:
> 1) just reject such statements (for CreateTable and AlterTable statements)
> where default_time_to_live = 0
> 2) Implement a guardrail for 1) so it can be enabled / disabled on demand
> 3) Leave possibility to set default_time_to_live to 0 on a table but make a
> guardrail for UpdateStatement so it might reject queries for tables with
> default_time_to_live is zero and for which its TTL (on that update statement)
> is set to 0 too.
> I would be careful about making the current configuration illegal because of
> backward compatibility. For that reason 2) makes the most sense to me.
> Maybe implementing 3) would make sense as well. There might be a table which
> has default ttl set to 0 as it expects a user to supply TTL every time.
> However, as it is not currently enforced anywhere, a client might still
> insert TTLs to be set to 0 even by accident.
> POC for 2) is here
> https://github.com/instaclustr/cassandra/commit/0b4dcc3d3deeffa393c02a3b80e27482007f9579
--
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] [Comment Edited] (CASSANDRA-17992) Upgrade Netty on 4.x(current trunk)
[
https://issues.apache.org/jira/browse/CASSANDRA-17992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17625366#comment-17625366
]
Ekaterina Dimitrova edited comment on CASSANDRA-17992 at 11/30/22 10:56 PM:
{quote}Getting the full stack trace will help inform next steps.
{quote}
I think I have some preliminary good news. I ran some rough tests today to get
to it. I suspect things might have improved on Netty side recently.
So with the Netty version that was current in March, [current trunk and
JDK17|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2005/workflows/18b54727-8b82-42cc-9dd2-5a04bfb06e5a]
I can see 55 failing tests and a bunch of SSL tests.
Now looking into the cqlsh tests
[here|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2005/workflows/18b54727-8b82-42cc-9dd2-5a04bfb06e5a/jobs/16218/tests#failed-test-1]
I can also find the issue we discussed, test_tls:
{code:java}
test teardown failure Unexpected error found in node logs (see stdout for full
details). Errors: [[node1] "WARN [nioEventLoopGroup-5-5] 2022-10-27
22:45:13,917 ExceptionHandlers.java:140 - Unknown exception in client
networking\nio.netty.handler.codec.DecoderException:
javax.net.ssl.SSLException: Fail to unwrap network record\n\tat
io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:480)\n\tat
io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:279)\n\tat
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)\n\tat
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)\n\tat
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)\n\tat
io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)\n\tat
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)\n\tat
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)\n\tat
io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)\n\tat
io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:166)\n\tat
io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:722)\n\tat
io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:658)\n\tat
io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:584)\n\tat
io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:496)\n\tat
io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:986)\n\tat
io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)\n\tat
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
java.base/java.lang.Thread.run(Thread.java:833)\nCaused by:
javax.net.ssl.SSLException: Fail to unwrap network record\n\tat
java.base/sun.security.ssl.Alert.createSSLException(Alert.java:133)\n\tat
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:371)\n\tat
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:314)\n\tat
java.base/sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:522)\n\tat
java.base/sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:482)\n\tat
java.base/javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:679)\n\tat
io.netty.handler.ssl.SslHandler$SslEngineType$3.unwrap(SslHandler.java:295)\n\tat
io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1341)\n\tat
io.netty.handler.ssl.SslHandler.decodeJdkCompatible(SslHandler.java:1234)\n\tat
io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1283)\n\tat
io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:510)\n\tat
io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:449)\n\t...
17 common frames omitted\nCaused by: java.lang.ClassCastException: class
org.apache.cassandra.utils.memory.BufferPool$Chunk cannot be cast to class
sun.nio.ch.DirectBuffer (org.apache.cassandra.utils.memory.BufferPool$Chunk is
in unnamed module of loader 'app'; sun.nio.ch.DirectBuffer is in module
java.base of loader 'bootstrap')\n\tat
java.base/com.sun.crypto.provider.GaloisCounterMode$GCMEngine.overlapDetection(GaloisCounterMode.java:865)\n\tat
java.base/com.sun.crypto.provider.GaloisCounterMode$GCMDecrypt.doFinal(GaloisCounterMode.java:1502)\n\tat
java.base/com.sun.crypto.provider.GaloisCounterMode.engineDoFinal(GaloisCounterMode.java:447)\n\tat
java.base/javax.crypto.Cipher.doFinal(Cipher.java:2500)\n\tat
[jira] [Commented] (CASSANDRA-18042) Implement a guardrail for not having zero default ttl on tables with TWCS
[ https://issues.apache.org/jira/browse/CASSANDRA-18042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17641580#comment-17641580 ] Andres de la Peña commented on CASSANDRA-18042: --- Yep, it's not only redundant but it can also produce ambiguity in some cases. I guess it might have worked better if we had the nested guardrail config that was initially proposed on the CEP, but with the agreed flat config now it can clash with other properties. > Implement a guardrail for not having zero default ttl on tables with TWCS > - > > Key: CASSANDRA-18042 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18042 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Guardrails, Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.x > > Time Spent: 3h > Remaining Estimate: 0h > > A user was surprised that his data have not started to expire after 90 days > on his TWCS, he noticed that default_time_to_live on the table was set to 0 > (by accident from his side) and inserts were using TTL = 0 too. > It is questionable why it it possible to create a table with TWCS and enable > a user to specify default_time_to_live to be zero. > On the other hand, I would argue that having default_time_to_live set to 0 on > TWCS does not necessarily mean that such combination is illegal. It is about > people just using that with advantage very often so tables are compacted away > nicely. However, that does not have to mean that they could not use it with > 0. But I yet have to see a use-case where TWCS was used and default ttl was > set to 0 on purpose. Merely looking into Cassandra codebase, there are only > cases when this parameter is not 0. > There are three approaches: > 1) just reject such statements (for CreateTable and AlterTable statements) > where default_time_to_live = 0 > 2) Implement a guardrail for 1) so it can be enabled / disabled on demand > 3) Leave possibility to set default_time_to_live to 0 on a table but make a > guardrail for UpdateStatement so it might reject queries for tables with > default_time_to_live is zero and for which its TTL (on that update statement) > is set to 0 too. > I would be careful about making the current configuration illegal because of > backward compatibility. For that reason 2) makes the most sense to me. > Maybe implementing 3) would make sense as well. There might be a table which > has default ttl set to 0 as it expects a user to supply TTL every time. > However, as it is not currently enforced anywhere, a client might still > insert TTLs to be set to 0 even by accident. > POC for 2) is here > https://github.com/instaclustr/cassandra/commit/0b4dcc3d3deeffa393c02a3b80e27482007f9579 -- 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] [Comment Edited] (CASSANDRA-18042) Implement a guardrail for not having zero default ttl on tables with TWCS
[
https://issues.apache.org/jira/browse/CASSANDRA-18042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17641570#comment-17641570
]
Stefan Miklosovic edited comment on CASSANDRA-18042 at 11/30/22 10:22 PM:
--
In this case I would go like
{code:java}
sai_indexes_take_snapshots: true
sai_indexes_warn_if_enabled: true
sai_indexes_enabled: true {code}
Because in order to be able to take snapshots of sai indexes, sai indexes have
to be enabled in the first place so "if_enabled" is redundant.
and you could eventually do
{code:java}
sai_indexes_take_snapshots_warn_if_enabled: true
sai_indexes_take_snapshots: true
sai_indexes_warn_if_enabled: true
sai_indexes_enabled: true {code}
I personally do not see anything wrong with "sai_indexes_warned" or
"zero_ttl_on_twcs_warned" format. that "if_enabled" is just confusing IMO.
zero_ttl_on_twcs_enabled and zero_ttl_on_twcs_warned is just fine, same logic
is done as for "if_enabled" cases, it is just shorter.
EDIT:
I should add that when I first saw "if_enabled" I was little bit confused like
... enabled what?
If you have
{code:java}
sai_indexes_take_snapshots_if_enabled: true{code}
What does this "if_enabled" mean? If you have sai indexes enabled or if you
have snapshots on sai indexes enabled?
Do you see the difference? Somewhere in yaml you might have this hypothetical
property for being able to take snapshots on sai indexes like
"sai_indexes_take_snapshots". So in this case, how would you call a guardrail
which should warn you when you have "enabled snapshots on sai indexes"? I would
say it would be "sai_indexes_take_snapshots_warned" and the property itself
would be "sai_indexes_take_snaphots_enabled" (if it is meant to be guardrail as
well).
was (Author: smiklosovic):
In this case I would go like
{code:java}
sai_indexes_take_snapshots: true
sai_indexes_warn_if_enabled: true
sai_indexes_enabled: true {code}
Because in order to be able to take snapshots of sai indexes, sai indexes have
to be enabled in the first place so "if_enabled" is redundant.
and you could eventually do
{code:java}
sai_indexes_take_snapshots_warn_if_enabled: true
sai_indexes_take_snapshots: true
sai_indexes_warn_if_enabled: true
sai_indexes_enabled: true {code}
I personally do not see anything wrong with "sai_indexes_warned" or
"zero_ttl_on_twcs_warned" format. that "if_enabled" is just confusing IMO.
zero_ttl_on_twcs_enabled and zero_ttl_on_twcs_warned is just fine, same logic
is done as for "if_enabled" cases, it is just shorter.
> Implement a guardrail for not having zero default ttl on tables with TWCS
> -
>
> Key: CASSANDRA-18042
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18042
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Guardrails, Legacy/Core
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 3h
> Remaining Estimate: 0h
>
> A user was surprised that his data have not started to expire after 90 days
> on his TWCS, he noticed that default_time_to_live on the table was set to 0
> (by accident from his side) and inserts were using TTL = 0 too.
> It is questionable why it it possible to create a table with TWCS and enable
> a user to specify default_time_to_live to be zero.
> On the other hand, I would argue that having default_time_to_live set to 0 on
> TWCS does not necessarily mean that such combination is illegal. It is about
> people just using that with advantage very often so tables are compacted away
> nicely. However, that does not have to mean that they could not use it with
> 0. But I yet have to see a use-case where TWCS was used and default ttl was
> set to 0 on purpose. Merely looking into Cassandra codebase, there are only
> cases when this parameter is not 0.
> There are three approaches:
> 1) just reject such statements (for CreateTable and AlterTable statements)
> where default_time_to_live = 0
> 2) Implement a guardrail for 1) so it can be enabled / disabled on demand
> 3) Leave possibility to set default_time_to_live to 0 on a table but make a
> guardrail for UpdateStatement so it might reject queries for tables with
> default_time_to_live is zero and for which its TTL (on that update statement)
> is set to 0 too.
> I would be careful about making the current configuration illegal because of
> backward compatibility. For that reason 2) makes the most sense to me.
> Maybe implementing 3) would make sense as well. There might be a table which
> has default ttl set to 0 as it expects a user to supply TTL every time.
> However, as it is not currently enforced anywhere, a client might still
> insert TTLs to be set to 0 even by accident.
> POC for
[jira] [Commented] (CASSANDRA-18042) Implement a guardrail for not having zero default ttl on tables with TWCS
[
https://issues.apache.org/jira/browse/CASSANDRA-18042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17641570#comment-17641570
]
Stefan Miklosovic commented on CASSANDRA-18042:
---
In this case I would go like
{code:java}
sai_indexes_take_snapshots: true
sai_indexes_warn_if_enabled: true
sai_indexes_enabled: true {code}
Because in order to be able to take snapshots of sai indexes, sai indexes have
to be enabled in the first place so "if_enabled" is redundant.
and you could eventually do
{code:java}
sai_indexes_take_snapshots_warn_if_enabled: true
sai_indexes_take_snapshots: true
sai_indexes_warn_if_enabled: true
sai_indexes_enabled: true {code}
I personally do not see anything wrong with "sai_indexes_warned" or
"zero_ttl_on_twcs_warned" format. that "if_enabled" is just confusing IMO.
zero_ttl_on_twcs_enabled and zero_ttl_on_twcs_warned is just fine, same logic
is done as for "if_enabled" cases, it is just shorter.
> Implement a guardrail for not having zero default ttl on tables with TWCS
> -
>
> Key: CASSANDRA-18042
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18042
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Guardrails, Legacy/Core
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 3h
> Remaining Estimate: 0h
>
> A user was surprised that his data have not started to expire after 90 days
> on his TWCS, he noticed that default_time_to_live on the table was set to 0
> (by accident from his side) and inserts were using TTL = 0 too.
> It is questionable why it it possible to create a table with TWCS and enable
> a user to specify default_time_to_live to be zero.
> On the other hand, I would argue that having default_time_to_live set to 0 on
> TWCS does not necessarily mean that such combination is illegal. It is about
> people just using that with advantage very often so tables are compacted away
> nicely. However, that does not have to mean that they could not use it with
> 0. But I yet have to see a use-case where TWCS was used and default ttl was
> set to 0 on purpose. Merely looking into Cassandra codebase, there are only
> cases when this parameter is not 0.
> There are three approaches:
> 1) just reject such statements (for CreateTable and AlterTable statements)
> where default_time_to_live = 0
> 2) Implement a guardrail for 1) so it can be enabled / disabled on demand
> 3) Leave possibility to set default_time_to_live to 0 on a table but make a
> guardrail for UpdateStatement so it might reject queries for tables with
> default_time_to_live is zero and for which its TTL (on that update statement)
> is set to 0 too.
> I would be careful about making the current configuration illegal because of
> backward compatibility. For that reason 2) makes the most sense to me.
> Maybe implementing 3) would make sense as well. There might be a table which
> has default ttl set to 0 as it expects a user to supply TTL every time.
> However, as it is not currently enforced anywhere, a client might still
> insert TTLs to be set to 0 even by accident.
> POC for 2) is here
> https://github.com/instaclustr/cassandra/commit/0b4dcc3d3deeffa393c02a3b80e27482007f9579
--
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] [Updated] (CASSANDRA-17719) CEP-15: Multi-Partition Transaction CQL Support (Alpha)
[
https://issues.apache.org/jira/browse/CASSANDRA-17719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-17719:
Summary: CEP-15: Multi-Partition Transaction CQL Support (Alpha) (was:
CEP-15: Multi-Partition Transaction CQL Support v0.1)
> CEP-15: Multi-Partition Transaction CQL Support (Alpha)
> ---
>
> Key: CASSANDRA-17719
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17719
> Project: Cassandra
> Issue Type: New Feature
> Components: Accord, CQL/Syntax
>Reporter: Blake Eggleston
>Assignee: Caleb Rackliffe
>Priority: Normal
>
> The dev list thread regarding CQL transaction support seems to have converged
> on a syntax.
>
> The thread is here:
> [https://lists.apache.org/thread/5sds3968mnnk42c24pvgwphg4qvo2xk0]
>
> The message proposing the syntax ultimately agreed on is here:
> [https://lists.apache.org/thread/y289tczngj68bqpoo7gkso3bzmtf86pl]
>
> I'll describe my understanding of the agreed syntax here for, but I'd
> suggest reading through the thread.
>
> The example query is this:
> {code:sql}
> BEGIN TRANSACTION
> LET car = (SELECT miles_driven, is_running FROM cars WHERE model=’pinto’);
> LET user = (SELECT miles_driven FROM users WHERE name=’Blake’);
> SELECT car.is_running, car.miles_driven;
> IF car.is_running THEN
> UPDATE users SET miles_driven = user.miles_driven + 30 WHERE name='blake';
> UPDATE cars SET miles_driven = car.miles_driven + 30 WHERE model='pinto';
> END IF
> COMMIT TRANSACTION
> {code}
> Sections are described below, and we want to require the statement enforces
> an order on the different types of clauses. First, assignments, then
> select(s), then conditional updates. This may be relaxed in the future, but
> is meant to prevent users from interleaving updates and assignments and
> expecting read your own write behavior that we don't want to support in v1.
> h3. Reference assignments
> {code:sql}
> LET car = (SELECT miles_driven, is_running FROM cars WHERE
> model=’pinto’){code}
>
> The first part is basically assigning the result of a SELECT statement to a
> named reference that can be used in updates/conditions and be returned to the
> user. Tuple names belong to a global scope and must not clash with other LET
> statements or update statements (more on that in the updates section). Also,
> the select statement must either be a point read, with all primary key
> columns defined, or explicitly set a limit of 1.
> h3. Selection
> Data to returned to client. Currently, we're only supporting a single select
> statement. Either a normal select statement, or one returning values assigned
> by LET statements as shown in the example. Ultimately we'll want to support
> multiple select statements and returning the results to the client. Although
> that will require a protocol change.
> h3. Updates
> Normal inserts/updates/deletes with the following extensions:
> * Inserts and updates can reference values assigned earlier in the statement
> * Updates can reference their own columns:
> {code:java}
> miles_driven = miles_driven + 30{code}
> - or -
> {code:java}
> miles_driven += 30{code}
> These will of course need to generate any required reads behind the scenes.
> There's no precedence of table vs reference names, so if a relevant column
> name and reference name conflict, the query needs to fail to parse.
> h3. If blocks
> {code:sql}
> IF THEN
> ;
> ;
> END IF
> {code}
>
> For v1, we only need to support a single condition in the format above. In
> the future, we'd like to support multiple branches with multiple conditions
> like:
>
> {code:sql}
> IF THEN
> ;
> ;
> ELSE IF THEN
> ;
> ELSE
> ;
> END IF
> {code}
>
> h3. Conditions
> Comparisons of value references to literals or other references. IS NULL / IS
> NOT NULL also needs to be supported. Multiple comparisons need to be
> supported, but v1 only needs to support AND'ing them together.
> {code:java}
> Supported operators: =, !=, >, >=, <, <=, IS NULL, IS NOT NULL
> = 5
> IS NOT NULL
> IF car IS NOT NULL AND car.miles_driven > 30
> IF car.miles_driven = user.miles_driven{code}
> (Note that {{IS[ NOT ]NULL}} can apply to both tuple references and
> individually dereferenced columns.)
> CONTAINS and CONTAINS KEY require indexed collections, and will not be
> supported in v1.
> h3. Implementation notes
> I have a proof of concept I'd created to demo the initially proposed syntax
> here: [https://github.com/bdeggleston/cassandra/tree/accord-cql-poc], It
> could be used as a starting point, a source of ideas for approaches, or not
> used at all. The main thing to keep in mind is that value references prevent
> creating read commands and mutations until later
[jira] [Commented] (CASSANDRA-18042) Implement a guardrail for not having zero default ttl on tables with TWCS
[
https://issues.apache.org/jira/browse/CASSANDRA-18042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17641566#comment-17641566
]
Andres de la Peña commented on CASSANDRA-18042:
---
I understand that feature flags could be implemented with an {{EnableFlag}} as
it's defined in the current PR, so they have separate properties for warning
and enabling/disabling.
A curious detail of "feature_warn_if_enabled" is that any other property
associated to the feature would equally only happen if "feature_enabled". So,
let's say that we have a guardrail for SAI indexes:
{code}
sai_indexes_warn_if_enabled: true
sai_indexes_enabled: true
{code}
If we add a new property to, for example, taking snapshots of the index, should
we use:
{code}
sai_indexes_take_snapshots_if_enabled: true
sai_indexes_warn_if_enabled: true
sai_indexes_enabled: true
{code}
or
{code}
sai_indexes_take_snapshots: true
sai_indexes_warn_if_enabled: true
sai_indexes_enabled: true
{code}
?
> Implement a guardrail for not having zero default ttl on tables with TWCS
> -
>
> Key: CASSANDRA-18042
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18042
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Guardrails, Legacy/Core
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 3h
> Remaining Estimate: 0h
>
> A user was surprised that his data have not started to expire after 90 days
> on his TWCS, he noticed that default_time_to_live on the table was set to 0
> (by accident from his side) and inserts were using TTL = 0 too.
> It is questionable why it it possible to create a table with TWCS and enable
> a user to specify default_time_to_live to be zero.
> On the other hand, I would argue that having default_time_to_live set to 0 on
> TWCS does not necessarily mean that such combination is illegal. It is about
> people just using that with advantage very often so tables are compacted away
> nicely. However, that does not have to mean that they could not use it with
> 0. But I yet have to see a use-case where TWCS was used and default ttl was
> set to 0 on purpose. Merely looking into Cassandra codebase, there are only
> cases when this parameter is not 0.
> There are three approaches:
> 1) just reject such statements (for CreateTable and AlterTable statements)
> where default_time_to_live = 0
> 2) Implement a guardrail for 1) so it can be enabled / disabled on demand
> 3) Leave possibility to set default_time_to_live to 0 on a table but make a
> guardrail for UpdateStatement so it might reject queries for tables with
> default_time_to_live is zero and for which its TTL (on that update statement)
> is set to 0 too.
> I would be careful about making the current configuration illegal because of
> backward compatibility. For that reason 2) makes the most sense to me.
> Maybe implementing 3) would make sense as well. There might be a table which
> has default ttl set to 0 as it expects a user to supply TTL every time.
> However, as it is not currently enforced anywhere, a client might still
> insert TTLs to be set to 0 even by accident.
> POC for 2) is here
> https://github.com/instaclustr/cassandra/commit/0b4dcc3d3deeffa393c02a3b80e27482007f9579
--
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-18042) Implement a guardrail for not having zero default ttl on tables with TWCS
[ https://issues.apache.org/jira/browse/CASSANDRA-18042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17641563#comment-17641563 ] Stefan Miklosovic commented on CASSANDRA-18042: --- Yes it is same relationship, because if "warn_if_enabled" is true and "feature_enabled" is false it would fail the query so warning is redundant. I think this is designed just fine. What I got from your last sentence is that we might maybe return to having one property and warning every time? Did I interpret it right? > Implement a guardrail for not having zero default ttl on tables with TWCS > - > > Key: CASSANDRA-18042 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18042 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Guardrails, Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.x > > Time Spent: 3h > Remaining Estimate: 0h > > A user was surprised that his data have not started to expire after 90 days > on his TWCS, he noticed that default_time_to_live on the table was set to 0 > (by accident from his side) and inserts were using TTL = 0 too. > It is questionable why it it possible to create a table with TWCS and enable > a user to specify default_time_to_live to be zero. > On the other hand, I would argue that having default_time_to_live set to 0 on > TWCS does not necessarily mean that such combination is illegal. It is about > people just using that with advantage very often so tables are compacted away > nicely. However, that does not have to mean that they could not use it with > 0. But I yet have to see a use-case where TWCS was used and default ttl was > set to 0 on purpose. Merely looking into Cassandra codebase, there are only > cases when this parameter is not 0. > There are three approaches: > 1) just reject such statements (for CreateTable and AlterTable statements) > where default_time_to_live = 0 > 2) Implement a guardrail for 1) so it can be enabled / disabled on demand > 3) Leave possibility to set default_time_to_live to 0 on a table but make a > guardrail for UpdateStatement so it might reject queries for tables with > default_time_to_live is zero and for which its TTL (on that update statement) > is set to 0 too. > I would be careful about making the current configuration illegal because of > backward compatibility. For that reason 2) makes the most sense to me. > Maybe implementing 3) would make sense as well. There might be a table which > has default ttl set to 0 as it expects a user to supply TTL every time. > However, as it is not currently enforced anywhere, a client might still > insert TTLs to be set to 0 even by accident. > POC for 2) is here > https://github.com/instaclustr/cassandra/commit/0b4dcc3d3deeffa393c02a3b80e27482007f9579 -- 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-18042) Implement a guardrail for not having zero default ttl on tables with TWCS
[
https://issues.apache.org/jira/browse/CASSANDRA-18042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17641560#comment-17641560
]
Josh McKenzie commented on CASSANDRA-18042:
---
{quote}Just to understand the mechanics better - "warn_if_enabled", that "if"
means that "if zero_ttl_on_twcs_enabled is true" ?
{quote}
To your point Stefan, it is a touch unwieldy. But basically "feature_warned"
would only actually happen if "feature_enabled" so it's the same dependent
relationship.
There's the meta question here: should we have warnings for feature flag
enabled features? Basically, all the things we feature flag guardrailed are
"you could be using this wrong and/or be setting yourself up for future pain"
style features too right?
So maybe the answer here is we should have the ability to warn on all of them
that gets passed back to clients w/context on their usage and potential
pitfalls like this one.
> Implement a guardrail for not having zero default ttl on tables with TWCS
> -
>
> Key: CASSANDRA-18042
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18042
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Guardrails, Legacy/Core
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 3h
> Remaining Estimate: 0h
>
> A user was surprised that his data have not started to expire after 90 days
> on his TWCS, he noticed that default_time_to_live on the table was set to 0
> (by accident from his side) and inserts were using TTL = 0 too.
> It is questionable why it it possible to create a table with TWCS and enable
> a user to specify default_time_to_live to be zero.
> On the other hand, I would argue that having default_time_to_live set to 0 on
> TWCS does not necessarily mean that such combination is illegal. It is about
> people just using that with advantage very often so tables are compacted away
> nicely. However, that does not have to mean that they could not use it with
> 0. But I yet have to see a use-case where TWCS was used and default ttl was
> set to 0 on purpose. Merely looking into Cassandra codebase, there are only
> cases when this parameter is not 0.
> There are three approaches:
> 1) just reject such statements (for CreateTable and AlterTable statements)
> where default_time_to_live = 0
> 2) Implement a guardrail for 1) so it can be enabled / disabled on demand
> 3) Leave possibility to set default_time_to_live to 0 on a table but make a
> guardrail for UpdateStatement so it might reject queries for tables with
> default_time_to_live is zero and for which its TTL (on that update statement)
> is set to 0 too.
> I would be careful about making the current configuration illegal because of
> backward compatibility. For that reason 2) makes the most sense to me.
> Maybe implementing 3) would make sense as well. There might be a table which
> has default ttl set to 0 as it expects a user to supply TTL every time.
> However, as it is not currently enforced anywhere, a client might still
> insert TTLs to be set to 0 even by accident.
> POC for 2) is here
> https://github.com/instaclustr/cassandra/commit/0b4dcc3d3deeffa393c02a3b80e27482007f9579
--
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] [Comment Edited] (CASSANDRA-18042) Implement a guardrail for not having zero default ttl on tables with TWCS
[
https://issues.apache.org/jira/browse/CASSANDRA-18042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17641441#comment-17641441
]
Josh McKenzie edited comment on CASSANDRA-18042 at 11/30/22 9:12 PM:
-
1. I'm terrible at naming things. Grain of salt me.
2. I think it's worth a little extra time here since we're establishing a
precedent (warn / fail threshold on feature flagged things)
Brandon's point I think needs a touch further tweaking; the "_fail_enabled" is
confusing to me.
The format of:
{code}
feature_warn_if_enabled: true
feature_enabled: true
{code}
while not internally "consistent" with one another makes the most clear logical
sense to me.
So we'd concretely have:
{code}
zero_ttl_on_twcs_warn_if_enabled: true
zero_ttl_on_twcs_enabled: true
{code}
was (Author: jmckenzie):
1. I'm terrible at naming things. Grain of salt me.
2. I think it's worth a little extra time here since we're establishing a
precedent (warn / fail threshold on feature flagged things)
Brandon's point I think needs a touch further tweaking; the "_fail_enabled" is
confusing to me.
The format of:
{quote}
feature_warn_if_enabled: true
feature_enabled: true
{quote}
while not internally "consistent" with one another makes the most clear logical
sense to me.
So we'd concretely have:
{quote}
zero_ttl_on_twcs_warn_if_enabled: true
zero_ttl_on_twcs_enabled: true
{quote}
> Implement a guardrail for not having zero default ttl on tables with TWCS
> -
>
> Key: CASSANDRA-18042
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18042
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Guardrails, Legacy/Core
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 3h
> Remaining Estimate: 0h
>
> A user was surprised that his data have not started to expire after 90 days
> on his TWCS, he noticed that default_time_to_live on the table was set to 0
> (by accident from his side) and inserts were using TTL = 0 too.
> It is questionable why it it possible to create a table with TWCS and enable
> a user to specify default_time_to_live to be zero.
> On the other hand, I would argue that having default_time_to_live set to 0 on
> TWCS does not necessarily mean that such combination is illegal. It is about
> people just using that with advantage very often so tables are compacted away
> nicely. However, that does not have to mean that they could not use it with
> 0. But I yet have to see a use-case where TWCS was used and default ttl was
> set to 0 on purpose. Merely looking into Cassandra codebase, there are only
> cases when this parameter is not 0.
> There are three approaches:
> 1) just reject such statements (for CreateTable and AlterTable statements)
> where default_time_to_live = 0
> 2) Implement a guardrail for 1) so it can be enabled / disabled on demand
> 3) Leave possibility to set default_time_to_live to 0 on a table but make a
> guardrail for UpdateStatement so it might reject queries for tables with
> default_time_to_live is zero and for which its TTL (on that update statement)
> is set to 0 too.
> I would be careful about making the current configuration illegal because of
> backward compatibility. For that reason 2) makes the most sense to me.
> Maybe implementing 3) would make sense as well. There might be a table which
> has default ttl set to 0 as it expects a user to supply TTL every time.
> However, as it is not currently enforced anywhere, a client might still
> insert TTLs to be set to 0 even by accident.
> POC for 2) is here
> https://github.com/instaclustr/cassandra/commit/0b4dcc3d3deeffa393c02a3b80e27482007f9579
--
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-17848) Fix incorrect resource name in LIST PERMISSION output
[
https://issues.apache.org/jira/browse/CASSANDRA-17848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17641554#comment-17641554
]
Yifan Cai commented on CASSANDRA-17848:
---
[~bereng], sure thing! I re-run the tests for 4.0. The result looks much
better. The prior errors were probably due to resources.
The CircleCI config was modified a bit. It is the equivalent of 'pre-commit'.
> Fix incorrect resource name in LIST PERMISSION output
> -
>
> Key: CASSANDRA-17848
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17848
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Yifan Cai
>Assignee: Yifan Cai
>Priority: Normal
> Fix For: 3.0.29, 3.11.15, 4.0.8, 4.1.1, 4.2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When producing the resource name, it seems to assume that the content in the
> `[]` is the function's input type, where it could also be part of the
> function name, as long as it is quoted. Here is an example to reproduce. In
> cqlsh,
> {code:java}
> > CREATE FUNCTION
> > test."admin_created_udf[org.apache.cassandra.db.marshal.LongType]"(input
> > int) RETURNS NULL ON NULL INPUT RETURNS int LANGUAGE java AS 'return 42;';
> > LIST EXECUTE OF user;
> role | username | resource| permission
> ---+--+-+
> user |user | |EXECUTE
> (1 rows)
> {code}
> The input should be "int", but in the output, it says "long".
> If the content enclosed by "[]" is not a valid class, the LIST PERMISSION
> request always fails for the user with "ConfigurationException: Unable to
> find abstract-type class".
> The bug is discovered by Piotr Sarna.
--
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] [Updated] (CASSANDRA-17254) nodetool toppartitions can fail because ByteBuffer.array() returns more bytes than would be considered valid by UTF8Serializer.validate
[
https://issues.apache.org/jira/browse/CASSANDRA-17254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh McKenzie updated CASSANDRA-17254:
--
Fix Version/s: 3.0.29
(was: 3.0.x)
> nodetool toppartitions can fail because ByteBuffer.array() returns more bytes
> than would be considered valid by UTF8Serializer.validate
> ---
>
> Key: CASSANDRA-17254
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17254
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/nodetool
>Reporter: Jordan West
>Assignee: Jordan West
>Priority: Normal
> Fix For: 3.0.29
>
>
> The error below is caused by the use of
> [{{ByteBuffer.array()}}|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/db/ColumnFamilyStore.java#L1628].
> Doing so not only makes the hex key potentially incorrect but causes invalid
> data to be passed to {{AbstractType.getString}} and ultimately
> {{UTF8Validator.validate}}.
> {code}
> error: String didn't validate.
> -- StackTrace --
> org.apache.cassandra.serializers.MarshalException: String didn't validate.
> at
> org.apache.cassandra.serializers.UTF8Serializer.validate(UTF8Serializer.java:35)
> at
> org.apache.cassandra.db.marshal.AbstractType.getString(AbstractType.java:129)
> at
> org.apache.cassandra.db.ColumnFamilyStore.finishLocalSampling(ColumnFamilyStore.java:1633)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}
--
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] [Comment Edited] (CASSANDRA-18042) Implement a guardrail for not having zero default ttl on tables with TWCS
[ https://issues.apache.org/jira/browse/CASSANDRA-18042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17641503#comment-17641503 ] Stefan Miklosovic edited comment on CASSANDRA-18042 at 11/30/22 7:20 PM: - Just to understand the mechanics better - "warn_if_enabled", that "if" means that "if zero_ttl_on_twcs_enabled is true" ? -To understand what that property with "if" means, it has to be somehow related to the other one. They need to be placed together. I am not sure I would understand this if that property was "standalone" because I would not know what "if_enabled" is actually related to.- I mean, I am not against this, but having "if" inside the property is quite awkward. I think this is the first case we have in the whole yaml with something different from a noun or verb or adjective ... you feel me. EDIT: actually, "zero_ttl_on_twcs_warn_if_enabled" is "warn if it is enabled" yeah :D I see it now ... OK OK guys, I will put there "if" no worries. On it. was (Author: smiklosovic): Just to understand the mechanics better - "warn_if_enabled", that "if" means that "if zero_ttl_on_twcs_enabled is true" ? To understand what that property with "if" means, it has to be somehow related to the other one. They need to be placed together. I am not sure I would understand this if that property was "standalone" because I would not know what "if_enabled" is actually related to. I mean, I am not against this, but having "if" inside the property is quite awkward. I think this is the first case we have in the whole yaml with something different from a noun or verb or adjective ... you feel me. EDIT: actually, "zero_ttl_on_twcs_warn_if_enabled" is "warn if it is enabled" yeah :D I see it now ... OK OK guys, I will put there "if" no worries. On it. > Implement a guardrail for not having zero default ttl on tables with TWCS > - > > Key: CASSANDRA-18042 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18042 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Guardrails, Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.x > > Time Spent: 3h > Remaining Estimate: 0h > > A user was surprised that his data have not started to expire after 90 days > on his TWCS, he noticed that default_time_to_live on the table was set to 0 > (by accident from his side) and inserts were using TTL = 0 too. > It is questionable why it it possible to create a table with TWCS and enable > a user to specify default_time_to_live to be zero. > On the other hand, I would argue that having default_time_to_live set to 0 on > TWCS does not necessarily mean that such combination is illegal. It is about > people just using that with advantage very often so tables are compacted away > nicely. However, that does not have to mean that they could not use it with > 0. But I yet have to see a use-case where TWCS was used and default ttl was > set to 0 on purpose. Merely looking into Cassandra codebase, there are only > cases when this parameter is not 0. > There are three approaches: > 1) just reject such statements (for CreateTable and AlterTable statements) > where default_time_to_live = 0 > 2) Implement a guardrail for 1) so it can be enabled / disabled on demand > 3) Leave possibility to set default_time_to_live to 0 on a table but make a > guardrail for UpdateStatement so it might reject queries for tables with > default_time_to_live is zero and for which its TTL (on that update statement) > is set to 0 too. > I would be careful about making the current configuration illegal because of > backward compatibility. For that reason 2) makes the most sense to me. > Maybe implementing 3) would make sense as well. There might be a table which > has default ttl set to 0 as it expects a user to supply TTL every time. > However, as it is not currently enforced anywhere, a client might still > insert TTLs to be set to 0 even by accident. > POC for 2) is here > https://github.com/instaclustr/cassandra/commit/0b4dcc3d3deeffa393c02a3b80e27482007f9579 -- 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] [Updated] (CASSANDRA-18042) Implement a guardrail for not having zero default ttl on tables with TWCS
[ https://issues.apache.org/jira/browse/CASSANDRA-18042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-18042: -- Status: In Progress (was: Patch Available) > Implement a guardrail for not having zero default ttl on tables with TWCS > - > > Key: CASSANDRA-18042 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18042 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Guardrails, Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.x > > Time Spent: 3h > Remaining Estimate: 0h > > A user was surprised that his data have not started to expire after 90 days > on his TWCS, he noticed that default_time_to_live on the table was set to 0 > (by accident from his side) and inserts were using TTL = 0 too. > It is questionable why it it possible to create a table with TWCS and enable > a user to specify default_time_to_live to be zero. > On the other hand, I would argue that having default_time_to_live set to 0 on > TWCS does not necessarily mean that such combination is illegal. It is about > people just using that with advantage very often so tables are compacted away > nicely. However, that does not have to mean that they could not use it with > 0. But I yet have to see a use-case where TWCS was used and default ttl was > set to 0 on purpose. Merely looking into Cassandra codebase, there are only > cases when this parameter is not 0. > There are three approaches: > 1) just reject such statements (for CreateTable and AlterTable statements) > where default_time_to_live = 0 > 2) Implement a guardrail for 1) so it can be enabled / disabled on demand > 3) Leave possibility to set default_time_to_live to 0 on a table but make a > guardrail for UpdateStatement so it might reject queries for tables with > default_time_to_live is zero and for which its TTL (on that update statement) > is set to 0 too. > I would be careful about making the current configuration illegal because of > backward compatibility. For that reason 2) makes the most sense to me. > Maybe implementing 3) would make sense as well. There might be a table which > has default ttl set to 0 as it expects a user to supply TTL every time. > However, as it is not currently enforced anywhere, a client might still > insert TTLs to be set to 0 even by accident. > POC for 2) is here > https://github.com/instaclustr/cassandra/commit/0b4dcc3d3deeffa393c02a3b80e27482007f9579 -- 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] [Comment Edited] (CASSANDRA-18042) Implement a guardrail for not having zero default ttl on tables with TWCS
[ https://issues.apache.org/jira/browse/CASSANDRA-18042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17641503#comment-17641503 ] Stefan Miklosovic edited comment on CASSANDRA-18042 at 11/30/22 7:06 PM: - Just to understand the mechanics better - "warn_if_enabled", that "if" means that "if zero_ttl_on_twcs_enabled is true" ? To understand what that property with "if" means, it has to be somehow related to the other one. They need to be placed together. I am not sure I would understand this if that property was "standalone" because I would not know what "if_enabled" is actually related to. I mean, I am not against this, but having "if" inside the property is quite awkward. I think this is the first case we have in the whole yaml with something different from a noun or verb or adjective ... you feel me. EDIT: actually, "zero_ttl_on_twcs_warn_if_enabled" is "warn if it is enabled" yeah :D I see it now ... OK OK guys, I will put there "if" no worries. On it. was (Author: smiklosovic): Just to understand the mechanics better - "warn_if_enabled", that "if" means that "if zero_ttl_on_twcs_enabled is true" ? To understand what that property with "if" means, it has to be somehow related to the other one. They need to be placed together. I am not sure I would understand this if that property was "standalone" because I would not know what "if_enabled" is actually related to. I mean, I am not against this, but having "if" inside the property is quite awkward. I think this is the first case we have in the whole yaml with something different from a noun or verb or adjective ... you feel me. EDIT: actually, "zero_ttl_on_twcs_warn_if_enabled" is "warn if it is enabled" yeah :D I see it know ... OK OK guys, I will put there "if" no worries. On it. > Implement a guardrail for not having zero default ttl on tables with TWCS > - > > Key: CASSANDRA-18042 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18042 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Guardrails, Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.x > > Time Spent: 3h > Remaining Estimate: 0h > > A user was surprised that his data have not started to expire after 90 days > on his TWCS, he noticed that default_time_to_live on the table was set to 0 > (by accident from his side) and inserts were using TTL = 0 too. > It is questionable why it it possible to create a table with TWCS and enable > a user to specify default_time_to_live to be zero. > On the other hand, I would argue that having default_time_to_live set to 0 on > TWCS does not necessarily mean that such combination is illegal. It is about > people just using that with advantage very often so tables are compacted away > nicely. However, that does not have to mean that they could not use it with > 0. But I yet have to see a use-case where TWCS was used and default ttl was > set to 0 on purpose. Merely looking into Cassandra codebase, there are only > cases when this parameter is not 0. > There are three approaches: > 1) just reject such statements (for CreateTable and AlterTable statements) > where default_time_to_live = 0 > 2) Implement a guardrail for 1) so it can be enabled / disabled on demand > 3) Leave possibility to set default_time_to_live to 0 on a table but make a > guardrail for UpdateStatement so it might reject queries for tables with > default_time_to_live is zero and for which its TTL (on that update statement) > is set to 0 too. > I would be careful about making the current configuration illegal because of > backward compatibility. For that reason 2) makes the most sense to me. > Maybe implementing 3) would make sense as well. There might be a table which > has default ttl set to 0 as it expects a user to supply TTL every time. > However, as it is not currently enforced anywhere, a client might still > insert TTLs to be set to 0 even by accident. > POC for 2) is here > https://github.com/instaclustr/cassandra/commit/0b4dcc3d3deeffa393c02a3b80e27482007f9579 -- 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] [Comment Edited] (CASSANDRA-18042) Implement a guardrail for not having zero default ttl on tables with TWCS
[ https://issues.apache.org/jira/browse/CASSANDRA-18042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17641503#comment-17641503 ] Stefan Miklosovic edited comment on CASSANDRA-18042 at 11/30/22 7:04 PM: - Just to understand the mechanics better - "warn_if_enabled", that "if" means that "if zero_ttl_on_twcs_enabled is true" ? To understand what that property with "if" means, it has to be somehow related to the other one. They need to be placed together. I am not sure I would understand this if that property was "standalone" because I would not know what "if_enabled" is actually related to. I mean, I am not against this, but having "if" inside the property is quite awkward. I think this is the first case we have in the whole yaml with something different from a noun or verb or adjective ... you feel me. EDIT: actually, "zero_ttl_on_twcs_warn_if_enabled" is "warn if it is enabled" yeah :D I see it know ... OK OK guys, I will put there "if" no worries. On it. was (Author: smiklosovic): Just to understand the mechanics better - "warn_if_enabled", that "if" means that "if zero_ttl_on_twcs_enabled is true" ? To understand what that property with "if" means, it has to be somehow related to the other one. They need to be placed together. I am not sure I would understand this if that property was "standalone" because I would not know what "if_enabled" is actually related to. I mean, I am not against this, but having "if" inside the property is quite awkward. I think this is the first case we have in the whole yaml with something different from a noun or verb or adjective ... you feel me. > Implement a guardrail for not having zero default ttl on tables with TWCS > - > > Key: CASSANDRA-18042 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18042 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Guardrails, Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.x > > Time Spent: 3h > Remaining Estimate: 0h > > A user was surprised that his data have not started to expire after 90 days > on his TWCS, he noticed that default_time_to_live on the table was set to 0 > (by accident from his side) and inserts were using TTL = 0 too. > It is questionable why it it possible to create a table with TWCS and enable > a user to specify default_time_to_live to be zero. > On the other hand, I would argue that having default_time_to_live set to 0 on > TWCS does not necessarily mean that such combination is illegal. It is about > people just using that with advantage very often so tables are compacted away > nicely. However, that does not have to mean that they could not use it with > 0. But I yet have to see a use-case where TWCS was used and default ttl was > set to 0 on purpose. Merely looking into Cassandra codebase, there are only > cases when this parameter is not 0. > There are three approaches: > 1) just reject such statements (for CreateTable and AlterTable statements) > where default_time_to_live = 0 > 2) Implement a guardrail for 1) so it can be enabled / disabled on demand > 3) Leave possibility to set default_time_to_live to 0 on a table but make a > guardrail for UpdateStatement so it might reject queries for tables with > default_time_to_live is zero and for which its TTL (on that update statement) > is set to 0 too. > I would be careful about making the current configuration illegal because of > backward compatibility. For that reason 2) makes the most sense to me. > Maybe implementing 3) would make sense as well. There might be a table which > has default ttl set to 0 as it expects a user to supply TTL every time. > However, as it is not currently enforced anywhere, a client might still > insert TTLs to be set to 0 even by accident. > POC for 2) is here > https://github.com/instaclustr/cassandra/commit/0b4dcc3d3deeffa393c02a3b80e27482007f9579 -- 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] [Comment Edited] (CASSANDRA-18042) Implement a guardrail for not having zero default ttl on tables with TWCS
[ https://issues.apache.org/jira/browse/CASSANDRA-18042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17641503#comment-17641503 ] Stefan Miklosovic edited comment on CASSANDRA-18042 at 11/30/22 7:02 PM: - Just to understand the mechanics better - "warn_if_enabled", that "if" means that "if zero_ttl_on_twcs_enabled is true" ? To understand what that property with "if" means, it has to be somehow related to the other one. They need to be placed together. I am not sure I would understand this if that property was "standalone" because I would not know what "if_enabled" is actually related to. I mean, I am not against this, but having "if" inside the property is quite awkward. I think this is the first case we have in the whole yaml with something different from a noun or verb or adjective ... you feel me. was (Author: smiklosovic): Just to understand the mechanics better - "warn_if_enabled", that "if" means that "if zero_ttl_on_twcs_enabled is true" ? I mean, I am not against this, but having "if" inside the property is quite awkward. I think this is the first case we have in the whole yaml with something different from a noun or verb or adjective ... you feel me. > Implement a guardrail for not having zero default ttl on tables with TWCS > - > > Key: CASSANDRA-18042 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18042 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Guardrails, Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.x > > Time Spent: 3h > Remaining Estimate: 0h > > A user was surprised that his data have not started to expire after 90 days > on his TWCS, he noticed that default_time_to_live on the table was set to 0 > (by accident from his side) and inserts were using TTL = 0 too. > It is questionable why it it possible to create a table with TWCS and enable > a user to specify default_time_to_live to be zero. > On the other hand, I would argue that having default_time_to_live set to 0 on > TWCS does not necessarily mean that such combination is illegal. It is about > people just using that with advantage very often so tables are compacted away > nicely. However, that does not have to mean that they could not use it with > 0. But I yet have to see a use-case where TWCS was used and default ttl was > set to 0 on purpose. Merely looking into Cassandra codebase, there are only > cases when this parameter is not 0. > There are three approaches: > 1) just reject such statements (for CreateTable and AlterTable statements) > where default_time_to_live = 0 > 2) Implement a guardrail for 1) so it can be enabled / disabled on demand > 3) Leave possibility to set default_time_to_live to 0 on a table but make a > guardrail for UpdateStatement so it might reject queries for tables with > default_time_to_live is zero and for which its TTL (on that update statement) > is set to 0 too. > I would be careful about making the current configuration illegal because of > backward compatibility. For that reason 2) makes the most sense to me. > Maybe implementing 3) would make sense as well. There might be a table which > has default ttl set to 0 as it expects a user to supply TTL every time. > However, as it is not currently enforced anywhere, a client might still > insert TTLs to be set to 0 even by accident. > POC for 2) is here > https://github.com/instaclustr/cassandra/commit/0b4dcc3d3deeffa393c02a3b80e27482007f9579 -- 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-18042) Implement a guardrail for not having zero default ttl on tables with TWCS
[ https://issues.apache.org/jira/browse/CASSANDRA-18042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17641503#comment-17641503 ] Stefan Miklosovic commented on CASSANDRA-18042: --- Just to understand the mechanics better - "warn_if_enabled", that "if" means that "if zero_ttl_on_twcs_enabled is true" ? I mean, I am not against this, but having "if" inside the property is quite awkward. I think this is the first case we have in the whole yaml with something different from a noun or verb or adjective ... you feel me. > Implement a guardrail for not having zero default ttl on tables with TWCS > - > > Key: CASSANDRA-18042 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18042 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Guardrails, Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.x > > Time Spent: 3h > Remaining Estimate: 0h > > A user was surprised that his data have not started to expire after 90 days > on his TWCS, he noticed that default_time_to_live on the table was set to 0 > (by accident from his side) and inserts were using TTL = 0 too. > It is questionable why it it possible to create a table with TWCS and enable > a user to specify default_time_to_live to be zero. > On the other hand, I would argue that having default_time_to_live set to 0 on > TWCS does not necessarily mean that such combination is illegal. It is about > people just using that with advantage very often so tables are compacted away > nicely. However, that does not have to mean that they could not use it with > 0. But I yet have to see a use-case where TWCS was used and default ttl was > set to 0 on purpose. Merely looking into Cassandra codebase, there are only > cases when this parameter is not 0. > There are three approaches: > 1) just reject such statements (for CreateTable and AlterTable statements) > where default_time_to_live = 0 > 2) Implement a guardrail for 1) so it can be enabled / disabled on demand > 3) Leave possibility to set default_time_to_live to 0 on a table but make a > guardrail for UpdateStatement so it might reject queries for tables with > default_time_to_live is zero and for which its TTL (on that update statement) > is set to 0 too. > I would be careful about making the current configuration illegal because of > backward compatibility. For that reason 2) makes the most sense to me. > Maybe implementing 3) would make sense as well. There might be a table which > has default ttl set to 0 as it expects a user to supply TTL every time. > However, as it is not currently enforced anywhere, a client might still > insert TTLs to be set to 0 even by accident. > POC for 2) is here > https://github.com/instaclustr/cassandra/commit/0b4dcc3d3deeffa393c02a3b80e27482007f9579 -- 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-18042) Implement a guardrail for not having zero default ttl on tables with TWCS
[ https://issues.apache.org/jira/browse/CASSANDRA-18042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17641490#comment-17641490 ] Brandon Williams commented on CASSANDRA-18042: -- In feature_warn_if_enabled vs feature_warned, I think I'm with Josh on the former now. > Implement a guardrail for not having zero default ttl on tables with TWCS > - > > Key: CASSANDRA-18042 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18042 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Guardrails, Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.x > > Time Spent: 3h > Remaining Estimate: 0h > > A user was surprised that his data have not started to expire after 90 days > on his TWCS, he noticed that default_time_to_live on the table was set to 0 > (by accident from his side) and inserts were using TTL = 0 too. > It is questionable why it it possible to create a table with TWCS and enable > a user to specify default_time_to_live to be zero. > On the other hand, I would argue that having default_time_to_live set to 0 on > TWCS does not necessarily mean that such combination is illegal. It is about > people just using that with advantage very often so tables are compacted away > nicely. However, that does not have to mean that they could not use it with > 0. But I yet have to see a use-case where TWCS was used and default ttl was > set to 0 on purpose. Merely looking into Cassandra codebase, there are only > cases when this parameter is not 0. > There are three approaches: > 1) just reject such statements (for CreateTable and AlterTable statements) > where default_time_to_live = 0 > 2) Implement a guardrail for 1) so it can be enabled / disabled on demand > 3) Leave possibility to set default_time_to_live to 0 on a table but make a > guardrail for UpdateStatement so it might reject queries for tables with > default_time_to_live is zero and for which its TTL (on that update statement) > is set to 0 too. > I would be careful about making the current configuration illegal because of > backward compatibility. For that reason 2) makes the most sense to me. > Maybe implementing 3) would make sense as well. There might be a table which > has default ttl set to 0 as it expects a user to supply TTL every time. > However, as it is not currently enforced anywhere, a client might still > insert TTLs to be set to 0 even by accident. > POC for 2) is here > https://github.com/instaclustr/cassandra/commit/0b4dcc3d3deeffa393c02a3b80e27482007f9579 -- 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] [Comment Edited] (CASSANDRA-18075) Upgraded (C* 4.0.4) node stops communicating with older version (3.11.4) nodes during upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-18075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17641463#comment-17641463
]
Brandon Williams edited comment on CASSANDRA-18075 at 11/30/22 5:47 PM:
I don't think we would expect anything to change by explicitly setting those
two properties since they match the defaults, my greater point was that you
should use a minimally modified yaml so that it's directly comparable to the
stock yaml. That said, you are missing enable_legacy_ssl_storage_port this
time.
bq. So, something is going wrong (probably a bug) with SSL cluster
communication during the upgrade process
Here is a passing test that covers this scenario:
https://ci-cassandra.apache.org/job/Cassandra-3.0/313/testReport/dtest-upgrade.upgrade_tests.upgrade_through_versions_test/TestUpgrade_indev_3_0_x_To_indev_4_0_x/test_parallel_upgrade_with_internode_ssl/
was (Author: brandon.williams):
I don't think we would expect anything to change by explicitly settings those
two properties since they match the defaults, my greater point was that you
should use a minimally modified yaml so that it's directly comparable to the
stock yaml. That said, you are missing enable_legacy_ssl_storage_port this
time.
bq. So, something is going wrong (probably a bug) with SSL cluster
communication during the upgrade process
Here is a passing test that covers this scenario:
https://ci-cassandra.apache.org/job/Cassandra-3.0/313/testReport/dtest-upgrade.upgrade_tests.upgrade_through_versions_test/TestUpgrade_indev_3_0_x_To_indev_4_0_x/test_parallel_upgrade_with_internode_ssl/
> Upgraded (C* 4.0.4) node stops communicating with older version (3.11.4)
> nodes during upgrade
> -
>
> Key: CASSANDRA-18075
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18075
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Encryption
>Reporter: Alaykumar Barochia
>Priority: Normal
> Attachments: cassandra-env.sh_3114, cassandra-env.sh_404,
> cassandra.yaml_10.110.44.207_explicitely_set_port,
> cassandra.yaml_10.110.49.242_explicitely_set_port, cassandra.yaml_3114,
> cassandra.yaml_404, system.log_10.110.44.207,
> system.log_10.110.44.207_after_explicitely_set_port,
> system.log_10.110.49.242_after_explicitely_set_port
>
>
> We are testing upgrade from Cassandra 3.11.4 to 4.0.4 on our test cluster
> which is SSL enabled and facing an issue.
> Our cluster size is 3x3.
> {noformat}
> Datacenter: abssl_dev_tap_ttc
> =
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- AddressLoad Tokens Owns (effective) Host ID
> Rack
> UN 10.109.6.153 94.27 KiB 16 100.0%
> 130e59d2-2a9a-4039-a42f-deb20afcf288 rack1
> UN 10.109.45.8104.43 KiB 16 100.0%
> 35274a2c-f915-4308-9981-d207a4e2108f rack1
> UN 10.109.66.149 104.23 KiB 16 100.0%
> ea0151bc-fb6c-425d-af42-75c10e52f941 rack1
> Datacenter: abssl_dev_tap_tte
> =
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- AddressLoad Tokens Owns (effective) Host ID
> Rack
> UN 10.110.4.110 104.44 KiB 16 100.0%
> fd4a9fa8-f2a9-494c-afb8-7cb8a08c7554 rack1
> UN 10.110.44.220 99.33 KiB 16 100.0%
> f1dc35c0-a1c2-45fe-9f65-b1cc3d7f6947 rack1
> UN 10.110.49.242 65.57 KiB 16 100.0%
> 72bc4ae5-876d-4d0a-91ac-6cf8b531b4dd rack1
> dbaasprod-ca-abssl-de-393671-v001-yqlvf:~# nodetool describecluster
> Cluster Information:
> Name: abssl_dev
> Snitch: org.apache.cassandra.locator.GossipingPropertyFileSnitch
> DynamicEndPointSnitch: enabled
> Partitioner: org.apache.cassandra.dht.Murmur3Partitioner
> Schema versions:
> f68fbc0c-c9d6-3709-8075-c5a0d74192f2: [10.110.4.110,
> 10.110.44.220, 10.109.6.153, 10.109.45.8, 10.109.66.149, 10.110.49.242]
> {noformat}
> During the upgrade, we re-run the pipeline in which we get new server (with
> different IP) that will have Cassandra 4.0.4 binary.
> Disk '/data' (contains data files, commitlogs etc.) will get detached from
> the old server and get attached to the new server.
> This process works fine on non-SSL cluster but when we perform this on SSL
> cluster, new node stops communicating with the rest of the nodes.
> In this example, after upgrade, node 10.110.4.110 got replaced with new
> server with new IP 10.110.44.207.
> *Output from 3.11.4 node:*
> {noformat}
> dbaasprod-ca-abssl-dc-437097-v001-7mump:~# hostname -i
> 10.109.6.153
>
[jira] [Commented] (CASSANDRA-18075) Upgraded (C* 4.0.4) node stops communicating with older version (3.11.4) nodes during upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-18075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17641463#comment-17641463
]
Brandon Williams commented on CASSANDRA-18075:
--
I don't think we would expect anything to change by explicitly settings those
two properties since they match the defaults, my greater point was that you
should use a minimally modified yaml so that it's directly comparable to the
stock yaml. That said, you are missing enable_legacy_ssl_storage_port this
time.
bq. So, something is going wrong (probably a bug) with SSL cluster
communication during the upgrade process
Here is a passing test that covers this scenario:
https://ci-cassandra.apache.org/job/Cassandra-3.0/313/testReport/dtest-upgrade.upgrade_tests.upgrade_through_versions_test/TestUpgrade_indev_3_0_x_To_indev_4_0_x/test_parallel_upgrade_with_internode_ssl/
> Upgraded (C* 4.0.4) node stops communicating with older version (3.11.4)
> nodes during upgrade
> -
>
> Key: CASSANDRA-18075
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18075
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Encryption
>Reporter: Alaykumar Barochia
>Priority: Normal
> Attachments: cassandra-env.sh_3114, cassandra-env.sh_404,
> cassandra.yaml_10.110.44.207_explicitely_set_port,
> cassandra.yaml_10.110.49.242_explicitely_set_port, cassandra.yaml_3114,
> cassandra.yaml_404, system.log_10.110.44.207,
> system.log_10.110.44.207_after_explicitely_set_port,
> system.log_10.110.49.242_after_explicitely_set_port
>
>
> We are testing upgrade from Cassandra 3.11.4 to 4.0.4 on our test cluster
> which is SSL enabled and facing an issue.
> Our cluster size is 3x3.
> {noformat}
> Datacenter: abssl_dev_tap_ttc
> =
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- AddressLoad Tokens Owns (effective) Host ID
> Rack
> UN 10.109.6.153 94.27 KiB 16 100.0%
> 130e59d2-2a9a-4039-a42f-deb20afcf288 rack1
> UN 10.109.45.8104.43 KiB 16 100.0%
> 35274a2c-f915-4308-9981-d207a4e2108f rack1
> UN 10.109.66.149 104.23 KiB 16 100.0%
> ea0151bc-fb6c-425d-af42-75c10e52f941 rack1
> Datacenter: abssl_dev_tap_tte
> =
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- AddressLoad Tokens Owns (effective) Host ID
> Rack
> UN 10.110.4.110 104.44 KiB 16 100.0%
> fd4a9fa8-f2a9-494c-afb8-7cb8a08c7554 rack1
> UN 10.110.44.220 99.33 KiB 16 100.0%
> f1dc35c0-a1c2-45fe-9f65-b1cc3d7f6947 rack1
> UN 10.110.49.242 65.57 KiB 16 100.0%
> 72bc4ae5-876d-4d0a-91ac-6cf8b531b4dd rack1
> dbaasprod-ca-abssl-de-393671-v001-yqlvf:~# nodetool describecluster
> Cluster Information:
> Name: abssl_dev
> Snitch: org.apache.cassandra.locator.GossipingPropertyFileSnitch
> DynamicEndPointSnitch: enabled
> Partitioner: org.apache.cassandra.dht.Murmur3Partitioner
> Schema versions:
> f68fbc0c-c9d6-3709-8075-c5a0d74192f2: [10.110.4.110,
> 10.110.44.220, 10.109.6.153, 10.109.45.8, 10.109.66.149, 10.110.49.242]
> {noformat}
> During the upgrade, we re-run the pipeline in which we get new server (with
> different IP) that will have Cassandra 4.0.4 binary.
> Disk '/data' (contains data files, commitlogs etc.) will get detached from
> the old server and get attached to the new server.
> This process works fine on non-SSL cluster but when we perform this on SSL
> cluster, new node stops communicating with the rest of the nodes.
> In this example, after upgrade, node 10.110.4.110 got replaced with new
> server with new IP 10.110.44.207.
> *Output from 3.11.4 node:*
> {noformat}
> dbaasprod-ca-abssl-dc-437097-v001-7mump:~# hostname -i
> 10.109.6.153
> dbaasprod-ca-abssl-dc-437097-v001-7mump:~# java -version
> openjdk version "1.8.0_322"
> OpenJDK Runtime Environment (Temurin)(build 1.8.0_322-b06)
> OpenJDK 64-Bit Server VM (Temurin)(build 25.322-b06, mixed mode)
> dbaasprod-ca-abssl-dc-437097-v001-7mump:~# nodetool status
> Datacenter: abssl_dev_tap_ttc
> =
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- AddressLoad Tokens Owns (effective) Host ID
> Rack
> UN 10.109.6.153 135.24 KiB 16 100.0%
> 130e59d2-2a9a-4039-a42f-deb20afcf288 rack1
> UN 10.109.45.8135.35 KiB 16 100.0%
> 35274a2c-f915-4308-9981-d207a4e2108f rack1
> UN 10.109.66.149 135.25 KiB 16 100.0%
>
[jira] [Updated] (CASSANDRA-18023) Add option to print level with getsstables output
[ https://issues.apache.org/jira/browse/CASSANDRA-18023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18023: - Reviewers: Brandon Williams, Cheng Wang (was: Cheng Wang) > Add option to print level with getsstables output > - > > Key: CASSANDRA-18023 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18023 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Jordan West >Assignee: Jordan West >Priority: Normal > > A common operation is to pipe getsstables output to sstablemetadata to > determine the level. This adds friction to operations. Add an optional flag > to getsstables to print the level with data file path. -- 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-18023) Add option to print level with getsstables output
[ https://issues.apache.org/jira/browse/CASSANDRA-18023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17641456#comment-17641456 ] Brandon Williams commented on CASSANDRA-18023: -- Unfortunately there are a lot of failures in those runs, I think you need to rebase to pick up some recent circle changes and resubmit. > Add option to print level with getsstables output > - > > Key: CASSANDRA-18023 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18023 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Jordan West >Assignee: Jordan West >Priority: Normal > > A common operation is to pipe getsstables output to sstablemetadata to > determine the level. This adds friction to operations. Add an optional flag > to getsstables to print the level with data file path. -- 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] [Updated] (CASSANDRA-18083) snakeyaml-1.26.jar: CVE-2022-41854
[ https://issues.apache.org/jira/browse/CASSANDRA-18083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18083: - Test and Documentation Plan: run CI Status: Patch Available (was: Open) > snakeyaml-1.26.jar: CVE-2022-41854 > -- > > Key: CASSANDRA-18083 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18083 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > > https://nvd.nist.gov/vuln/detail/CVE-2022-41854 -- 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] [Updated] (CASSANDRA-16949) Fix flaky test org.apache.cassandra.transport.CQLConnectionTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh McKenzie updated CASSANDRA-16949:
--
Fix Version/s: 4.x
(was: 4.1)
> Fix flaky test org.apache.cassandra.transport.CQLConnectionTest
> ---
>
> Key: CASSANDRA-16949
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16949
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: David Capwell
>Priority: Normal
> Fix For: 4.x
>
>
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/1037/workflows/c728d370-49b9-41aa-bdfb-8c41cf0355d8/jobs/6577/parallel-runs/3
> {code}
> [junit-timeout] Testsuite: org.apache.cassandra.transport.CQLConnectionTest
> [junit-timeout] Testsuite: org.apache.cassandra.transport.CQLConnectionTest
> Tests run: 9, Failures: 4, Errors: 0, Skipped: 0, Time elapsed: 12.926 sec
> [junit-timeout]
> [junit-timeout] Testcase:
> handleCorruptionOfLargeMessageFrame(org.apache.cassandra.transport.CQLConnectionTest):
> FAILED
> [junit-timeout] null
> [junit-timeout] junit.framework.AssertionFailedError
> [junit-timeout] at
> org.apache.cassandra.transport.CQLConnectionTest.testFrameCorruption(CQLConnectionTest.java:484)
> [junit-timeout] at
> org.apache.cassandra.transport.CQLConnectionTest.testFrameCorruption(CQLConnectionTest.java:446)
> [junit-timeout] at
> org.apache.cassandra.transport.CQLConnectionTest.handleCorruptionOfLargeMessageFrame(CQLConnectionTest.java:217)
> [junit-timeout] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [junit-timeout] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout]
> [junit-timeout]
> [junit-timeout] Testcase:
> testNegativeEnvelopeBodySize(org.apache.cassandra.transport.CQLConnectionTest):
> FAILED
> [junit-timeout] expected:<[]0L> but was:<[52424]0L>
> [junit-timeout] junit.framework.AssertionFailedError: expected:<[]0L> but
> was:<[52424]0L>
> [junit-timeout] at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> [junit-timeout] at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> [junit-timeout] at
> org.apache.cassandra.transport.CQLConnectionTest$AllocationObserver.lambda$verifier$0(CQLConnectionTest.java:850)
> [junit-timeout] at
> org.apache.cassandra.transport.CQLConnectionTest.testFrameCorruption(CQLConnectionTest.java:492)
> [junit-timeout] at
> org.apache.cassandra.transport.CQLConnectionTest.testFrameCorruption(CQLConnectionTest.java:446)
> [junit-timeout] at
> org.apache.cassandra.transport.CQLConnectionTest.testNegativeEnvelopeBodySize(CQLConnectionTest.java:326)
> [junit-timeout] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [junit-timeout] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout]
> [junit-timeout]
> [junit-timeout] Testcase:
> testUnrecoverableMessageDecodingErrors(org.apache.cassandra.transport.CQLConnectionTest):
>FAILED
> [junit-timeout] expected:<[]0L> but was:<[52424]0L>
> [junit-timeout] junit.framework.AssertionFailedError: expected:<[]0L> but
> was:<[52424]0L>
> [junit-timeout] at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> [junit-timeout] at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> [junit-timeout] at
> org.apache.cassandra.transport.CQLConnectionTest$AllocationObserver.lambda$verifier$0(CQLConnectionTest.java:850)
> [junit-timeout] at
> org.apache.cassandra.transport.CQLConnectionTest.testFrameCorruption(CQLConnectionTest.java:492)
> [junit-timeout] at
> org.apache.cassandra.transport.CQLConnectionTest.testUnrecoverableMessageDecodingErrors(CQLConnectionTest.java:392)
> [junit-timeout] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>
[jira] [Commented] (CASSANDRA-18042) Implement a guardrail for not having zero default ttl on tables with TWCS
[
https://issues.apache.org/jira/browse/CASSANDRA-18042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17641454#comment-17641454
]
Andres de la Peña commented on CASSANDRA-18042:
---
Whatever we choose, I think that it would be desirable to keep the
{{feature_enabled}} format for the hard limit because of the point mentioned on
[this
comment|https://issues.apache.org/jira/browse/CASSANDRA-18042?focusedCommentId=17640654=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17640654].
Long story short, we already have properties with that format on 4.1 and not
changing the convention would allow us to add soft/warn limits to them.
Both
{code}
feature_warned: true
feature_enabled: true
{code}
and
{code}
feature_warn_if_enabled: true
feature_enabled: true
{code}
work for me.
> Implement a guardrail for not having zero default ttl on tables with TWCS
> -
>
> Key: CASSANDRA-18042
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18042
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Guardrails, Legacy/Core
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 3h
> Remaining Estimate: 0h
>
> A user was surprised that his data have not started to expire after 90 days
> on his TWCS, he noticed that default_time_to_live on the table was set to 0
> (by accident from his side) and inserts were using TTL = 0 too.
> It is questionable why it it possible to create a table with TWCS and enable
> a user to specify default_time_to_live to be zero.
> On the other hand, I would argue that having default_time_to_live set to 0 on
> TWCS does not necessarily mean that such combination is illegal. It is about
> people just using that with advantage very often so tables are compacted away
> nicely. However, that does not have to mean that they could not use it with
> 0. But I yet have to see a use-case where TWCS was used and default ttl was
> set to 0 on purpose. Merely looking into Cassandra codebase, there are only
> cases when this parameter is not 0.
> There are three approaches:
> 1) just reject such statements (for CreateTable and AlterTable statements)
> where default_time_to_live = 0
> 2) Implement a guardrail for 1) so it can be enabled / disabled on demand
> 3) Leave possibility to set default_time_to_live to 0 on a table but make a
> guardrail for UpdateStatement so it might reject queries for tables with
> default_time_to_live is zero and for which its TTL (on that update statement)
> is set to 0 too.
> I would be careful about making the current configuration illegal because of
> backward compatibility. For that reason 2) makes the most sense to me.
> Maybe implementing 3) would make sense as well. There might be a table which
> has default ttl set to 0 as it expects a user to supply TTL every time.
> However, as it is not currently enforced anywhere, a client might still
> insert TTLs to be set to 0 even by accident.
> POC for 2) is here
> https://github.com/instaclustr/cassandra/commit/0b4dcc3d3deeffa393c02a3b80e27482007f9579
--
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] [Comment Edited] (CASSANDRA-18042) Implement a guardrail for not having zero default ttl on tables with TWCS
[ https://issues.apache.org/jira/browse/CASSANDRA-18042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17641446#comment-17641446 ] Brandon Williams edited comment on CASSANDRA-18042 at 11/30/22 4:59 PM: I wasn't hugely fond of 'fail_enabled' either. but now I think this makes the two properties sound like there's a dependency relationship...warn_if_enabled, and then plain 'enabled'. was (Author: brandon.williams): I think that works, I wasn't hugely fond of 'fail_enabled' either. > Implement a guardrail for not having zero default ttl on tables with TWCS > - > > Key: CASSANDRA-18042 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18042 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Guardrails, Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.x > > Time Spent: 3h > Remaining Estimate: 0h > > A user was surprised that his data have not started to expire after 90 days > on his TWCS, he noticed that default_time_to_live on the table was set to 0 > (by accident from his side) and inserts were using TTL = 0 too. > It is questionable why it it possible to create a table with TWCS and enable > a user to specify default_time_to_live to be zero. > On the other hand, I would argue that having default_time_to_live set to 0 on > TWCS does not necessarily mean that such combination is illegal. It is about > people just using that with advantage very often so tables are compacted away > nicely. However, that does not have to mean that they could not use it with > 0. But I yet have to see a use-case where TWCS was used and default ttl was > set to 0 on purpose. Merely looking into Cassandra codebase, there are only > cases when this parameter is not 0. > There are three approaches: > 1) just reject such statements (for CreateTable and AlterTable statements) > where default_time_to_live = 0 > 2) Implement a guardrail for 1) so it can be enabled / disabled on demand > 3) Leave possibility to set default_time_to_live to 0 on a table but make a > guardrail for UpdateStatement so it might reject queries for tables with > default_time_to_live is zero and for which its TTL (on that update statement) > is set to 0 too. > I would be careful about making the current configuration illegal because of > backward compatibility. For that reason 2) makes the most sense to me. > Maybe implementing 3) would make sense as well. There might be a table which > has default ttl set to 0 as it expects a user to supply TTL every time. > However, as it is not currently enforced anywhere, a client might still > insert TTLs to be set to 0 even by accident. > POC for 2) is here > https://github.com/instaclustr/cassandra/commit/0b4dcc3d3deeffa393c02a3b80e27482007f9579 -- 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-18042) Implement a guardrail for not having zero default ttl on tables with TWCS
[ https://issues.apache.org/jira/browse/CASSANDRA-18042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17641446#comment-17641446 ] Brandon Williams commented on CASSANDRA-18042: -- I think that works, I wasn't hugely fond of 'fail_enabled' either. > Implement a guardrail for not having zero default ttl on tables with TWCS > - > > Key: CASSANDRA-18042 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18042 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Guardrails, Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.x > > Time Spent: 3h > Remaining Estimate: 0h > > A user was surprised that his data have not started to expire after 90 days > on his TWCS, he noticed that default_time_to_live on the table was set to 0 > (by accident from his side) and inserts were using TTL = 0 too. > It is questionable why it it possible to create a table with TWCS and enable > a user to specify default_time_to_live to be zero. > On the other hand, I would argue that having default_time_to_live set to 0 on > TWCS does not necessarily mean that such combination is illegal. It is about > people just using that with advantage very often so tables are compacted away > nicely. However, that does not have to mean that they could not use it with > 0. But I yet have to see a use-case where TWCS was used and default ttl was > set to 0 on purpose. Merely looking into Cassandra codebase, there are only > cases when this parameter is not 0. > There are three approaches: > 1) just reject such statements (for CreateTable and AlterTable statements) > where default_time_to_live = 0 > 2) Implement a guardrail for 1) so it can be enabled / disabled on demand > 3) Leave possibility to set default_time_to_live to 0 on a table but make a > guardrail for UpdateStatement so it might reject queries for tables with > default_time_to_live is zero and for which its TTL (on that update statement) > is set to 0 too. > I would be careful about making the current configuration illegal because of > backward compatibility. For that reason 2) makes the most sense to me. > Maybe implementing 3) would make sense as well. There might be a table which > has default ttl set to 0 as it expects a user to supply TTL every time. > However, as it is not currently enforced anywhere, a client might still > insert TTLs to be set to 0 even by accident. > POC for 2) is here > https://github.com/instaclustr/cassandra/commit/0b4dcc3d3deeffa393c02a3b80e27482007f9579 -- 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-18042) Implement a guardrail for not having zero default ttl on tables with TWCS
[
https://issues.apache.org/jira/browse/CASSANDRA-18042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17641441#comment-17641441
]
Josh McKenzie commented on CASSANDRA-18042:
---
1. I'm terrible at naming things. Grain of salt me.
2. I think it's worth a little extra time here since we're establishing a
precedent (warn / fail threshold on feature flagged things)
Brandon's point I think needs a touch further tweaking; the "_fail_enabled" is
confusing to me.
The format of:
{quote}
feature_warn_if_enabled: true
feature_enabled: true
{quote}
while not internally "consistent" with one another makes the most clear logical
sense to me.
So we'd concretely have:
{quote}
zero_ttl_on_twcs_warn_if_enabled: true
zero_ttl_on_twcs_enabled: true
{quote}
> Implement a guardrail for not having zero default ttl on tables with TWCS
> -
>
> Key: CASSANDRA-18042
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18042
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Guardrails, Legacy/Core
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 3h
> Remaining Estimate: 0h
>
> A user was surprised that his data have not started to expire after 90 days
> on his TWCS, he noticed that default_time_to_live on the table was set to 0
> (by accident from his side) and inserts were using TTL = 0 too.
> It is questionable why it it possible to create a table with TWCS and enable
> a user to specify default_time_to_live to be zero.
> On the other hand, I would argue that having default_time_to_live set to 0 on
> TWCS does not necessarily mean that such combination is illegal. It is about
> people just using that with advantage very often so tables are compacted away
> nicely. However, that does not have to mean that they could not use it with
> 0. But I yet have to see a use-case where TWCS was used and default ttl was
> set to 0 on purpose. Merely looking into Cassandra codebase, there are only
> cases when this parameter is not 0.
> There are three approaches:
> 1) just reject such statements (for CreateTable and AlterTable statements)
> where default_time_to_live = 0
> 2) Implement a guardrail for 1) so it can be enabled / disabled on demand
> 3) Leave possibility to set default_time_to_live to 0 on a table but make a
> guardrail for UpdateStatement so it might reject queries for tables with
> default_time_to_live is zero and for which its TTL (on that update statement)
> is set to 0 too.
> I would be careful about making the current configuration illegal because of
> backward compatibility. For that reason 2) makes the most sense to me.
> Maybe implementing 3) would make sense as well. There might be a table which
> has default ttl set to 0 as it expects a user to supply TTL every time.
> However, as it is not currently enforced anywhere, a client might still
> insert TTLs to be set to 0 even by accident.
> POC for 2) is here
> https://github.com/instaclustr/cassandra/commit/0b4dcc3d3deeffa393c02a3b80e27482007f9579
--
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-18042) Implement a guardrail for not having zero default ttl on tables with TWCS
[ https://issues.apache.org/jira/browse/CASSANDRA-18042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17641427#comment-17641427 ] Brandon Williams commented on CASSANDRA-18042: -- I think it would be a little more consistent with other properties as: zero_ttl_on_twcs_warn_enabled: true zero_ttl_on_twcs_fail_enabled: true My reasoning being that 'warn_threshold' and 'fail_threshold' are common, but since these aren't thresholds we go with the established 'enabled' instead. > Implement a guardrail for not having zero default ttl on tables with TWCS > - > > Key: CASSANDRA-18042 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18042 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Guardrails, Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.x > > Time Spent: 3h > Remaining Estimate: 0h > > A user was surprised that his data have not started to expire after 90 days > on his TWCS, he noticed that default_time_to_live on the table was set to 0 > (by accident from his side) and inserts were using TTL = 0 too. > It is questionable why it it possible to create a table with TWCS and enable > a user to specify default_time_to_live to be zero. > On the other hand, I would argue that having default_time_to_live set to 0 on > TWCS does not necessarily mean that such combination is illegal. It is about > people just using that with advantage very often so tables are compacted away > nicely. However, that does not have to mean that they could not use it with > 0. But I yet have to see a use-case where TWCS was used and default ttl was > set to 0 on purpose. Merely looking into Cassandra codebase, there are only > cases when this parameter is not 0. > There are three approaches: > 1) just reject such statements (for CreateTable and AlterTable statements) > where default_time_to_live = 0 > 2) Implement a guardrail for 1) so it can be enabled / disabled on demand > 3) Leave possibility to set default_time_to_live to 0 on a table but make a > guardrail for UpdateStatement so it might reject queries for tables with > default_time_to_live is zero and for which its TTL (on that update statement) > is set to 0 too. > I would be careful about making the current configuration illegal because of > backward compatibility. For that reason 2) makes the most sense to me. > Maybe implementing 3) would make sense as well. There might be a table which > has default ttl set to 0 as it expects a user to supply TTL every time. > However, as it is not currently enforced anywhere, a client might still > insert TTLs to be set to 0 even by accident. > POC for 2) is here > https://github.com/instaclustr/cassandra/commit/0b4dcc3d3deeffa393c02a3b80e27482007f9579 -- 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-18083) snakeyaml-1.26.jar: CVE-2022-41854
[ https://issues.apache.org/jira/browse/CASSANDRA-18083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17641422#comment-17641422 ] Brandon Williams commented on CASSANDRA-18083: -- 3.0 also has (for snakeyaml): https://nvd.nist.gov/vuln/detail/CVE-2022-38752 https://nvd.nist.gov/vuln/detail/CVE-2022-38751 https://nvd.nist.gov/vuln/detail/CVE-2022-38750 https://nvd.nist.gov/vuln/detail/CVE-2022-41854 https://nvd.nist.gov/vuln/detail/CVE-2022-25857 https://nvd.nist.gov/vuln/detail/CVE-2022-38749 which are all also about parsing untrusted files resulting in a DOS, a scenario that is not relevant to Apache Cassandra, and these are already suppressed in 3.11 and up. ||Branch||Circle|| |[3.0|https://github.com/driftx/cassandra/tree/CASSANDRA-18083-3.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/708/workflows/1868a814-1682-4e7b-8d7f-5662d45b516b]| |[3.11|https://github.com/driftx/cassandra/tree/CASSANDRA-18083-3.11]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/706/workflows/b1fe40aa-2683-42cd-b8d4-4626b9694796]| |[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-18083-4.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/705/workflows/3b65caca-fa1a-4003-b7b0-45011abaf88a], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/705/workflows/3b65caca-fa1a-4003-b7b0-45011abaf88a]| |[4.1|https://github.com/driftx/cassandra/tree/CASSANDRA-18083-4.1]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/709/workflows/75af59b5-f999-4ca7-84a0-ff40622de955], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/709/workflows/c7f2cde8-44c4-4a6a-af44-1952b4b5f8af]| |[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-18083-trunk]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/707/workflows/ba4212f2-1654-4902-9f63-e0e0643f9cd6], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/707/workflows/789cc3a6-e7ad-4432-b435-ba3584c553c1]| > snakeyaml-1.26.jar: CVE-2022-41854 > -- > > Key: CASSANDRA-18083 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18083 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > > https://nvd.nist.gov/vuln/detail/CVE-2022-41854 -- 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] [Comment Edited] (CASSANDRA-17925) Java source code should have sorted imports as defined in the codestyle
[
https://issues.apache.org/jira/browse/CASSANDRA-17925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17641410#comment-17641410
]
Josh McKenzie edited comment on CASSANDRA-17925 at 11/30/22 3:51 PM:
-
{quote}I am not sure if it is possible to just warn and not error out in
practice
{quote}
Thinking configuring
[severity|https://checkstyle.org/property_types.html#SeverityLevel] for the
check.
was (Author: jmckenzie):
{quote}I am not sure if it is possible to just warn and not error out in
practice
{quote}
Thinking configuring
[severity|https://checkstyle.sourceforge.io/config.html#Severity] for the check.
> Java source code should have sorted imports as defined in the codestyle
> ---
>
> Key: CASSANDRA-17925
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17925
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Stefan Miklosovic
>Assignee: Maxim Muzafarov
>Priority: Normal
>
> After we cleaned all unused imports in CASSANDRA-17876, there is one more
> task remaining to be done - to add checkstyle for imports order and enforce
> this on build time.
> When the project is imported into IDEA, there is a helper target on Ant
> called "generate-idea-files". ide/idea/codeStyleSettings.xml contains this:
> {code:java}
>
>
>
>
>
> static="false" />
> static="false" />
> static="false" />
> static="false" />
>
>
>
>
>
>
>
>
> {code}
> This code style is also mentioned in the web page here (minus some details
> which are present in above configuration snippet but not on the web page):
> [https://cassandra.apache.org/_/development/code_style.html] (at the very
> bottom).
> However, when one runs "Optimise imports" in the context menu after
> right-clicking on org.cassandra.apache package, it will refactor the imports
> and it results with hundreds of changes.
> This means that the source code, as-is, does not adhere to the self-imposed
> code style we ship for IDEA.
> If we fix this, we should add checkstyle for it like this:
> {code:java}
>
>value="/(^java\.|javax)/,/(com\.google\.common|org\.apache\.log4j|org\.apache\.commons|org\.cliffc\.high_scale_lib|org\.junit|org\.slf4j)/"/>
>
>
>
>
>
>
> {code}
> This checkstyle on import order will pass on the source code we run the
> import optimization in the context menu on.
> There is also no enforcement on "all star" imports (org.some.pkg.*).
> Checkstyle has specific module for this:
> [https://checkstyle.org/config_imports.html#AvoidStarImport]
> I propose we should stop to use all-star imports. Same argument holds as
> described there: Rationale: Importing all classes from a package or static
> members from a class leads to tight coupling between packages or classes and
> might lead to problems when a new version of a library introduces name
> clashes.
> This should be applied to test checktyle as well and the source code should
> be refactored on imports too.
> This should be done on cassandra-4.1 as well as for trunk.
--
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-17925) Java source code should have sorted imports as defined in the codestyle
[
https://issues.apache.org/jira/browse/CASSANDRA-17925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17641410#comment-17641410
]
Josh McKenzie commented on CASSANDRA-17925:
---
{quote}I am not sure if it is possible to just warn and not error out in
practice
{quote}
Thinking configuring
[severity|https://checkstyle.sourceforge.io/config.html#Severity] for the check.
> Java source code should have sorted imports as defined in the codestyle
> ---
>
> Key: CASSANDRA-17925
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17925
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Stefan Miklosovic
>Assignee: Maxim Muzafarov
>Priority: Normal
>
> After we cleaned all unused imports in CASSANDRA-17876, there is one more
> task remaining to be done - to add checkstyle for imports order and enforce
> this on build time.
> When the project is imported into IDEA, there is a helper target on Ant
> called "generate-idea-files". ide/idea/codeStyleSettings.xml contains this:
> {code:java}
>
>
>
>
>
> static="false" />
> static="false" />
> static="false" />
> static="false" />
>
>
>
>
>
>
>
>
> {code}
> This code style is also mentioned in the web page here (minus some details
> which are present in above configuration snippet but not on the web page):
> [https://cassandra.apache.org/_/development/code_style.html] (at the very
> bottom).
> However, when one runs "Optimise imports" in the context menu after
> right-clicking on org.cassandra.apache package, it will refactor the imports
> and it results with hundreds of changes.
> This means that the source code, as-is, does not adhere to the self-imposed
> code style we ship for IDEA.
> If we fix this, we should add checkstyle for it like this:
> {code:java}
>
>value="/(^java\.|javax)/,/(com\.google\.common|org\.apache\.log4j|org\.apache\.commons|org\.cliffc\.high_scale_lib|org\.junit|org\.slf4j)/"/>
>
>
>
>
>
>
> {code}
> This checkstyle on import order will pass on the source code we run the
> import optimization in the context menu on.
> There is also no enforcement on "all star" imports (org.some.pkg.*).
> Checkstyle has specific module for this:
> [https://checkstyle.org/config_imports.html#AvoidStarImport]
> I propose we should stop to use all-star imports. Same argument holds as
> described there: Rationale: Importing all classes from a package or static
> members from a class leads to tight coupling between packages or classes and
> might lead to problems when a new version of a library introduces name
> clashes.
> This should be applied to test checktyle as well and the source code should
> be refactored on imports too.
> This should be done on cassandra-4.1 as well as for trunk.
--
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-18042) Implement a guardrail for not having zero default ttl on tables with TWCS
[
https://issues.apache.org/jira/browse/CASSANDRA-18042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17641407#comment-17641407
]
Josh McKenzie commented on CASSANDRA-18042:
---
{code}
zero_ttl_on_twcs_warned: true
zero_ttl_on_twcs_enabled: true
{code}
Works for me.
> Implement a guardrail for not having zero default ttl on tables with TWCS
> -
>
> Key: CASSANDRA-18042
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18042
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Guardrails, Legacy/Core
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 3h
> Remaining Estimate: 0h
>
> A user was surprised that his data have not started to expire after 90 days
> on his TWCS, he noticed that default_time_to_live on the table was set to 0
> (by accident from his side) and inserts were using TTL = 0 too.
> It is questionable why it it possible to create a table with TWCS and enable
> a user to specify default_time_to_live to be zero.
> On the other hand, I would argue that having default_time_to_live set to 0 on
> TWCS does not necessarily mean that such combination is illegal. It is about
> people just using that with advantage very often so tables are compacted away
> nicely. However, that does not have to mean that they could not use it with
> 0. But I yet have to see a use-case where TWCS was used and default ttl was
> set to 0 on purpose. Merely looking into Cassandra codebase, there are only
> cases when this parameter is not 0.
> There are three approaches:
> 1) just reject such statements (for CreateTable and AlterTable statements)
> where default_time_to_live = 0
> 2) Implement a guardrail for 1) so it can be enabled / disabled on demand
> 3) Leave possibility to set default_time_to_live to 0 on a table but make a
> guardrail for UpdateStatement so it might reject queries for tables with
> default_time_to_live is zero and for which its TTL (on that update statement)
> is set to 0 too.
> I would be careful about making the current configuration illegal because of
> backward compatibility. For that reason 2) makes the most sense to me.
> Maybe implementing 3) would make sense as well. There might be a table which
> has default ttl set to 0 as it expects a user to supply TTL every time.
> However, as it is not currently enforced anywhere, a client might still
> insert TTLs to be set to 0 even by accident.
> POC for 2) is here
> https://github.com/instaclustr/cassandra/commit/0b4dcc3d3deeffa393c02a3b80e27482007f9579
--
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-18083) snakeyaml-1.26.jar: CVE-2022-41854
[ https://issues.apache.org/jira/browse/CASSANDRA-18083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17641394#comment-17641394 ] Brandon Williams commented on CASSANDRA-18083: -- bq. Those using Snakeyaml to parse untrusted YAML files may be vulnerable to Denial of Service attacks (DOS). If the parser is running on user supplied input, an attacker may supply content that causes the parser to crash by stack overflow. I don't think we need to worry about this, similar to CASSANDRA-17907. > snakeyaml-1.26.jar: CVE-2022-41854 > -- > > Key: CASSANDRA-18083 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18083 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > > https://nvd.nist.gov/vuln/detail/CVE-2022-41854 -- 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] [Updated] (CASSANDRA-18081) CVE's in Cassandra 4.0.7
[ https://issues.apache.org/jira/browse/CASSANDRA-18081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18081: - Resolution: Duplicate Status: Resolved (was: Triage Needed) > CVE's in Cassandra 4.0.7 > > > Key: CASSANDRA-18081 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18081 > Project: Cassandra > Issue Type: Bug >Reporter: Gaurav Gupta >Priority: Normal > > Below CVE's are available in Latest Cassandra version. > CVE-2022-42004,CVE-2022-25857,CVE-2020-11612,CVE-2022-42003 > Above CVE's are part of component maven:org.yaml:snakeyaml, > maven:io.netty:netty-all, maven:com.fasterxml.jackson.core:jackson-databind -- 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-18081) CVE's in Cassandra 4.0.7
[ https://issues.apache.org/jira/browse/CASSANDRA-18081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17641386#comment-17641386 ] Brandon Williams commented on CASSANDRA-18081: -- These: https://nvd.nist.gov/vuln/detail/CVE-2022-42003 https://nvd.nist.gov/vuln/detail/CVE-2022-42004 https://nvd.nist.gov/vuln/detail/CVE-2022-25857 are [already suppressed|https://github.com/apache/cassandra/blob/cassandra-4.0/.build/dependency-check-suppressions.xml] so I'm not going to look. That leaves: https://nvd.nist.gov/vuln/detail/CVE-2020-11612 which I don't think we use, but also doesn't show up in the OWASP scan so I'm not concerned. What does show in the scan however is: https://nvd.nist.gov/vuln/detail/CVE-2022-41854 Which looks like another snakeyaml local DOS we can suppress and I've created CASSANDRA-18083 to handle. > CVE's in Cassandra 4.0.7 > > > Key: CASSANDRA-18081 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18081 > Project: Cassandra > Issue Type: Bug >Reporter: Gaurav Gupta >Priority: Normal > > Below CVE's are available in Latest Cassandra version. > CVE-2022-42004,CVE-2022-25857,CVE-2020-11612,CVE-2022-42003 > Above CVE's are part of component maven:org.yaml:snakeyaml, > maven:io.netty:netty-all, maven:com.fasterxml.jackson.core:jackson-databind -- 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] [Updated] (CASSANDRA-18083) snakeyaml-1.26.jar: CVE-2022-41854
[ https://issues.apache.org/jira/browse/CASSANDRA-18083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18083: - Bug Category: Parent values: Security(12985)Level 1 values: Denial of Service(13001) Complexity: Normal Component/s: Dependencies Discovered By: User Report Severity: Normal Assignee: Brandon Williams Status: Open (was: Triage Needed) > snakeyaml-1.26.jar: CVE-2022-41854 > -- > > Key: CASSANDRA-18083 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18083 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > > https://nvd.nist.gov/vuln/detail/CVE-2022-41854 -- 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] [Updated] (CASSANDRA-18083) snakeyaml-1.26.jar: CVE-2022-41854
[ https://issues.apache.org/jira/browse/CASSANDRA-18083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18083: - Fix Version/s: 3.0.x 3.11.x 4.0.x 4.1.x 4.x > snakeyaml-1.26.jar: CVE-2022-41854 > -- > > Key: CASSANDRA-18083 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18083 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > > https://nvd.nist.gov/vuln/detail/CVE-2022-41854 -- 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] [Created] (CASSANDRA-18083) snakeyaml-1.26.jar: CVE-2022-41854
Brandon Williams created CASSANDRA-18083: Summary: snakeyaml-1.26.jar: CVE-2022-41854 Key: CASSANDRA-18083 URL: https://issues.apache.org/jira/browse/CASSANDRA-18083 Project: Cassandra Issue Type: Bug Reporter: Brandon Williams https://nvd.nist.gov/vuln/detail/CVE-2022-41854 -- 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-18078) Consider removing MAXWRITETIME function
[
https://issues.apache.org/jira/browse/CASSANDRA-18078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17641381#comment-17641381
]
Andres de la Peña commented on CASSANDRA-18078:
---
Thanks for the feedback.
In the latter example, the assumption is that the user knows the type of the
column and will only use {{collection_max}} function when dealing with
collections:
{code:java}
> CREATE TABLE test.max_ts ( a int PRIMARY KEY, b int, c list );
> INSERT INTO max_ts ( a, b, c ) VALUES ( 1, 1, [1, 2, 3] );
> SELECT a, b, c, writetime(b), collection_max(writetime(c)) FROM max_ts WHERE
> a = 1;
a | b | c | writetime(b) | system.collection_max(writetime(c))
---+---+---+--+-
1 | 1 | [1, 2, 3] | 1669820977087840 |1669820977087840
{code}
But I guess we can also consider that applying collection functions to a not
collection type is equivalent to applying them to a singleton collection. So,
for example, collection_max(2) = collection_max([2]) = 2. I have added a commit
to the PR that does exactly that:
||PR||CI||
|[trunk|https://github.com/apache/cassandra/pull/2032]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/2521/workflows/e15c8205-bbf8-45a8-bc0f-eceb8eec9fca]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/2521/workflows/28c80583-3c80-4255-9a42-38344c8ca14b]|
> Consider removing MAXWRITETIME function
> ---
>
> Key: CASSANDRA-18078
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18078
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Andres de la Peña
>Priority: Normal
> Fix For: 4.2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> CASSANDRA-17425 added a new {{MAXWRITETIME}} function that allows to retrieve
> the maximum timestamp of a multi-cell column. For example:
> {code:java}
> > CREATE TABLE t (k int PRIMARY KEY, v set);
> > INSERT INTO t (k, v) VALUES (1, {1, 2}) USING TIMESTAMP 100;
> > UPDATE t USING TIMESTAMP 200 SET v += {3} WHERE k=1;
> > SELECT maxwritetime(v) FROM t;
> maxwritetime(v)
> -
> 200
> {code}
> Later, CASSANDRA-8877 added the means to retrieve the write times and TTLs of
> each of the cells in a multi-cell column:
> {code:java}
> > SELECT writetime(v) FROM t;
> writetime(v)
> -
> [100, 100, 200]
> > SELECT writetime(v[1]) FROM t;
> writetime(v[1])
> -
> 100
> {code}
> Quite recently, CASSANDRA-18060 has added generic CQL functions to get the
> min and max items in a collection. Those functions can be used in combination
> with the classic {{writetime}} function to get the same results as the new
> {{maxwritetime}} function:
> {code:java}
> > SELECT collection_max(writetime(v)) FROM t;
> system.collection_max(writetime(v))
> -
> 200
> {code}
> Those new functions can also be used to get the min timestamp, or the min/max
> TTL, for which there isn't a specific function:
> {code:java}
> SELECT collection_min(writetime(v)) FROM t;
> SELECT collection_max(writetime(v)) FROM t;
> SELECT collection_avg(writetime(v)) FROM t;
> SELECT collection_min(ttl(v)) FROM t;
> SELECT collection_max(ttl(v)) FROM t;
> SELECT collection_avg(ttl(v)) FROM t;
> {code}
> I think this makes the new {{maxwritetime}} mostly redundant, since the new
> functions can achieve the same results in a more generic way. Since the new
> {{maxwritetime}} function is only on trunk, we should consider whether we
> want to remove it in favour of the generic functions.
--
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-18082) Broken link in the documentation
[ https://issues.apache.org/jira/browse/CASSANDRA-18082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17641358#comment-17641358 ] Brandon Williams commented on CASSANDRA-18082: -- wrong one, you want [~erickramirezau] > Broken link in the documentation > > > Key: CASSANDRA-18082 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18082 > Project: Cassandra > Issue Type: Bug > Components: Documentation/Website >Reporter: Tibor Repasi >Priority: Normal > > At the page Cassandra > [Operating|https://cassandra.apache.org/doc/latest/cassandra/operating/index.html], > the link to Snitches on the left menu-pane is broken for at least latest and > 4.0 versions. As [~brandonwilliams] pointed out, the page which should be > linked still exists at > [https://cassandra.apache.org/doc/latest/cassandra/architecture/snitch.html]. -- 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-18082) Broken link in the documentation
[ https://issues.apache.org/jira/browse/CASSANDRA-18082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17641300#comment-17641300 ] Stefan Miklosovic commented on CASSANDRA-18082: --- kindly pinging [~eric_sv] > Broken link in the documentation > > > Key: CASSANDRA-18082 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18082 > Project: Cassandra > Issue Type: Bug > Components: Documentation/Website >Reporter: Tibor Repasi >Priority: Normal > > At the page Cassandra > [Operating|https://cassandra.apache.org/doc/latest/cassandra/operating/index.html], > the link to Snitches on the left menu-pane is broken for at least latest and > 4.0 versions. As [~brandonwilliams] pointed out, the page which should be > linked still exists at > [https://cassandra.apache.org/doc/latest/cassandra/architecture/snitch.html]. -- 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] [Created] (CASSANDRA-18082) Broken link in the documentation
Tibor Repasi created CASSANDRA-18082: Summary: Broken link in the documentation Key: CASSANDRA-18082 URL: https://issues.apache.org/jira/browse/CASSANDRA-18082 Project: Cassandra Issue Type: Bug Components: Documentation/Website Reporter: Tibor Repasi At the page Cassandra [Operating|https://cassandra.apache.org/doc/latest/cassandra/operating/index.html], the link to Snitches on the left menu-pane is broken for at least latest and 4.0 versions. As [~brandonwilliams] pointed out, the page which should be linked still exists at [https://cassandra.apache.org/doc/latest/cassandra/architecture/snitch.html]. -- 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
[cassandra-website] branch asf-staging updated (cf40fc5a -> 5250a2aa)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard cf40fc5a generate docs for 6f603a2c new 5250a2aa generate docs for 6f603a2c This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (cf40fc5a) \ N -- N -- N refs/heads/asf-staging (5250a2aa) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: site-ui/build/ui-bundle.zip | Bin 4970139 -> 4970139 bytes 1 file changed, 0 insertions(+), 0 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18079) Log better message when nodetool commands can not get probe.getOwnershipWithPort()
[
https://issues.apache.org/jira/browse/CASSANDRA-18079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18079:
--
Test and Documentation Plan: clean CI
Status: Patch Available (was: In Progress)
PR is here: [https://github.com/apache/cassandra/pull/2036]
I changed in similar fashion all commands same logic occurs (status, ring,
describecluster).
I also fixed some minor code issues while I was on it.
Maybe [~yifanc] [~brandon.williams] would fancy to take a look at this
low-hanger? I see that [~ycai] was involved in CASSANDRA-16057 which is somehow
tangential to this.
> Log better message when nodetool commands can not get
> probe.getOwnershipWithPort()
> --
>
> Key: CASSANDRA-18079
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18079
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Tools
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Low
> Labels: lhf, nodetool
> Fix For: 4.x
>
>
> When status, ring or describecluster nodetool commands are executed while a
> node which is queried is not fully bootstrapped / started, it can throw this
> exception:
> {code:java}
> cassandra_node_4 | error: No nodes present in the cluster. Has this node
> finished starting up?
> cassandra_node_4 | -- StackTrace --
> cassandra_node_4 | java.lang.RuntimeException: No nodes present in the
> cluster. Has this node finished starting up?
> cassandra_node_4 | at
> org.apache.cassandra.dht.Murmur3Partitioner.describeOwnership(Murmur3Partitioner.java:303)
> cassandra_node_4 | at
> org.apache.cassandra.service.StorageService.getOwnershipWithPort(StorageService.java:5751)
> cassandra_node_4 | at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> cassandra_node_4 | at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> cassandra_node_4 | at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> cassandra_node_4 | at
> java.base/java.lang.reflect.Method.invoke(Method.java:566)
> cassandra_node_4 | at
> sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
> cassandra_node_4 | at
> jdk.internal.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)
> cassandra_node_4 | at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> cassandra_node_4 | at
> java.base/java.lang.reflect.Method.invoke(Method.java:566)
> cassandra_node_4 | at
> java.base/sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:260)
> cassandra_node_4 | at
> java.management/com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> cassandra_node_4 | at
> java.management/com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> cassandra_node_4 | at
> java.management/com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> cassandra_node_4 | at
> java.management/com.sun.jmx.mbeanserver.PerInterface.getAttribute(PerInterface.java:83)
> cassandra_node_4 | at
> java.management/com.sun.jmx.mbeanserver.MBeanSupport.getAttribute(MBeanSupport.java:206)
> cassandra_node_4 | at
> java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:641)
> cassandra_node_4 | at
> java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:678)
> cassandra_node_4 | at
> java.management/com.sun.jmx.remote.security.MBeanServerAccessController.getAttribute(MBeanServerAccessController.java:320)
> cassandra_node_4 | at
> java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1443)
> cassandra_node_4 | at
> java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1307)
> cassandra_node_4 | at
> java.base/java.security.AccessController.doPrivileged(Native Method)
> cassandra_node_4 | at
> java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1406)
> cassandra_node_4 | at
> java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl.getAttribute(RMIConnectionImpl.java:637)
> cassandra_node_4 | at
> java.base/jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> cassandra_node_4 | at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> cassandra_node_4 | at
>
[jira] [Updated] (CASSANDRA-18079) Log better message when nodetool commands can not get probe.getOwnershipWithPort()
[
https://issues.apache.org/jira/browse/CASSANDRA-18079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18079:
--
Change Category: Operability
Complexity: Low Hanging Fruit
Fix Version/s: 4.x
Assignee: Stefan Miklosovic
Priority: Low (was: Normal)
Status: Open (was: Triage Needed)
> Log better message when nodetool commands can not get
> probe.getOwnershipWithPort()
> --
>
> Key: CASSANDRA-18079
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18079
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Tools
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Low
> Labels: lhf, nodetool
> Fix For: 4.x
>
>
> When status, ring or describecluster nodetool commands are executed while a
> node which is queried is not fully bootstrapped / started, it can throw this
> exception:
> {code:java}
> cassandra_node_4 | error: No nodes present in the cluster. Has this node
> finished starting up?
> cassandra_node_4 | -- StackTrace --
> cassandra_node_4 | java.lang.RuntimeException: No nodes present in the
> cluster. Has this node finished starting up?
> cassandra_node_4 | at
> org.apache.cassandra.dht.Murmur3Partitioner.describeOwnership(Murmur3Partitioner.java:303)
> cassandra_node_4 | at
> org.apache.cassandra.service.StorageService.getOwnershipWithPort(StorageService.java:5751)
> cassandra_node_4 | at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> cassandra_node_4 | at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> cassandra_node_4 | at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> cassandra_node_4 | at
> java.base/java.lang.reflect.Method.invoke(Method.java:566)
> cassandra_node_4 | at
> sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
> cassandra_node_4 | at
> jdk.internal.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)
> cassandra_node_4 | at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> cassandra_node_4 | at
> java.base/java.lang.reflect.Method.invoke(Method.java:566)
> cassandra_node_4 | at
> java.base/sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:260)
> cassandra_node_4 | at
> java.management/com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> cassandra_node_4 | at
> java.management/com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> cassandra_node_4 | at
> java.management/com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> cassandra_node_4 | at
> java.management/com.sun.jmx.mbeanserver.PerInterface.getAttribute(PerInterface.java:83)
> cassandra_node_4 | at
> java.management/com.sun.jmx.mbeanserver.MBeanSupport.getAttribute(MBeanSupport.java:206)
> cassandra_node_4 | at
> java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:641)
> cassandra_node_4 | at
> java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:678)
> cassandra_node_4 | at
> java.management/com.sun.jmx.remote.security.MBeanServerAccessController.getAttribute(MBeanServerAccessController.java:320)
> cassandra_node_4 | at
> java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1443)
> cassandra_node_4 | at
> java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1307)
> cassandra_node_4 | at
> java.base/java.security.AccessController.doPrivileged(Native Method)
> cassandra_node_4 | at
> java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1406)
> cassandra_node_4 | at
> java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl.getAttribute(RMIConnectionImpl.java:637)
> cassandra_node_4 | at
> java.base/jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> cassandra_node_4 | at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> cassandra_node_4 | at
> java.base/java.lang.reflect.Method.invoke(Method.java:566)
> cassandra_node_4 | at
> java.rmi/sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:359)
> cassandra_node_4 | at
> java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:200)
> cassandra_node_4 | at
>
[jira] [Commented] (CASSANDRA-18058) In-memory index and query path
[ https://issues.apache.org/jira/browse/CASSANDRA-18058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17641261#comment-17641261 ] Andres de la Peña commented on CASSANDRA-18058: --- Thanks, I'll take a look at the changes. I keep leaving batches of comments on the PR, I'll have completed the first review round very soon. So far it's looking good :) > In-memory index and query path > -- > > Key: CASSANDRA-18058 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18058 > Project: Cassandra > Issue Type: New Feature > Components: Feature/SAI >Reporter: Mike Adamson >Assignee: Mike Adamson >Priority: Normal > Fix For: 5.x > > > An in-memory index using the in-memory trie structure introduced with > CASSANDRA-17240 along with a query path implementation to perform index > queries from the in-memory index. -- 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] [Updated] (CASSANDRA-18058) In-memory index and query path
[ https://issues.apache.org/jira/browse/CASSANDRA-18058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andres de la Peña updated CASSANDRA-18058: -- Status: Review In Progress (was: Patch Available) > In-memory index and query path > -- > > Key: CASSANDRA-18058 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18058 > Project: Cassandra > Issue Type: New Feature > Components: Feature/SAI >Reporter: Mike Adamson >Assignee: Mike Adamson >Priority: Normal > Fix For: 5.x > > > An in-memory index using the in-memory trie structure introduced with > CASSANDRA-17240 along with a query path implementation to perform index > queries from the in-memory index. -- 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-18081) CVE's in Cassandra 4.0.7
[ https://issues.apache.org/jira/browse/CASSANDRA-18081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17641256#comment-17641256 ] Stefan Miklosovic commented on CASSANDRA-18081: --- For example this [https://nvd.nist.gov/vuln/detail/CVE-2020-11612] I do not think we are using "ZlibDecoders" in Cassandra, (I might be wrong though). [https://nvd.nist.gov/vuln/detail/CVE-2022-25857] What is the attack vector here? [https://nvd.nist.gov/vuln/detail/CVE-2022-42004] again I do not think we use this [https://nvd.nist.gov/vuln/detail/CVE-2022-42003] I do not think we use "UNWRAP_SINGLE_VALUE_ARRAYS" feature which enables this attack. > CVE's in Cassandra 4.0.7 > > > Key: CASSANDRA-18081 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18081 > Project: Cassandra > Issue Type: Bug >Reporter: Gaurav Gupta >Priority: Normal > > Below CVE's are available in Latest Cassandra version. > CVE-2022-42004,CVE-2022-25857,CVE-2020-11612,CVE-2022-42003 > Above CVE's are part of component maven:org.yaml:snakeyaml, > maven:io.netty:netty-all, maven:com.fasterxml.jackson.core:jackson-databind -- 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-18081) CVE's in Cassandra 4.0.7
[ https://issues.apache.org/jira/browse/CASSANDRA-18081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17641253#comment-17641253 ] Gaurav Gupta commented on CASSANDRA-18081: -- What do you mean it doesn't apply to you? These are part of dependency maven:org.yaml:snakeyaml, maven:io.netty:netty-all, maven:com.fasterxml.jackson.core:jackson-databind > CVE's in Cassandra 4.0.7 > > > Key: CASSANDRA-18081 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18081 > Project: Cassandra > Issue Type: Bug >Reporter: Gaurav Gupta >Priority: Normal > > Below CVE's are available in Latest Cassandra version. > CVE-2022-42004,CVE-2022-25857,CVE-2020-11612,CVE-2022-42003 > Above CVE's are part of component maven:org.yaml:snakeyaml, > maven:io.netty:netty-all, maven:com.fasterxml.jackson.core:jackson-databind -- 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-18081) CVE's in Cassandra 4.0.7
[ https://issues.apache.org/jira/browse/CASSANDRA-18081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17641252#comment-17641252 ] Stefan Miklosovic commented on CASSANDRA-18081: --- I think none of them apply to us. Maybe [~brandon.williams] could double check here? [https://nvd.nist.gov/vuln/detail/CVE-2022-42003] [https://nvd.nist.gov/vuln/detail/CVE-2022-42004] [https://nvd.nist.gov/vuln/detail/CVE-2022-25857] [https://nvd.nist.gov/vuln/detail/CVE-2020-11612] > CVE's in Cassandra 4.0.7 > > > Key: CASSANDRA-18081 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18081 > Project: Cassandra > Issue Type: Bug >Reporter: Gaurav Gupta >Priority: Normal > > Below CVE's are available in Latest Cassandra version. > CVE-2022-42004,CVE-2022-25857,CVE-2020-11612,CVE-2022-42003 > Above CVE's are part of component maven:org.yaml:snakeyaml, > maven:io.netty:netty-all, maven:com.fasterxml.jackson.core:jackson-databind -- 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] [Created] (CASSANDRA-18081) CVE's in Cassandra 4.0.7
Gaurav Gupta created CASSANDRA-18081: Summary: CVE's in Cassandra 4.0.7 Key: CASSANDRA-18081 URL: https://issues.apache.org/jira/browse/CASSANDRA-18081 Project: Cassandra Issue Type: Bug Reporter: Gaurav Gupta Below CVE's are available in Latest Cassandra version. CVE-2022-42004,CVE-2022-25857,CVE-2020-11612,CVE-2022-42003 Above CVE's are part of component maven:org.yaml:snakeyaml, maven:io.netty:netty-all, maven:com.fasterxml.jackson.core:jackson-databind -- 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
[cassandra-website] branch asf-staging updated (136bdfad -> cf40fc5a)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git omit 136bdfad generate docs for 6f603a2c new cf40fc5a generate docs for 6f603a2c This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (136bdfad) \ N -- N -- N refs/heads/asf-staging (cf40fc5a) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: site-ui/build/ui-bundle.zip | Bin 4970139 -> 4970139 bytes 1 file changed, 0 insertions(+), 0 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18058) In-memory index and query path
[ https://issues.apache.org/jira/browse/CASSANDRA-18058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17641240#comment-17641240 ] Mike Adamson commented on CASSANDRA-18058: -- [~adelapena] Please note that I have pushed a commit to help resolve some of the dtest failures. The SecondaryIndexManager was attempting to propagate index states when the Gossiper was not enabled. This resulted in exceptions being added to the logs which were being picked up as test failures. > In-memory index and query path > -- > > Key: CASSANDRA-18058 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18058 > Project: Cassandra > Issue Type: New Feature > Components: Feature/SAI >Reporter: Mike Adamson >Assignee: Mike Adamson >Priority: Normal > Fix For: 5.x > > > An in-memory index using the in-memory trie structure introduced with > CASSANDRA-17240 along with a query path implementation to perform index > queries from the in-memory index. -- 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-18080) BLOG - Summit 2023 registrations open
[
https://issues.apache.org/jira/browse/CASSANDRA-18080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17641231#comment-17641231
]
Erick Ramirez commented on CASSANDRA-18080:
---
I’ve completed final verification in staging and [published to
production|https://github.com/apache/cassandra-website#merging-asf-staging-to-asf-site]:
{noformat}
$ git branch
* trunk
$ git fetch origin
$ git checkout asf-site
Branch ‘asf-site’ set up to track remote branch ‘asf-site’ from ‘origin’.
Switched to a new branch ‘asf-site’
$ git branch
* asf-site
trunk
$ git reset --hard origin/asf-staging
HEAD is now at 136bdfad generate docs for 6f603a2c
$ git push -f origin asf-site
Total 0 (delta 0), reused 0 (delta 0)
To [https://github.com/apache/cassandra-website.git]
+ af806a6f...136bdfad asf-site -> asf-site (forced update)
{noformat}
The new blog post is now live on the site –
https://cassandra.apache.org/_/blog/Summit-2023-Registrations-Open.html
> BLOG - Summit 2023 registrations open
> -
>
> Key: CASSANDRA-18080
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18080
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Blog
>Reporter: Erick Ramirez
>Assignee: Erick Ramirez
>Priority: Normal
> Fix For: NA
>
> Attachments: c18080-01-blog-index.png, c18080-02-blog-post.png
>
>
> Announcing registrations open for the 2023 Apache Cassandra Summit.
> Blog draft -
> https://docs.google.com/document/d/1eX_4bu0DnQ_henIxN0BRQ_2R4j5xADlAkGYGozsGB-Q/edit
--
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
[cassandra-website] branch asf-site updated (af806a6f -> 136bdfad)
This is an automated email from the ASF dual-hosted git repository.
erickramirezau pushed a change to branch asf-site
in repository https://gitbox.apache.org/repos/asf/cassandra-website.git
discard af806a6f generate docs for 0834e145
add 6f603a2c BLOG - Summit 2023 registrations open
add 136bdfad generate docs for 6f603a2c
This update added new revisions after undoing existing revisions.
That is to say, some revisions that were in the old version of the
branch are not in the new version. This situation occurs
when a user --force pushes a change and generates a repository
containing something like this:
* -- * -- B -- O -- O -- O (af806a6f)
\
N -- N -- N refs/heads/asf-site (136bdfad)
You should already have received notification emails for all of the O
revisions, and so the following emails describe only the N revisions
from the common base, B.
Any revisions marked "omit" are not gone; other references still
refer to them. Any revisions marked "discard" are gone forever.
No new revisions were added by this update.
Summary of changes:
.../_/_images/blog}/summit-2023-1080x391.png | Bin
content/_/blog.html| 24 ++
...23.html => Summit-2023-Registrations-Open.html} | 49 +++--
content/search-index.js| 2 +-
.../ROOT/images/blog}/summit-2023-1080x391.png | Bin
site-content/source/modules/ROOT/pages/blog.adoc | 24 ++
.../pages/blog/Summit-2023-Registrations-Open.adoc | 36 +++
site-ui/build/ui-bundle.zip| Bin 4970139 -> 4970139
bytes
8 files changed, 120 insertions(+), 15 deletions(-)
copy {site-ui/src/img => content/_/_images/blog}/summit-2023-1080x391.png
(100%)
copy content/_/blog/{Cassandra-Summit-Returns-in-2023.html =>
Summit-2023-Registrations-Open.html} (84%)
copy {site-ui/src/img =>
site-content/source/modules/ROOT/images/blog}/summit-2023-1080x391.png (100%)
create mode 100644
site-content/source/modules/ROOT/pages/blog/Summit-2023-Registrations-Open.adoc
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18080) BLOG - Summit 2023 registrations open
[ https://issues.apache.org/jira/browse/CASSANDRA-18080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17641229#comment-17641229 ] Erick Ramirez commented on CASSANDRA-18080: --- The build completed in 14 minutes and the new blog post is now in staging – https://cassandra.staged.apache.org/_/blog/Summit-2023-Registrations-Open.html > BLOG - Summit 2023 registrations open > - > > Key: CASSANDRA-18080 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18080 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Erick Ramirez >Assignee: Erick Ramirez >Priority: Normal > Fix For: NA > > Attachments: c18080-01-blog-index.png, c18080-02-blog-post.png > > > Announcing registrations open for the 2023 Apache Cassandra Summit. > Blog draft - > https://docs.google.com/document/d/1eX_4bu0DnQ_henIxN0BRQ_2R4j5xADlAkGYGozsGB-Q/edit -- 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
[cassandra-website] branch asf-staging updated (b32374e8 -> 136bdfad)
This is an automated email from the ASF dual-hosted git repository.
git-site-role pushed a change to branch asf-staging
in repository https://gitbox.apache.org/repos/asf/cassandra-website.git
discard b32374e8 generate docs for 0834e145
add 6f603a2c BLOG - Summit 2023 registrations open
new 136bdfad generate docs for 6f603a2c
This update added new revisions after undoing existing revisions.
That is to say, some revisions that were in the old version of the
branch are not in the new version. This situation occurs
when a user --force pushes a change and generates a repository
containing something like this:
* -- * -- B -- O -- O -- O (b32374e8)
\
N -- N -- N refs/heads/asf-staging (136bdfad)
You should already have received notification emails for all of the O
revisions, and so the following emails describe only the N revisions
from the common base, B.
Any revisions marked "omit" are not gone; other references still
refer to them. Any revisions marked "discard" are gone forever.
The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails. The revisions
listed as "add" were already present in the repository and have only
been added to this reference.
Summary of changes:
.../_/_images/blog}/summit-2023-1080x391.png | Bin
content/_/blog.html| 24 ++
...23.html => Summit-2023-Registrations-Open.html} | 49 +++--
content/search-index.js| 2 +-
.../ROOT/images/blog}/summit-2023-1080x391.png | Bin
site-content/source/modules/ROOT/pages/blog.adoc | 24 ++
.../pages/blog/Summit-2023-Registrations-Open.adoc | 36 +++
site-ui/build/ui-bundle.zip| Bin 4970139 -> 4970139
bytes
8 files changed, 120 insertions(+), 15 deletions(-)
copy {site-ui/src/img => content/_/_images/blog}/summit-2023-1080x391.png
(100%)
copy content/_/blog/{Cassandra-Summit-Returns-in-2023.html =>
Summit-2023-Registrations-Open.html} (84%)
copy {site-ui/src/img =>
site-content/source/modules/ROOT/images/blog}/summit-2023-1080x391.png (100%)
create mode 100644
site-content/source/modules/ROOT/pages/blog/Summit-2023-Registrations-Open.adoc
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18080) BLOG - Summit 2023 registrations open
[
https://issues.apache.org/jira/browse/CASSANDRA-18080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17641222#comment-17641222
]
Erick Ramirez commented on CASSANDRA-18080:
---
The website content is getting built in staging:
||Branch||PR||Commit||Build||
|{{trunk}}|[#198|https://github.com/apache/cassandra-website/pull/198]|[6f603a2|https://github.com/apache/cassandra-website/commit/6f603a2cdb7c4f5983cc6d6dcacdbdbd4d5ff2b1]|[#787|https://ci-cassandra.apache.org/job/cassandra-website/791/]|
> BLOG - Summit 2023 registrations open
> -
>
> Key: CASSANDRA-18080
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18080
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Blog
>Reporter: Erick Ramirez
>Assignee: Erick Ramirez
>Priority: Normal
> Fix For: NA
>
> Attachments: c18080-01-blog-index.png, c18080-02-blog-post.png
>
>
> Announcing registrations open for the 2023 Apache Cassandra Summit.
> Blog draft -
> https://docs.google.com/document/d/1eX_4bu0DnQ_henIxN0BRQ_2R4j5xADlAkGYGozsGB-Q/edit
--
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] [Updated] (CASSANDRA-18080) BLOG - Summit 2023 registrations open
[
https://issues.apache.org/jira/browse/CASSANDRA-18080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Ramirez updated CASSANDRA-18080:
--
Source Control Link:
https://github.com/apache/cassandra-website/commit/6f603a2cdb7c4f5983cc6d6dcacdbdbd4d5ff2b1
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed:
||Branch||PR||Commit||
|{{trunk}}|[#198|https://github.com/apache/cassandra-website/pull/198]|[6f603a2|https://github.com/apache/cassandra-website/commit/6f603a2cdb7c4f5983cc6d6dcacdbdbd4d5ff2b1]|
> BLOG - Summit 2023 registrations open
> -
>
> Key: CASSANDRA-18080
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18080
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Blog
>Reporter: Erick Ramirez
>Assignee: Erick Ramirez
>Priority: Normal
> Fix For: NA
>
> Attachments: c18080-01-blog-index.png, c18080-02-blog-post.png
>
>
> Announcing registrations open for the 2023 Apache Cassandra Summit.
> Blog draft -
> https://docs.google.com/document/d/1eX_4bu0DnQ_henIxN0BRQ_2R4j5xADlAkGYGozsGB-Q/edit
--
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
[cassandra-website] branch trunk updated: BLOG - Summit 2023 registrations open
This is an automated email from the ASF dual-hosted git repository. erickramirezau pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra-website.git The following commit(s) were added to refs/heads/trunk by this push: new 6f603a2c BLOG - Summit 2023 registrations open 6f603a2c is described below commit 6f603a2cdb7c4f5983cc6d6dcacdbdbd4d5ff2b1 Author: Erick Ramirez AuthorDate: Wed Nov 30 17:02:43 2022 +1100 BLOG - Summit 2023 registrations open patch by Erick Ramirez, Chris Thornett; reviewed by Michael Semb Wever for CASSANDRA-18080 --- .../ROOT/images/blog/summit-2023-1080x391.png | Bin 0 -> 309382 bytes site-content/source/modules/ROOT/pages/blog.adoc | 24 ++ .../pages/blog/Summit-2023-Registrations-Open.adoc | 36 + 3 files changed, 60 insertions(+) diff --git a/site-content/source/modules/ROOT/images/blog/summit-2023-1080x391.png b/site-content/source/modules/ROOT/images/blog/summit-2023-1080x391.png new file mode 100644 index ..45692a4b Binary files /dev/null and b/site-content/source/modules/ROOT/images/blog/summit-2023-1080x391.png differ diff --git a/site-content/source/modules/ROOT/pages/blog.adoc b/site-content/source/modules/ROOT/pages/blog.adoc index 78fa7373..2822cd63 100644 --- a/site-content/source/modules/ROOT/pages/blog.adoc +++ b/site-content/source/modules/ROOT/pages/blog.adoc @@ -8,6 +8,30 @@ NOTES FOR CONTENT CREATORS - Replace post tile, date, description and link to you post. +//start card +[openblock,card shadow relative test] + +[openblock,card-header] +-- +[discrete] +=== Cassandra Summit 2023 registration is now open +[discrete] + November 30, 2022 +-- +[openblock,card-content] +-- +Registrations for Cassandra Summit 2023 are open. Book your place for this not to be missed two-day event in San Jose, California. + +[openblock,card-btn card-btn--blog] + +[.btn.btn--alt] +xref:blog/Summit-2023-Registrations-Open.adoc[Read More] + + +-- + +//end card + //start card [openblock,card shadow relative test] diff --git a/site-content/source/modules/ROOT/pages/blog/Summit-2023-Registrations-Open.adoc b/site-content/source/modules/ROOT/pages/blog/Summit-2023-Registrations-Open.adoc new file mode 100644 index ..ea9a0302 --- /dev/null +++ b/site-content/source/modules/ROOT/pages/blog/Summit-2023-Registrations-Open.adoc @@ -0,0 +1,36 @@ += Registration is now open for Cassandra Summit 2023 +:page-layout: single-post +:page-role: blog-post +:page-post-date: Nov 30, 2022 +:page-post-author: Cassandra Community +:description: Cassandra Summit 2023 registration open + +:!figure-caption: +image::blog/summit-2023-1080x391.png[link="https://events.linuxfoundation.org/cassandra-summit/",window="_blank; alt="Cassandra Summit 2023"] + +=== Registration is now open for https://events.linuxfoundation.org/cassandra-summit/[Cassandra Summit 2023]! + +Book in for https://events.linuxfoundation.org/cassandra-summit/attend/about/[the biggest festival celebrating the world of Apache Cassandra], the community and the thriving ecosystem around our popular massively scalable open source NoSQL distributed database. + +This not to be missed two-day celebration will be held in San Jose, CA between March 13-14, 2023. We will also have pre-event training and activities running on March 12. + + https://events.linuxfoundation.org/cassandra-summit/register/[Click here to register today!^] + +https://events.linuxfoundation.org/cassandra-summit/[Cassandra Summit^] is an opportunity to connect with thousands of database practitioners, developers, engineers and influencers, and to take a deep dive into Apache Cassandra, and discover how it powers global enterprises every day (and night). + +The summit is a vendor-neutral gathering where attendees will share and learn best practices & use cases, celebrate contributors and users, build relationships, and learn about the latest advancements in the Apache Cassandra ecosystem. + +Details of the keynotes, hands-on labs, sessions will be announced very soon and will focus on the following topics: + +* Cloud-native deployments and strategies +* Developing applications with Cassandra +* Ecosystem tools that leverage Cassandra +* Use cases and sharing about best practices +* What’s coming for future Cassandra versions + + +And, of course, there will be the popular hallway track! + +There will be a lot of fun, memorable things to do with experiential, interactive exhibits and entertainment breaks. + +Come celebrate what we’ve achieved and come build with us. https://events.linuxfoundation.org/cassandra-summit/register/[Join us and register today^] as we discover what’s coming next on the Cassandra journey! - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail:
[jira] [Updated] (CASSANDRA-18080) BLOG - Summit 2023 registrations open
[ https://issues.apache.org/jira/browse/CASSANDRA-18080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-18080: -- Status: Ready to Commit (was: Review In Progress) Thanks again for the quick review, [[~mck] ] ! > BLOG - Summit 2023 registrations open > - > > Key: CASSANDRA-18080 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18080 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Erick Ramirez >Assignee: Erick Ramirez >Priority: Normal > Fix For: NA > > Attachments: c18080-01-blog-index.png, c18080-02-blog-post.png > > > Announcing registrations open for the 2023 Apache Cassandra Summit. > Blog draft - > https://docs.google.com/document/d/1eX_4bu0DnQ_henIxN0BRQ_2R4j5xADlAkGYGozsGB-Q/edit -- 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] [Updated] (CASSANDRA-18080) BLOG - Summit 2023 registrations open
[ https://issues.apache.org/jira/browse/CASSANDRA-18080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-18080: -- Reviewers: Michael Semb Wever Status: Review In Progress (was: Patch Available) > BLOG - Summit 2023 registrations open > - > > Key: CASSANDRA-18080 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18080 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Erick Ramirez >Assignee: Erick Ramirez >Priority: Normal > Fix For: NA > > Attachments: c18080-01-blog-index.png, c18080-02-blog-post.png > > > Announcing registrations open for the 2023 Apache Cassandra Summit. > Blog draft - > https://docs.google.com/document/d/1eX_4bu0DnQ_henIxN0BRQ_2R4j5xADlAkGYGozsGB-Q/edit -- 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
[cassandra-website] branch asf-staging updated (e5d329b5 -> b32374e8)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard e5d329b5 generate docs for 0834e145 new b32374e8 generate docs for 0834e145 This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (e5d329b5) \ N -- N -- N refs/heads/asf-staging (b32374e8) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: content/search-index.js | 2 +- site-ui/build/ui-bundle.zip | Bin 4970139 -> 4970139 bytes 2 files changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18042) Implement a guardrail for not having zero default ttl on tables with TWCS
[ https://issues.apache.org/jira/browse/CASSANDRA-18042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17641153#comment-17641153 ] Stefan Miklosovic commented on CASSANDRA-18042: --- [~jmckenzie] [~bschoeni] everybody comfortable with the latest changes? > Implement a guardrail for not having zero default ttl on tables with TWCS > - > > Key: CASSANDRA-18042 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18042 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Guardrails, Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.x > > Time Spent: 3h > Remaining Estimate: 0h > > A user was surprised that his data have not started to expire after 90 days > on his TWCS, he noticed that default_time_to_live on the table was set to 0 > (by accident from his side) and inserts were using TTL = 0 too. > It is questionable why it it possible to create a table with TWCS and enable > a user to specify default_time_to_live to be zero. > On the other hand, I would argue that having default_time_to_live set to 0 on > TWCS does not necessarily mean that such combination is illegal. It is about > people just using that with advantage very often so tables are compacted away > nicely. However, that does not have to mean that they could not use it with > 0. But I yet have to see a use-case where TWCS was used and default ttl was > set to 0 on purpose. Merely looking into Cassandra codebase, there are only > cases when this parameter is not 0. > There are three approaches: > 1) just reject such statements (for CreateTable and AlterTable statements) > where default_time_to_live = 0 > 2) Implement a guardrail for 1) so it can be enabled / disabled on demand > 3) Leave possibility to set default_time_to_live to 0 on a table but make a > guardrail for UpdateStatement so it might reject queries for tables with > default_time_to_live is zero and for which its TTL (on that update statement) > is set to 0 too. > I would be careful about making the current configuration illegal because of > backward compatibility. For that reason 2) makes the most sense to me. > Maybe implementing 3) would make sense as well. There might be a table which > has default ttl set to 0 as it expects a user to supply TTL every time. > However, as it is not currently enforced anywhere, a client might still > insert TTLs to be set to 0 even by accident. > POC for 2) is here > https://github.com/instaclustr/cassandra/commit/0b4dcc3d3deeffa393c02a3b80e27482007f9579 -- 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
