[jira] [Comment Edited] (CASSANDRA-17212) Migrate threshold for minimum keyspace replication factor to guardrails
[
https://issues.apache.org/jira/browse/CASSANDRA-17212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480345#comment-17480345
]
Caleb Rackliffe edited comment on CASSANDRA-17212 at 1/22/22, 4:47 AM:
---
bq. To me grouping based off feature is the only way for a config to actually
be "discoverable", pulling bits and pieces out to other places because they are
"limits" would always break this in my mind.
Agreed, but the logical conclusion of that feels like eventually dismembering
the top-level {{guardrails}} element in the current/trunk config. (I'm fine w/
this, to be clear.)
bq. Can we move this conversation/decision to its own JIRA/CEP that we vote on;
I feel that an extension to an existing feature isn't the best place for such
discussion. If you want to take on this work, I will support you.
Either way, we're going to be forced to continue this discussion for some
things like CASSANDRA-17148. Looking at the example snippet you've posted
above, I think it would make a lot of sense to have the {{track_warnings}} bits
under a top-level {{query}} element. (We might say the same for
CASSANDRA-17188.) I'm writing up the skeleton of a new Jira that deals w/ the
overall structure of the config, and we can have a few proposals up there
shortly. Would it be feasible to converge on a specific-enough long-term plan
after some discussion there quickly enough to allow CASSANDRA-17148, et al. to
proceed coherently without too much delay?
was (Author: maedhroz):
bq. To me grouping based off feature is the only way for a config to actually
be "discoverable", pulling bits and pieces out to other places because they are
"limits" would always break this in my mind.
Agreed, but the logical conclusion of that feels like eventually dismembering
the top-level {{guardrails}} element in the current/trunk config. (I'm fine w/
this, to be clear.)
bq. Can we move this conversation/decision to its own JIRA/CEP that we vote on;
I feel that an extension to an existing feature isn't the best place for such
discussion. If you want to take on this work, I will support you.
Either way, we're going to be forced to continue this discussion for some
things like CASSANDRA-17148. Looking at the example snippet you've posted
above, I think it would make a lot of sense to have the {{track_warnings}} bits
under a top-level {{query}} element. (We might say the same for
CASSANDRA-17188.) I'm up the skeleton of a new Jira that deals w/ the overall
structure of the config, and we can have a few proposals up there shortly.
Would it be feasible to converge on a specific-enough long-term plan after some
discussion there quickly enough to allow CASSANDRA-17148, et al. to proceed
without burdensome delay?
> Migrate threshold for minimum keyspace replication factor to guardrails
> ---
>
> Key: CASSANDRA-17212
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17212
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Priority: Normal
>
> The config property
> [{{minimum_keyspace_rf}}|https://github.com/apache/cassandra/blob/5fdadb25f95099b8945d9d9ee11d3e380d3867f4/conf/cassandra.yaml]
> that was added by CASSANDRA-14557 can be migrated to guardrails, for example:
> {code}
> guardrails:
> ...
> replication_factor:
> warn_threshold: 2
> abort_threshold: 3
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17212) Migrate threshold for minimum keyspace replication factor to guardrails
[
https://issues.apache.org/jira/browse/CASSANDRA-17212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480345#comment-17480345
]
Caleb Rackliffe commented on CASSANDRA-17212:
-
bq. To me grouping based off feature is the only way for a config to actually
be "discoverable", pulling bits and pieces out to other places because they are
"limits" would always break this in my mind.
Agreed, but the logical conclusion of that feels like eventually dismembering
the top-level {{guardrails}} element in the current/trunk config. (I'm fine w/
this, to be clear.)
bq. Can we move this conversation/decision to its own JIRA/CEP that we vote on;
I feel that an extension to an existing feature isn't the best place for such
discussion. If you want to take on this work, I will support you.
Either way, we're going to be forced to continue this discussion for some
things like CASSANDRA-17148. Looking at the example snippet you've posted
above, I think it would make a lot of sense to have the {{track_warnings}} bits
under a top-level {{query}} element. (We might say the same for
CASSANDRA-17188.) I'm up the skeleton of a new Jira that deals w/ the overall
structure of the config, and we can have a few proposals up there shortly.
Would it be feasible to converge on a specific-enough long-term plan after some
discussion there quickly enough to allow CASSANDRA-17148, et al. to proceed
without burdensome delay?
> Migrate threshold for minimum keyspace replication factor to guardrails
> ---
>
> Key: CASSANDRA-17212
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17212
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Priority: Normal
>
> The config property
> [{{minimum_keyspace_rf}}|https://github.com/apache/cassandra/blob/5fdadb25f95099b8945d9d9ee11d3e380d3867f4/conf/cassandra.yaml]
> that was added by CASSANDRA-14557 can be migrated to guardrails, for example:
> {code}
> guardrails:
> ...
> replication_factor:
> warn_threshold: 2
> abort_threshold: 3
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] (CASSANDRA-17148) Adapt track_warnings to Guardrails
[ https://issues.apache.org/jira/browse/CASSANDRA-17148 ] Caleb Rackliffe deleted comment on CASSANDRA-17148: - was (Author: maedhroz): The only thing I'm a little worried about is that it might be best to continue w/ this when CASSANDRA-15234 lands, and when we can resolve the structural conversation in CASSANDRA-17212? (The former will affect parameter naming and the latter configuration structure.) CC [~benedict] [~e.dimitrova] > Adapt track_warnings to Guardrails > -- > > Key: CASSANDRA-17148 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17148 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Andres de la Peña >Assignee: Andres de la Peña >Priority: Normal > > The purpose of this ticket is adapting the warnings added by CASSANDRA-16850 > to use the new Guardrails framework. This will involve extending the > framework to be able to propagate warnings and failures triggered on > replicas, taking advantage of the machinery added in that ticket. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17212) Migrate threshold for minimum keyspace replication factor to guardrails
[
https://issues.apache.org/jira/browse/CASSANDRA-17212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480321#comment-17480321
]
David Capwell commented on CASSANDRA-17212:
---
bq. Discoverability remains poor
To me grouping based off feature is the only way for a config to actually be
"discoverable", pulling bits and pieces out to other places because they are
"limits" would always break this in my mind. If I want to see how to configure
compaction, I would look at the configs I know are for compaction, but having
them scattered under "limits" (limits.concurrency.compaction,
limits.throughput.compaction, etc.) will always make this much harder to find
what actually impacts compaction... so if we want to solve for discovery, then
the only solution I can see is
{code}
compaction:
# configs related to compaction goes here; including limits
query:
# configs related to queries goes here; including limits
repair:
# configs related to repairs goes here; including limits
{code}
aka, group by feature/domain. So in this model a top level "limits" shouldn't
exist, if we want to solve for discoverability.
bq. but also this is almost inherently inconsistent as we are already grouping
under a concept heading by using limits. What about other row_index things that
aren't limits?
This actually reads like an argument in favor of a feature/domain grouping. We
had tried to talk about things in "[DISCUSS] Nested YAML configs for new
features" and thought that we were inline with your thinking; but seems that
isn't true.
Can we move this conversation/decision to its own JIRA/CEP that we vote on; I
feel that an extension to an existing feature isn't the best place for such
discussion. If you want to take on this work, I will support you.
> Migrate threshold for minimum keyspace replication factor to guardrails
> ---
>
> Key: CASSANDRA-17212
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17212
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Priority: Normal
>
> The config property
> [{{minimum_keyspace_rf}}|https://github.com/apache/cassandra/blob/5fdadb25f95099b8945d9d9ee11d3e380d3867f4/conf/cassandra.yaml]
> that was added by CASSANDRA-14557 can be migrated to guardrails, for example:
> {code}
> guardrails:
> ...
> replication_factor:
> warn_threshold: 2
> abort_threshold: 3
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17164) CEP-14: Paxos Improvements
[
https://issues.apache.org/jira/browse/CASSANDRA-17164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480311#comment-17480311
]
Benedict Elliott Smith edited comment on CASSANDRA-17164 at 1/22/22, 1:11 AM:
--
{quote}Why did you remove the logged warning about non linearizable reads?
{quote}
-Hopefully unintentionally...- Skimming your edits, it looks like this might
have been down to it having been duplicated, as it is also logged at
StorageProxy startup?
{quote} Why did you change type.decompose to type.decomposeUntyped in
makeInternalOptionsWithNowInSec?
{quote}
I think because dtest-api uses UUID and so a full migration to TimeUUID in all
places was kind of tricky, particularly for e.g. upgrade tests? It's hazy after
so long.
{quote}especially since it’s not checking for the partition key or static row
{quote}
I'm sure this is an oversight that's just not important for the use case -
which unfortunately I forget, so I'll just fix up this oversight.
{quote}should we log out of range requests in isInRangeAndShouldProcess?
{quote}
I think this is something that still hasn't taken full shape in OSS, so I'm not
sure what the right course of action is. Happy to do whatever you feel is
appropriate until a broader strategy is sorted out.
{quote}I’d prefer we use .equals instead of checking pointer equality here.
.equals should check for pointer equality, but will also guard against
unintended behavior
{quote}
For the assert? That would be fine, but it makes enforcing the identity
constraint harder with automated testing. In the other case, it's a pure
optimisation so better to keep IMO (else the benefit is likely lost)
{quote}WDYT about returning an empty collection if we don’t know about the
table?
{quote}
I'll have a ponder over the weekend.
{quote}WDYT about renaming rawTimestamp to uuidTimestamp? Raw is ambiguous
{quote}
WFM
{quote}These changes seem like they may have been for debugging purposes, are
they something that should be committed?
{quote}
Oops, yep.
{quote}A description and explanation of the upgrade procedure should also be
included, as well as an entry in NEWS.txt
{quote}
Yep, agreed.
Thanks!
was (Author: benedict):
{quote}Why did you remove the logged warning about non linearizable reads?
{quote}
Hopefully unintentionally...
{quote} Why did you change type.decompose to type.decomposeUntyped in
makeInternalOptionsWithNowInSec?
{quote}
I think because dtest-api uses UUID and so a full migration to TimeUUID in all
places was kind of tricky, particularly for e.g. upgrade tests? It's hazy after
so long.
{quote}especially since it’s not checking for the partition key or static row
{quote}
I'm sure this is an oversight that's just not important for the use case -
which unfortunately I forget, so I'll just fix up this oversight.
{quote}should we log out of range requests in isInRangeAndShouldProcess?
{quote}
I think this is something that still hasn't taken full shape in OSS, so I'm not
sure what the right course of action is. Happy to do whatever you feel is
appropriate until a broader strategy is sorted out.
{quote}I’d prefer we use .equals instead of checking pointer equality here.
.equals should check for pointer equality, but will also guard against
unintended behavior
{quote}
For the assert? That would be fine, but it makes enforcing the identity
constraint harder with automated testing. In the other case, it's a pure
optimisation so better to keep IMO (else the benefit is likely lost)
{quote}WDYT about returning an empty collection if we don’t know about the
table?
{quote}
I'll have a ponder over the weekend.
{quote}WDYT about renaming rawTimestamp to uuidTimestamp? Raw is ambiguous
{quote}
WFM
{quote}These changes seem like they may have been for debugging purposes, are
they something that should be committed?
{quote}
Oops, yep.
{quote}A description and explanation of the upgrade procedure should also be
included, as well as an entry in NEWS.txt
{quote}
Yep, agreed.
Thanks!
> CEP-14: Paxos Improvements
> --
>
> Key: CASSANDRA-17164
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17164
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Coordination, Consistency/Repair
>Reporter: Benedict Elliott Smith
>Assignee: Benedict Elliott Smith
>Priority: Normal
> Fix For: 4.1
>
>
> This ticket encompasses work for [CEP-14|
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-14%3A+Paxos+Improvements].
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17164) CEP-14: Paxos Improvements
[
https://issues.apache.org/jira/browse/CASSANDRA-17164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480311#comment-17480311
]
Benedict Elliott Smith edited comment on CASSANDRA-17164 at 1/22/22, 1:08 AM:
--
{quote}Why did you remove the logged warning about non linearizable reads?
{quote}
Hopefully unintentionally...
{quote} Why did you change type.decompose to type.decomposeUntyped in
makeInternalOptionsWithNowInSec?
{quote}
I think because dtest-api uses UUID and so a full migration to TimeUUID in all
places was kind of tricky, particularly for e.g. upgrade tests? It's hazy after
so long.
{quote}especially since it’s not checking for the partition key or static row
{quote}
I'm sure this is an oversight that's just not important for the use case -
which unfortunately I forget, so I'll just fix up this oversight.
{quote}should we log out of range requests in isInRangeAndShouldProcess?
{quote}
I think this is something that still hasn't taken full shape in OSS, so I'm not
sure what the right course of action is. Happy to do whatever you feel is
appropriate until a broader strategy is sorted out.
{quote}I’d prefer we use .equals instead of checking pointer equality here.
.equals should check for pointer equality, but will also guard against
unintended behavior
{quote}
For the assert? That would be fine, but it makes enforcing the identity
constraint harder with automated testing. In the other case, it's a pure
optimisation so better to keep IMO (else the benefit is likely lost)
{quote}WDYT about returning an empty collection if we don’t know about the
table?
{quote}
I'll have a ponder over the weekend.
{quote}WDYT about renaming rawTimestamp to uuidTimestamp? Raw is ambiguous
{quote}
WFM
{quote}These changes seem like they may have been for debugging purposes, are
they something that should be committed?
{quote}
Oops, yep.
{quote}A description and explanation of the upgrade procedure should also be
included, as well as an entry in NEWS.txt
{quote}
Yep, agreed.
Thanks!
was (Author: benedict):
{quote}Why did you remove the logged warning about non linearizable
reads?{quote}
Hopefully unintentionally...
{quote} Why did you change type.decompose to type.decomposeUntyped in
makeInternalOptionsWithNowInSec? {quote}
I think because dtest-api uses UUID and so a full migration to TimeUUID in all
places was kind of tricky, particularly for e.g. upgrade tests? It's hazy after
so long.
{quote}especially since it’s not checking for the partition key or static
row{quote}
I'm sure this is an oversight that's just not important for the use case -
which unfortunately I forget, so I'll just fix up this oversight.
{quote}should we log out of range requests in isInRangeAndShouldProcess?{quote}
I think this is something that still hasn't taken full shape in OSS, so I'm not
sure what the right course of action is. Happy to do whatever you feel is
appropriate until a broader strategy is sorted out.
{quote}I’d prefer we use .equals instead of checking pointer equality here.
.equals should check for pointer equality, but will also guard against
unintended behavior{quote}
For the assert? That would be fine, but it makes enforcing the identity
constraint harder with automated testing. In the other case, it's a pure
optimisation so better to keep IMO (else the benefit is likely lost)
{quote}WDYT about returning an empty collection if we don’t know about the
table?{quote}
I'll have a ponder over the weekend.
{quote}WDYT about renaming rawTimestamp to uuidTimestamp? Raw is
ambiguous{quote}
WFM
{quote}These changes seem like they may have been for debugging purposes, are
they something that should be committed?{quote}
Oops, yep.
Thanks!
> CEP-14: Paxos Improvements
> --
>
> Key: CASSANDRA-17164
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17164
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Coordination, Consistency/Repair
>Reporter: Benedict Elliott Smith
>Assignee: Benedict Elliott Smith
>Priority: Normal
> Fix For: 4.1
>
>
> This ticket encompasses work for [CEP-14|
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-14%3A+Paxos+Improvements].
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17164) CEP-14: Paxos Improvements
[
https://issues.apache.org/jira/browse/CASSANDRA-17164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480311#comment-17480311
]
Benedict Elliott Smith commented on CASSANDRA-17164:
{quote}Why did you remove the logged warning about non linearizable
reads?{quote}
Hopefully unintentionally...
{quote} Why did you change type.decompose to type.decomposeUntyped in
makeInternalOptionsWithNowInSec? {quote}
I think because dtest-api uses UUID and so a full migration to TimeUUID in all
places was kind of tricky, particularly for e.g. upgrade tests? It's hazy after
so long.
{quote}especially since it’s not checking for the partition key or static
row{quote}
I'm sure this is an oversight that's just not important for the use case -
which unfortunately I forget, so I'll just fix up this oversight.
{quote}should we log out of range requests in isInRangeAndShouldProcess?{quote}
I think this is something that still hasn't taken full shape in OSS, so I'm not
sure what the right course of action is. Happy to do whatever you feel is
appropriate until a broader strategy is sorted out.
{quote}I’d prefer we use .equals instead of checking pointer equality here.
.equals should check for pointer equality, but will also guard against
unintended behavior{quote}
For the assert? That would be fine, but it makes enforcing the identity
constraint harder with automated testing. In the other case, it's a pure
optimisation so better to keep IMO (else the benefit is likely lost)
{quote}WDYT about returning an empty collection if we don’t know about the
table?{quote}
I'll have a ponder over the weekend.
{quote}WDYT about renaming rawTimestamp to uuidTimestamp? Raw is
ambiguous{quote}
WFM
{quote}These changes seem like they may have been for debugging purposes, are
they something that should be committed?{quote}
Oops, yep.
Thanks!
> CEP-14: Paxos Improvements
> --
>
> Key: CASSANDRA-17164
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17164
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Coordination, Consistency/Repair
>Reporter: Benedict Elliott Smith
>Assignee: Benedict Elliott Smith
>Priority: Normal
> Fix For: 4.1
>
>
> This ticket encompasses work for [CEP-14|
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-14%3A+Paxos+Improvements].
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16894) Java 11 support - remove the experimental flag
[ https://issues.apache.org/jira/browse/CASSANDRA-16894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480295#comment-17480295 ] Ekaterina Dimitrova commented on CASSANDRA-16894: - Hey [~mck] , can you check this brand new adoc patch, please? :D https://github.com/ekaterinadimitrova2/cassandra/pull/new/16894-4.0 > Java 11 support - remove the experimental flag > -- > > Key: CASSANDRA-16894 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16894 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0.x > > > As per this [thread. > |https://lists.apache.org/thread.html/r06a4768bae215dc19469491a1faec64dd90e1c3d4d10ed34b85ba248%40%3Cdev.cassandra.apache.org%3E]the > goal of this ticket is to remove the experimental flag for Java 11 support. > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17164) CEP-14: Paxos Improvements
[
https://issues.apache.org/jira/browse/CASSANDRA-17164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480292#comment-17480292
]
Blake Eggleston commented on CASSANDRA-17164:
-
So this looks pretty good for the most part, I don’t have any high level
concerns about the patch. I have a branch here with some minor changes:
[https://github.com/bdeggleston/cassandra/tree/17164-trunk-review]
Other feedback / questions:
* Config
** additional comments around some of the config options would be useful
* DatabaseDescriptor
** Why did you remove the logged warning about non linearizable reads?
* QueryProcessor
** Why did you change {{type.decompose}} to {{type.decomposeUntyped}} in
{{makeInternalOptionsWithNowInSec}}??
* AbstractBTreePartition / PartitionUpdate
** this equals method is going to cause confusion and possibly bugs in the
future. I’d opt for a standard equals/hashCode implementation either here or in
PartitionUpdate, and if you need something more specific for tests, I’d write
an assert method for those tests, especially since it’s not checking for the
partition key or static row
* PaxosCleanup
** should we log out of range requests in {{isInRangeAndShouldProcess}}?
* PaxosCleanupScheduler
** Doesn’t seem to be used outside of tests
* PaxosState
** I’d prefer we use {{.equals}} instead of checking pointer equality here.
{{.equals}} should check for pointer equality, but will also guard against
unintended behavior if logically identical but different objects end up in
these fields.
* UncommittedTableData
** Regarding your TODO in {{CFSFilterFactory,getReplicatedRanges}}, WDYT about
returning an empty collection if we don’t know about the table?
* Ballot/TimeUUID
** WDYT about renaming {{rawTimestamp}} to {{uuidTimestamp}}? Raw is ambiguous
* BufferPool
** These changes seem like they may have been for debugging purposes, are they
something that should be committed?
In addition to more docs around the config options, we should include docs
explaining what v2 is, and when/why you’d want to use it. A description and
explanation of the upgrade procedure should also be included, as well as an
entry in NEWS.txt.
> CEP-14: Paxos Improvements
> --
>
> Key: CASSANDRA-17164
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17164
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Coordination, Consistency/Repair
>Reporter: Benedict Elliott Smith
>Assignee: Benedict Elliott Smith
>Priority: Normal
> Fix For: 4.1
>
>
> This ticket encompasses work for [CEP-14|
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-14%3A+Paxos+Improvements].
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17182) Add info how to test with your own CCM branch
[
https://issues.apache.org/jira/browse/CASSANDRA-17182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480285#comment-17480285
]
Ekaterina Dimitrova edited comment on CASSANDRA-17182 at 1/21/22, 10:58 PM:
I decided to add one sentence instruction in requirements.txt and just refer to
the file, where the instruction can be found, in two other places. So now we
need to update only one place in case of changes in the current setup.
Patches:
[dtest|https://github.com/ekaterinadimitrova2/cassandra-dtest/pull/new/CASSANDRA-17182]
|
[website|https://github.com/ekaterinadimitrova2/cassandra-website/pull/new/CASSANDRA-17182]
CC [~Anthony Grasso], [~mck] as I am not sure what are the steps to stage now
for review the changes to the website. I saw the run.sh script but I wasn't
completely sure which options I should be using. Please advise.
was (Author: e.dimitrova):
I decided to add one sentence instruction in requirements.txt and just refer to
the instruction in two other places. So now we need to update only one place in
case of changes in the current setup.
Patches:
[dtest|https://github.com/ekaterinadimitrova2/cassandra-dtest/pull/new/CASSANDRA-17182]
|
[website|https://github.com/ekaterinadimitrova2/cassandra-website/pull/new/CASSANDRA-17182]
CC [~Anthony Grasso], [~mck] as I am not sure what are the steps to stage now
for review the changes to the website. I saw the run.sh script but I wasn't
completely sure which options I should be using. Please advise.
> Add info how to test with your own CCM branch
> -
>
> Key: CASSANDRA-17182
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17182
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Low
>
> In CASSANDRA-16688 we solved an issue with ccm and retagging.
> It required to remove the -e from the beginning of [this
> row|https://github.com/apache/cassandra-dtest/blob/trunk/requirements.txt#L9]
> But now if someone wants to test with their own ccm branch, they need to add
> back the -e during testing so that pip3 updates with their branch. Without
> it, it doesn't update.
> *Example:*
> {code:java}
> -e git+https://github.com/riptano/ccm.git@cassandra-test#egg=ccm
> {code}
> This is important information and I think we need to add it to at least:
> - our Testing page where dtest runs are mentioned on the website
> - Add a comment in requirements.txt in the dtest repo
> We can also update the README files of CCM and DTests but then if something
> changes we will need to update this info in 4 places which doesn't seem
> efficient to me.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17182) Add info how to test with your own CCM branch
[
https://issues.apache.org/jira/browse/CASSANDRA-17182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480285#comment-17480285
]
Ekaterina Dimitrova commented on CASSANDRA-17182:
-
I decided to add one sentence instruction in requirements.txt and just refer to
the instruction in two other places. So now we need to update only one place in
case of changes in the current setup.
Patches:
[dtest|https://github.com/ekaterinadimitrova2/cassandra-dtest/pull/new/CASSANDRA-17182]
|
[website|https://github.com/ekaterinadimitrova2/cassandra-website/pull/new/CASSANDRA-17182]
CC [~Anthony Grasso], [~mck] as I am not sure what are the steps to stage now
for review the changes to the website. I saw the run.sh script but I wasn't
completely sure which options I should be using. Please advise.
> Add info how to test with your own CCM branch
> -
>
> Key: CASSANDRA-17182
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17182
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Low
>
> In CASSANDRA-16688 we solved an issue with ccm and retagging.
> It required to remove the -e from the beginning of [this
> row|https://github.com/apache/cassandra-dtest/blob/trunk/requirements.txt#L9]
> But now if someone wants to test with their own ccm branch, they need to add
> back the -e during testing so that pip3 updates with their branch. Without
> it, it doesn't update.
> *Example:*
> {code:java}
> -e git+https://github.com/riptano/ccm.git@cassandra-test#egg=ccm
> {code}
> This is important information and I think we need to add it to at least:
> - our Testing page where dtest runs are mentioned on the website
> - Add a comment in requirements.txt in the dtest repo
> We can also update the README files of CCM and DTests but then if something
> changes we will need to update this info in 4 places which doesn't seem
> efficient to me.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17182) Add info how to test with your own CCM branch
[
https://issues.apache.org/jira/browse/CASSANDRA-17182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-17182:
Test and Documentation Plan:
[dtest|https://github.com/ekaterinadimitrova2/cassandra-dtest/pull/new/CASSANDRA-17182]
|
[website|https://github.com/ekaterinadimitrova2/cassandra-website/pull/new/CASSANDRA-17182]
Status: Patch Available (was: In Progress)
> Add info how to test with your own CCM branch
> -
>
> Key: CASSANDRA-17182
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17182
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Low
>
> In CASSANDRA-16688 we solved an issue with ccm and retagging.
> It required to remove the -e from the beginning of [this
> row|https://github.com/apache/cassandra-dtest/blob/trunk/requirements.txt#L9]
> But now if someone wants to test with their own ccm branch, they need to add
> back the -e during testing so that pip3 updates with their branch. Without
> it, it doesn't update.
> *Example:*
> {code:java}
> -e git+https://github.com/riptano/ccm.git@cassandra-test#egg=ccm
> {code}
> This is important information and I think we need to add it to at least:
> - our Testing page where dtest runs are mentioned on the website
> - Add a comment in requirements.txt in the dtest repo
> We can also update the README files of CCM and DTests but then if something
> changes we will need to update this info in 4 places which doesn't seem
> efficient to me.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-33) Optionally support multiple Cassandra instances in Sidecar
[ https://issues.apache.org/jira/browse/CASSANDRASC-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Saranya Krishnakumar updated CASSANDRASC-33: Authors: Saranya Krishnakumar Test and Documentation Plan: Unit tests Status: Patch Available (was: Open) > Optionally support multiple Cassandra instances in Sidecar > -- > > Key: CASSANDRASC-33 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-33 > Project: Sidecar for Apache Cassandra > Issue Type: New Feature > Components: Rest API >Reporter: Saranya Krishnakumar >Assignee: Saranya Krishnakumar >Priority: Normal > > Currently Sidecar supports only one Cassandra instance, we want to optionally > support multiple Cassandra instances -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-33) Optionally support multiple Cassandra instances in Sidecar
[ https://issues.apache.org/jira/browse/CASSANDRASC-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Saranya Krishnakumar updated CASSANDRASC-33: Change Category: Operability Complexity: Normal Component/s: Rest API (was: Configuration) Reviewers: Dinesh Joshi, Yifan Cai Status: Open (was: Triage Needed) [https://github.com/apache/cassandra-sidecar/pull/25.] Tested with unit tests > Optionally support multiple Cassandra instances in Sidecar > -- > > Key: CASSANDRASC-33 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-33 > Project: Sidecar for Apache Cassandra > Issue Type: New Feature > Components: Rest API >Reporter: Saranya Krishnakumar >Assignee: Saranya Krishnakumar >Priority: Normal > > Currently Sidecar supports only one Cassandra instance, we want to optionally > support multiple Cassandra instances -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17182) Add info how to test with your own CCM branch
[
https://issues.apache.org/jira/browse/CASSANDRA-17182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-17182:
Description:
In CASSANDRA-16688 we solved an issue with ccm and retagging.
It required to remove the -e from the beginning of [this
row|https://github.com/apache/cassandra-dtest/blob/trunk/requirements.txt#L9]
But now if someone wants to test with their own ccm branch, they need to add
back the -e during testing so that pip3 updates with their branch. Without it,
it doesn't update.
*Example:*
{code:java}
-e git+https://github.com/riptano/ccm.git@cassandra-test#egg=ccm
{code}
This is important information and I think we need to add it to at least:
- our Testing page where dtest runs are mentioned on the website
- Add a comment in requirements.txt in the dtest repo
We can also update the README files of CCM and DTests but then if something
changes we will need to update this info in 4 places which doesn't seem
efficient to me.
was:
In CASSANDRA-16688 we solved an issue with ccm and retagging.
It required to remove the -e from the beginning of [this
row|https://github.com/apache/cassandra-dtest/blob/trunk/requirements.txt#L9]
But now if someone wants to test with their own ccm branch, they need to add
back the -e during testing so that pip3 updates with their branch. Without it,
it doesn't update.
*Example:*
{code:java}
git+https://github.com/riptano/ccm.git@cassandra-test#egg=ccm
{code}
This is important information and I think we need to add it to at least:
- our Testing page where dtest runs are mentioned on the website
- Add a comment in requirements.txt in the dtest repo
We can also update the README files of CCM and DTests but then if something
changes we will need to update this info in 4 places which doesn't seem
efficient to me.
> Add info how to test with your own CCM branch
> -
>
> Key: CASSANDRA-17182
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17182
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Low
>
> In CASSANDRA-16688 we solved an issue with ccm and retagging.
> It required to remove the -e from the beginning of [this
> row|https://github.com/apache/cassandra-dtest/blob/trunk/requirements.txt#L9]
> But now if someone wants to test with their own ccm branch, they need to add
> back the -e during testing so that pip3 updates with their branch. Without
> it, it doesn't update.
> *Example:*
> {code:java}
> -e git+https://github.com/riptano/ccm.git@cassandra-test#egg=ccm
> {code}
> This is important information and I think we need to add it to at least:
> - our Testing page where dtest runs are mentioned on the website
> - Add a comment in requirements.txt in the dtest repo
> We can also update the README files of CCM and DTests but then if something
> changes we will need to update this info in 4 places which doesn't seem
> efficient to me.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
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 (5f2beae -> 012ca5e)
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 5f2beae generate docs for a0022ebd new 012ca5e generate docs for a0022ebd 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 (5f2beae) \ N -- N -- N refs/heads/asf-staging (012ca5e) 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 4740057 -> 4740057 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-17212) Migrate threshold for minimum keyspace replication factor to guardrails
[
https://issues.apache.org/jira/browse/CASSANDRA-17212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480268#comment-17480268
]
Josh McKenzie commented on CASSANDRA-17212:
---
Simple miscommunication and misunderstanding; I was on a different browser and
didn't realize the example you provided enumerated {_}past just the concurrency
limits{_}. So completely disregard.
JIRA comments on related tickets isn't the right place or technology for us to
have this discussion async. Do we have a gdoc where someone has enumerated the
crux of the discussion yet and I just missed it?
> Migrate threshold for minimum keyspace replication factor to guardrails
> ---
>
> Key: CASSANDRA-17212
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17212
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Priority: Normal
>
> The config property
> [{{minimum_keyspace_rf}}|https://github.com/apache/cassandra/blob/5fdadb25f95099b8945d9d9ee11d3e380d3867f4/conf/cassandra.yaml]
> that was added by CASSANDRA-14557 can be migrated to guardrails, for example:
> {code}
> guardrails:
> ...
> replication_factor:
> warn_threshold: 2
> abort_threshold: 3
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-15297) nodetool can not create snapshot with snapshot name that have special character
[ https://issues.apache.org/jira/browse/CASSANDRA-15297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Saranya Krishnakumar reassigned CASSANDRA-15297: Assignee: Saranya Krishnakumar (was: maxwellguo) > nodetool can not create snapshot with snapshot name that have special > character > --- > > Key: CASSANDRA-15297 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15297 > Project: Cassandra > Issue Type: Bug > Components: Tool/nodetool >Reporter: maxwellguo >Assignee: Saranya Krishnakumar >Priority: Normal > Labels: pull-request-available > Fix For: 4.x > > Attachments: after-fix.jpg, image.png, listsnapshots-p-s.jpg, > snapshot-listsnapshot-.jpg, snapshot-p-s.jpg > > Time Spent: 0.5h > Remaining Estimate: 0h > > we make snapshot through "nodetool snapshot -t snapshotname " , when > snapshotname contains special characters like "/", the make snapshot process > successfully , but the result > can be different ,when we check the data file directory or use "nodetool > listsnapshots". > here is some case : > 1. nodetool snapshot -t "p/s" > the listsnapshot resturns snapshot p for all table but actually the snapshot > name is "p/s"; > also the data directory is like the format : > datapath/snapshots/p/s/snapshot-datafile-link > !snapshot-p-s.jpg! > !listsnapshots-p-s.jpg! > 2. nodetool snapshot -t "/" > the listsnapshot resturns "there is not snapshot"; but the make snapshot > process return successfully and the data directory is like the format : > datapath/snapshots/snapshot-datafile-link > !snapshot-listsnapshot-.jpg! > the Attachements are the result under our environment. > so for me , we suggest that the snapshot name should not contains special > character. just throw exception and told the user not to use special > character. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15297) nodetool can not create snapshot with snapshot name that have special character
[ https://issues.apache.org/jira/browse/CASSANDRA-15297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480263#comment-17480263 ] Saranya Krishnakumar commented on CASSANDRA-15297: -- [~blerer] I created a PR after adding unit test https://github.com/apache/cassandra/pull/1420 > nodetool can not create snapshot with snapshot name that have special > character > --- > > Key: CASSANDRA-15297 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15297 > Project: Cassandra > Issue Type: Bug > Components: Tool/nodetool >Reporter: maxwellguo >Assignee: maxwellguo >Priority: Normal > Labels: pull-request-available > Fix For: 4.x > > Attachments: after-fix.jpg, image.png, listsnapshots-p-s.jpg, > snapshot-listsnapshot-.jpg, snapshot-p-s.jpg > > Time Spent: 0.5h > Remaining Estimate: 0h > > we make snapshot through "nodetool snapshot -t snapshotname " , when > snapshotname contains special characters like "/", the make snapshot process > successfully , but the result > can be different ,when we check the data file directory or use "nodetool > listsnapshots". > here is some case : > 1. nodetool snapshot -t "p/s" > the listsnapshot resturns snapshot p for all table but actually the snapshot > name is "p/s"; > also the data directory is like the format : > datapath/snapshots/p/s/snapshot-datafile-link > !snapshot-p-s.jpg! > !listsnapshots-p-s.jpg! > 2. nodetool snapshot -t "/" > the listsnapshot resturns "there is not snapshot"; but the make snapshot > process return successfully and the data directory is like the format : > datapath/snapshots/snapshot-datafile-link > !snapshot-listsnapshot-.jpg! > the Attachements are the result under our environment. > so for me , we suggest that the snapshot name should not contains special > character. just throw exception and told the user not to use special > character. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15399) Add ability to track state in repair
[
https://issues.apache.org/jira/browse/CASSANDRA-15399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480258#comment-17480258
]
David Capwell commented on CASSANDRA-15399:
---
My thinking with CASSANDRA-15566 is that this ticket helps, but doesn't provide
all the state yet... main thing missing is the merle trees (a common bug is
networking drops the large trees so we wait forever... if we store them we can
recover); wondering if I should add that table in this patch as well?
> Add ability to track state in repair
>
>
> Key: CASSANDRA-15399
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15399
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Repair
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> To enhance the visibility in repair, we should expose internal state via
> virtual tables; the state should include coordinator as well as participant
> state (validation, sync, etc.)
> I propose the following tables:
> repairs - high level summary of the global state of repair; this should be
> called on the coordinator.
> {code:sql}
> CREATE TABLE repairs (
> id uuid,
> keyspace_name text,
> table_names frozen>,
> ranges frozen>,
> coordinator text,
> participants frozen>,
> state text,
> progress_percentage float,
> last_updated_at_millis bigint,
> duration_micro bigint,
> failure_cause text,
> PRIMARY KEY ( (id) )
> )
> {code}
> repair_tasks - represents RepairJob and participants state. This will show
> if validations are running on participants and the progress they are making;
> this should be called on the coordinator.
> {code:sql}
> CREATE TABLE repair_tasks (
> id uuid,
> session_id uuid,
> keyspace_name text,
> table_name text,
> ranges frozen>,
> coordinator text,
> participant text,
> state text,
> state_description text,
> progress_percentage float, -- between 0.0 and 100.0
> last_updated_at_millis bigint,
> duration_micro bigint,
> failure_cause text,
> PRIMARY KEY ( (id), session_id, table_name, participant )
> )
> {code}
> repair_validations - shows the state of the validation task and updated
> periodically while validation is running; this should be called on the
> participants.
> {code:sql}
> CREATE TABLE repair_validations (
> id uuid,
> session_id uuid,
> ranges frozen>,
> keyspace_name text,
> table_name text,
> initiator text,
> state text,
> progress_percentage float,
> queue_duration_ms bigint,
> runtime_duration_ms bigint,
> total_duration_ms bigint,
> estimated_partitions bigint,
> partitions_processed bigint,
> estimated_total_bytes bigint,
> failure_cause text,
> PRIMARY KEY ( (id), session_id, table_name )
> )
> {code}
> The main reason for exposing virtual tables rather than exposing through
> durable tables is to make sure what is exposed is accurate. In cases of
> write failures or node failures, the durable tables could become in-accurate
> and could add edge cases where the repair is not running but the tables say
> it is; by relying on repair's internal in-memory bookkeeping, these problems
> go away.
> This jira does not try to solve the following:
> 1) repair resiliency - there are edge cases where repair hits an error and
> runs forever (at least from nodetool's perspective).
> 2) repair stream tracking - I have not learned the streaming side yet and
> what I see is multiple implementations exist, so seems like high scope. My
> hope is to punt from this jira and tackle separately.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15399) Add ability to track state in repair
[
https://issues.apache.org/jira/browse/CASSANDRA-15399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480257#comment-17480257
]
David Capwell commented on CASSANDRA-15399:
---
finally got time to come back to this, sent out a work-in-progress PR that
shows coordinator state as well as validation; missing streaming...
here is sample output querying after running a repair
{code}
node2: SELECT * FROM system_views.repairs
id: 967551d0-7af5-11ec-abdf-517b0d807e7c
duration_millis: 555
failure_cause: null
keyspace_name: distributed_test_keyspace
last_updated_at: Fri Jan 21 12:06:15 PST 2022
participants: [/127.0.0.1:7012]
progress_percentage: 100.0
ranges: [[(-1,9223372036854775805], (9223372036854775805,-1]]]
state: success
state_init_timestamp: Fri Jan 21 12:06:15 PST 2022
state_prepare_complete_timestamp: Fri Jan 21 12:06:15 PST 2022
state_prepare_submit_timestamp: Fri Jan 21 12:06:15 PST 2022
state_repair_complete_timestamp: Fri Jan 21 12:06:15 PST 2022
state_repair_submit_timestamp: Fri Jan 21 12:06:15 PST 2022
state_setup_timestamp: Fri Jan 21 12:06:15 PST 2022
state_started_timestamp: Fri Jan 21 12:06:15 PST 2022
state_success_timestamp: Fri Jan 21 12:06:15 PST 2022
table_names: [simple_preview_sequential_true]
type: preview
unfiltered_ranges: [[(-1,9223372036854775805], (9223372036854775805,-1]]]
node2: SELECT * FROM system_views.repair_sessions
id: 968111a0-7af5-11ec-abdf-517b0d807e7c
duration_millis: 470
failure_cause: null
keyspace_name: distributed_test_keyspace
last_updated_at: Fri Jan 21 12:06:15 PST 2022
progress_percentage: 100.0
ranges: [(-1,9223372036854775805], (9223372036854775805,-1]]
repair_id: 967551d0-7af5-11ec-abdf-517b0d807e7c
state: success
state_failure_timestamp: null
state_init_timestamp: Fri Jan 21 12:06:15 PST 2022
state_jobs_submit_timestamp: Fri Jan 21 12:06:15 PST 2022
state_skipped_timestamp: null
state_started_timestamp: Fri Jan 21 12:06:15 PST 2022
state_success_timestamp: Fri Jan 21 12:06:15 PST 2022
table_names: [simple_preview_sequential_true]
node2: SELECT * FROM system_views.repair_jobs
id: 2e8c3999-04b0-3013-a351-f8a43283c7c2
duration_millis: 457
failure_cause: null
keyspace_name: distributed_test_keyspace
last_updated_at: Fri Jan 21 12:06:15 PST 2022
progress_percentage: 100.0
ranges: [(-1,9223372036854775805], (9223372036854775805,-1]]
repair_id: 967551d0-7af5-11ec-abdf-517b0d807e7c
session_id: 968111a0-7af5-11ec-abdf-517b0d807e7c
state: success
state_failure_timestamp: null
state_init_timestamp: Fri Jan 21 12:06:15 PST 2022
state_snapshot_complete_timestamp: Fri Jan 21 12:06:15 PST 2022
state_snapshot_submit_timestamp: Fri Jan 21 12:06:15 PST 2022
state_started_timestamp: Fri Jan 21 12:06:15 PST 2022
state_stream_submit_timestamp: Fri Jan 21 12:06:15 PST 2022
state_success_timestamp: Fri Jan 21 12:06:15 PST 2022
state_validation_complete_timestamp: Fri Jan 21 12:06:15 PST 2022
state_validation_submit_timestamp: Fri Jan 21 12:06:15 PST 2022
table_name: simple_preview_sequential_true
node1: SELECT * FROM system_views.repair_validations
id: 2e8c3999-04b0-3013-a351-f8a43283c7c2
duration_millis: 83
estimated_partitions: 129
estimated_total_bytes: 28
failure_cause: null
initiator: /127.0.0.2:7012
keyspace_name: distributed_test_keyspace
last_updated_at: Fri Jan 21 12:06:15 PST 2022
partitions_processed: 1
progress_percentage: 100.0
ranges: [(-1,9223372036854775805], (9223372036854775805,-1]]
repair_id: 967551d0-7af5-11ec-abdf-517b0d807e7c
session_id: 968111a0-7af5-11ec-abdf-517b0d807e7c
state: success
state_failure_timestamp: null
state_init_timestamp: Fri Jan 21 12:06:15 PST 2022
state_sending_trees_timestamp: Fri Jan 21 12:06:15 PST 2022
state_skipped_timestamp: null
state_started_timestamp: Fri Jan 21 12:06:15 PST 2022
state_success_timestamp: Fri Jan 21 12:06:15 PST 2022
table_name: simple_preview_sequential_true
{code}
> Add ability to track state in repair
>
>
> Key: CASSANDRA-15399
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15399
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Repair
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> To enhance the visibility in repair, we should expose internal state via
> virtual tables; the state should include coordinator as well as participant
> state (validation, sync, etc.)
> I propose the following tables:
> repairs - high level summary of the global state of repair; this should be
> called on the coordinator.
> {code:sql}
> CREATE TABLE repairs (
> id uuid,
> keyspace_name text,
> table_names frozen>,
> ranges frozen>,
> coordinator text,
> participants frozen>,
> state text,
> progress_percentage float,
> last_updated_at_millis
[jira] [Comment Edited] (CASSANDRA-17212) Migrate threshold for minimum keyspace replication factor to guardrails
[
https://issues.apache.org/jira/browse/CASSANDRA-17212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480231#comment-17480231
]
Benedict Elliott Smith edited comment on CASSANDRA-17212 at 1/21/22, 7:19 PM:
--
bq. I think this is a bit of a straw man
Then surely there has been some miscommunication. I'm asking what a coherent
proposal is, and doing my best to construct it since it doesn't exist yet. I
wasn't trying to use it as a counter-example, but trying to understand how the
alternative proposal works in totality, and asking if this was close so we can
discuss it. I'd prefer for a proponent to propose it instead.
This kind of API design is like any other: there should be rules that underly
it as far as possible, so that it all hangs together naturally, and so that the
end user can predict its shape without knowing it all. What is the conceptual
framework, or rules, by which you would treat these other items consistently?
was (Author: benedict):
bq. I think this is a bit of a straw man
Do we both have the same understanding of what a straw man is? I'm asking what
a coherent proposal is, and doing my best to construct it since it doesn't
exist yet. I wasn't trying to use it as a counter-example, but trying to
understand how the alternative proposal works in totality, and asking if this
was close so we can discuss it. I'd prefer for a proponent to propose it
instead.
This kind of API design is like any other: there should be rules that underly
it as far as possible, so that it all hangs together naturally, and so that the
end user can predict its shape without knowing it all. What is the conceptual
framework, or rules, by which you would treat these other items consistently?
> Migrate threshold for minimum keyspace replication factor to guardrails
> ---
>
> Key: CASSANDRA-17212
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17212
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Priority: Normal
>
> The config property
> [{{minimum_keyspace_rf}}|https://github.com/apache/cassandra/blob/5fdadb25f95099b8945d9d9ee11d3e380d3867f4/conf/cassandra.yaml]
> that was added by CASSANDRA-14557 can be migrated to guardrails, for example:
> {code}
> guardrails:
> ...
> replication_factor:
> warn_threshold: 2
> abort_threshold: 3
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17212) Migrate threshold for minimum keyspace replication factor to guardrails
[
https://issues.apache.org/jira/browse/CASSANDRA-17212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480231#comment-17480231
]
Benedict Elliott Smith edited comment on CASSANDRA-17212 at 1/21/22, 6:55 PM:
--
bq. I think this is a bit of a straw man
Do we both have the same understanding of what a straw man is? I'm asking what
a coherent proposal is, and doing my best to construct it since it doesn't
exist yet. I wasn't trying to use it as a counter-example, but trying to
understand how the alternative proposal works in totality, and asking if this
was close so we can discuss it. I'd prefer for a proponent to propose it
instead.
This kind of API design is like any other: there should be rules that underly
it as far as possible, so that it all hangs together naturally, and so that the
end user can predict its shape without knowing it all. What is the conceptual
framework, or rules, by which you would treat these other items consistently?
was (Author: benedict):
bq. I think this is a bit of a straw man
Do we both have the same understanding of what a straw man is? I'm asking what
a coherent proposal is, and doing my best to construct it since it doesn't
exist yet. I wasn't trying to use it as a counter-example, but trying to
understand how the alternative proposal works in totality. I'd prefer for you
to propose a coherent design.
This kind of API design is like any other: there should be rules that underly
it as far as possible, so that it all hangs together naturally, and so that the
end user can predict its shape without knowing it all. What is the conceptual
framework, or rules, by which you would treat these other items consistently?
> Migrate threshold for minimum keyspace replication factor to guardrails
> ---
>
> Key: CASSANDRA-17212
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17212
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Priority: Normal
>
> The config property
> [{{minimum_keyspace_rf}}|https://github.com/apache/cassandra/blob/5fdadb25f95099b8945d9d9ee11d3e380d3867f4/conf/cassandra.yaml]
> that was added by CASSANDRA-14557 can be migrated to guardrails, for example:
> {code}
> guardrails:
> ...
> replication_factor:
> warn_threshold: 2
> abort_threshold: 3
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17212) Migrate threshold for minimum keyspace replication factor to guardrails
[
https://issues.apache.org/jira/browse/CASSANDRA-17212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480231#comment-17480231
]
Benedict Elliott Smith edited comment on CASSANDRA-17212 at 1/21/22, 6:52 PM:
--
bq. I think this is a bit of a straw man
Do we both have the same understanding of what a straw man is? I'm asking what
a coherent proposal is, and doing my best to construct it since it doesn't
exist yet. I wasn't trying to use it as a counter-example, but trying to
understand how the alternative proposal works in totality. I'd prefer for you
to propose a coherent design.
This kind of API design is like any other: there should be rules that underly
it as far as possible, so that it all hangs together naturally, and so that the
end user can predict its shape without knowing it all. What is the conceptual
framework, or rules, by which you would treat these other items consistently?
was (Author: benedict):
bq. I think this is a bit of a straw man
Do we both have the same understanding of what a straw man is? I'm asking what
a coherent proposal is, and doing my best to construct it since it doesn't
exist yet. I wasn't trying to use it as a counter-example, but trying to
understand how the alternative proposal works in totality. I'd prefer for you
to propose a coherent design.
This kind of API design is like any other: there should be rules that underly
it as far as possible, so that it all hands together naturally, and so that the
end user can predict its shape without knowing it all. What is the conceptual
framework, or rules, by which you would treat these other items consistently?
> Migrate threshold for minimum keyspace replication factor to guardrails
> ---
>
> Key: CASSANDRA-17212
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17212
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Priority: Normal
>
> The config property
> [{{minimum_keyspace_rf}}|https://github.com/apache/cassandra/blob/5fdadb25f95099b8945d9d9ee11d3e380d3867f4/conf/cassandra.yaml]
> that was added by CASSANDRA-14557 can be migrated to guardrails, for example:
> {code}
> guardrails:
> ...
> replication_factor:
> warn_threshold: 2
> abort_threshold: 3
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17212) Migrate threshold for minimum keyspace replication factor to guardrails
[
https://issues.apache.org/jira/browse/CASSANDRA-17212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480231#comment-17480231
]
Benedict Elliott Smith commented on CASSANDRA-17212:
bq. I think this is a bit of a straw man
Do we both have the same understanding of what a straw man is? I'm asking what
a coherent proposal is, and doing my best to construct it since it doesn't
exist yet. I wasn't trying to use it as a counter-example, but trying to
understand how the alternative proposal works in totality. I'd prefer for you
to propose a coherent design.
This kind of API design is like any other: there should be rules that underly
it as far as possible, so that it all hands together naturally, and so that the
end user can predict its shape without knowing it all. What is the conceptual
framework, or rules, by which you would treat these other items consistently?
> Migrate threshold for minimum keyspace replication factor to guardrails
> ---
>
> Key: CASSANDRA-17212
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17212
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Priority: Normal
>
> The config property
> [{{minimum_keyspace_rf}}|https://github.com/apache/cassandra/blob/5fdadb25f95099b8945d9d9ee11d3e380d3867f4/conf/cassandra.yaml]
> that was added by CASSANDRA-14557 can be migrated to guardrails, for example:
> {code}
> guardrails:
> ...
> replication_factor:
> warn_threshold: 2
> abort_threshold: 3
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17212) Migrate threshold for minimum keyspace replication factor to guardrails
[
https://issues.apache.org/jira/browse/CASSANDRA-17212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480223#comment-17480223
]
Josh McKenzie commented on CASSANDRA-17212:
---
Full disclosure, I'm with David on preferring the 2nd option. My intuition is
that having these thresholds for guardrails visible together (info, warn, fail)
will be less error prone to configure and subsequently modify than if those
values live separately from one another.
bq. For example, is this how you view the other properties?
I think this is a bit of a straw man. These are all examples of one-shot values
that are domain specific and aren't related outside of the fact that they limit
things, and in this case specifically, thread counts. If we had a "info, warn,
error" level for read threadpool concurrency then I'd advocate we co-locate
them as well, else it'd be far too easy to make a mistake when configuring it
and/or have values that weren't particularly sensible compared to one another.
Specifically re:
bq. do we group under info/warn/fail or do we group at the feature which also
offers info/warn/fail?
I don't think anybody is currently advocating for the statement: "concurrency
is a feature and we should group parameters under that".
> Migrate threshold for minimum keyspace replication factor to guardrails
> ---
>
> Key: CASSANDRA-17212
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17212
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Priority: Normal
>
> The config property
> [{{minimum_keyspace_rf}}|https://github.com/apache/cassandra/blob/5fdadb25f95099b8945d9d9ee11d3e380d3867f4/conf/cassandra.yaml]
> that was added by CASSANDRA-14557 can be migrated to guardrails, for example:
> {code}
> guardrails:
> ...
> replication_factor:
> warn_threshold: 2
> abort_threshold: 3
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17212) Migrate threshold for minimum keyspace replication factor to guardrails
[
https://issues.apache.org/jira/browse/CASSANDRA-17212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480205#comment-17480205
]
Benedict Elliott Smith edited comment on CASSANDRA-17212 at 1/21/22, 5:51 PM:
--
Discoverability remains poor, as previously mentioned, but also this is almost
inherently inconsistent as we are already grouping under a concept heading by
using {{limits}}. What about other {{row_index}} things that aren't limits?
I also don't think a discussion can ignore how this fits in with other limits,
such as concurrency, throughput etc., which looks particularly messy (and
materially harms discovery of these pieces) as well as complicates
documentation.
We also need to look at consistency of e.g. {{local_read_size}} versus
{{large_partition}} (no size).
For example, is this how you view the other properties?
{code}
limits:
reads:
concurrency: 32
writes:
concurrency: 32
counter_writes:
concurrency: 32
materialized_view_writes:
concurrency: 32
clients:
concurrency: 128
hint_delivery:
concurrency: 2
flush:
concurrency: 2
compaction:
concurrency: 1
repair:
concurrency: 0
auto_sstable_upgrades:
concurrency: 1
streaming:
local:
throughput: 25MiB/s
remote:
throughput: 25MiB/s
batchlog:
throughput: 1MiB/s
compaction:
throughput: 16MiB/s
hint_delivery:
throughput: 1MiB/s
memtable:
heap_capacity: 2048mb
offheap_capacity: 2048mb
compressed_chunks_cache:
capacity: 512MiB
key_index_cache:
row_index_size_limit: 2KiB
capacity: 0MiB
network:
tcp:
send_buffer_size: 512MiB
recv_buffer_size: 512MiB
connection:
send_queue_size: 4MiB
recv_queue_size: 4MiB
endpoint:
send_queue_size: 128MiB
recv_queue_size: 128MiB
global:
send_queue_size: 512MiB
recv_queue_size: 512MiB
{code}
I think you also then need to start asking difficult questions like, is
streaming a network limit? Will the user expect your choice here?
It is however trivial for the user to say "is this a throughput limit?" and
then find the relevant one.
was (Author: benedict):
Discoverability remains poor, as previously mentioned, but also this is almost
inherently inconsistent as we are already grouping under a concept heading by
using {{limits}}. What about other {{row_index}} things that aren't limits?
I also don't think a discussion can ignore how this fits in with other limits,
such as concurrency, throughput etc., which looks particularly messy (and
materially harms discovery of these pieces) as well as complicates
documentation.
We also need to look at consistency of e.g. {{local_read_size}} versus
{{large_partition}} (no size).
> Migrate threshold for minimum keyspace replication factor to guardrails
> ---
>
> Key: CASSANDRA-17212
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17212
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Priority: Normal
>
> The config property
> [{{minimum_keyspace_rf}}|https://github.com/apache/cassandra/blob/5fdadb25f95099b8945d9d9ee11d3e380d3867f4/conf/cassandra.yaml]
> that was added by CASSANDRA-14557 can be migrated to guardrails, for example:
> {code}
> guardrails:
> ...
> replication_factor:
> warn_threshold: 2
> abort_threshold: 3
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17188) Guardrails for consistency levels
[
https://issues.apache.org/jira/browse/CASSANDRA-17188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480207#comment-17480207
]
Benedict Elliott Smith commented on CASSANDRA-17188:
bq. I don't know if the idea here is reverting any new property since 4.0 and
block until we have that discussion
Have any new properties been created that relate to existing properties, and
have they done so in a manner that is inconsistent with existing or planned
near-term work? If so, yes they should be revisited.
I'm kind of surprised by the pushback here. I am not tying this to any
follow-up to CASSANDRA-15234, but to this work on its own merits. This epic
will be refactoring config, introducing new config, and all of this relates to
other existing config. These changes should all be thought of coherently, no?
> Guardrails for consistency levels
> -
>
> Key: CASSANDRA-17188
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17188
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.x
>
>
> Add guardrails for read/write consistency levels, for example:
> {code:java}
> # Guardrail to warn about or reject read consistency levels.
> # By default all consistency levels are allowed.
> read_consistency_levels:
> warned: []
> disallowed: []
> # Guardrail to warn about or reject write consistency levels.
> # By default all consistency levels are allowed.
> write_consistency_levels:
> warned: []
> disallowed: []
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17212) Migrate threshold for minimum keyspace replication factor to guardrails
[
https://issues.apache.org/jira/browse/CASSANDRA-17212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480205#comment-17480205
]
Benedict Elliott Smith commented on CASSANDRA-17212:
Discoverability remains poor, as previously mentioned, but also this is almost
inherently inconsistent as we are already grouping under a concept heading by
using {{limits}}. What about other {{row_index}} things that aren't limits?
I also don't think a discussion can ignore how this fits in with other limits,
such as concurrency, throughput etc., which looks particularly messy (and
materially harms discovery of these pieces) as well as complicates
documentation.
We also need to look at consistency of e.g. {{local_read_size}} versus
{{large_partition}} (no size).
> Migrate threshold for minimum keyspace replication factor to guardrails
> ---
>
> Key: CASSANDRA-17212
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17212
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Priority: Normal
>
> The config property
> [{{minimum_keyspace_rf}}|https://github.com/apache/cassandra/blob/5fdadb25f95099b8945d9d9ee11d3e380d3867f4/conf/cassandra.yaml]
> that was added by CASSANDRA-14557 can be migrated to guardrails, for example:
> {code}
> guardrails:
> ...
> replication_factor:
> warn_threshold: 2
> abort_threshold: 3
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16951) Dtest cluster reusage
[
https://issues.apache.org/jira/browse/CASSANDRA-16951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh McKenzie updated CASSANDRA-16951:
--
Status: Patch Available (was: Review In Progress)
> Dtest cluster reusage
> -
>
> Key: CASSANDRA-16951
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16951
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/dtest/python
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0.x
>
>
> Dtests are very heavy but in some instances most of the time is spent
> restarting nodes in between test methods. Not all of them, but many seem
> could benefit form reusing a common cluster sparing the restarts. Obviously
> that is not the case for tests that manipulate the nodes itself during the
> test. The ones that follow a setup node/do test seem to benefit greatly in
> terms of time execution.
> Some classes run time can be cut form 10m to 1,5m. Others only from 30m to
> 25m. But taking a 5m shave and considering it will probably get ran *
> with/without vnodes * j8/j11/j8j11 * 4.0/trunk turns the 5m cut into a 60m
> cut. That should be a nice reduction in CI usage. Unfortunately run time will
> mostly remain the same until we have a majority of tests reusing nodes as the
> 'longest pole' will be the determining factor.
> How it works? It's an opt-in. Annotate the first test with
> {{@reuse_cluster(new_cluster=True)}} and the following ones with
> {{@reuse_cluster}}. Best effort to reuse the cluster will be made. Stop using
> the annotation at any test method and it will start a new one.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16951) Dtest cluster reusage
[
https://issues.apache.org/jira/browse/CASSANDRA-16951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh McKenzie updated CASSANDRA-16951:
--
Status: Open (was: Patch Available)
> Dtest cluster reusage
> -
>
> Key: CASSANDRA-16951
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16951
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/dtest/python
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0.x
>
>
> Dtests are very heavy but in some instances most of the time is spent
> restarting nodes in between test methods. Not all of them, but many seem
> could benefit form reusing a common cluster sparing the restarts. Obviously
> that is not the case for tests that manipulate the nodes itself during the
> test. The ones that follow a setup node/do test seem to benefit greatly in
> terms of time execution.
> Some classes run time can be cut form 10m to 1,5m. Others only from 30m to
> 25m. But taking a 5m shave and considering it will probably get ran *
> with/without vnodes * j8/j11/j8j11 * 4.0/trunk turns the 5m cut into a 60m
> cut. That should be a nice reduction in CI usage. Unfortunately run time will
> mostly remain the same until we have a majority of tests reusing nodes as the
> 'longest pole' will be the determining factor.
> How it works? It's an opt-in. Annotate the first test with
> {{@reuse_cluster(new_cluster=True)}} and the following ones with
> {{@reuse_cluster}}. Best effort to reuse the cluster will be made. Stop using
> the annotation at any test method and it will start a new one.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17188) Guardrails for consistency levels
[
https://issues.apache.org/jira/browse/CASSANDRA-17188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480200#comment-17480200
]
Andres de la Peña commented on CASSANDRA-17188:
---
Guardrails fit in the current yaml in a way that is pretty similar to what was
proposed in the CEP, with the only addition of nesting, which makes them
identical to the already committed track_warnings. Besides, both features are
disabled by default and their properties are commented. I don't know how well
they fit into the new plans for the yaml, which don't have any associated CEP,
ticket nor agreement.
I don't know if the idea here is reverting any new property since 4.0 and block
until we have that discussion, whenever we have it. In any case I don't see why
this is exclusive to guardrails and not to all new properties since 4.0, since
any new property should also fit in that holistic view for config that doesn't
exist yet.
As for the difficulty of refactoring later, guardrails add an standard way to
treat limits, so transforming existing properties that are suitable (and
{{minimum_keyspace_rf}} might not be one of those) should make those properties
much easier to adapt to whatever yaml format we use later. This is so because
they have a common behaviour, validation rules, messaging formats, etc., so
they are easy no modify all at once, and not one by one as it was needed in
CASSANDRA-15234. So they put us closer to any planned future extensive changes
in yaml.
> Guardrails for consistency levels
> -
>
> Key: CASSANDRA-17188
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17188
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.x
>
>
> Add guardrails for read/write consistency levels, for example:
> {code:java}
> # Guardrail to warn about or reject read consistency levels.
> # By default all consistency levels are allowed.
> read_consistency_levels:
> warned: []
> disallowed: []
> # Guardrail to warn about or reject write consistency levels.
> # By default all consistency levels are allowed.
> write_consistency_levels:
> warned: []
> disallowed: []
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17212) Migrate threshold for minimum keyspace replication factor to guardrails
[
https://issues.apache.org/jira/browse/CASSANDRA-17212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480198#comment-17480198
]
David Capwell commented on CASSANDRA-17212:
---
Maybe we can better find an agreement if we show specific features and debate
how they should work; we can move on easier once we do that.
Currently we have (made up my own config values, these are not the defaults):
{code}
track_warnings: # planned to be merged into guardrails
enabled: true
coordinator_read_size:
warn_threshold: 1g
abort_threshold: 2g
local_read_size:
warn_threshold: 1g
abort_threshold: 2g
row_index_size:
warn_threshold: 1g
abort_threshold: 2g
replica_filtering_protection:
cached_rows_warn_threshold: 2000
cached_rows_fail_threshold: 32000
guardrails:
enabled: false
keyspaces:
warn_threshold: -1
abort_threshold: -1
tables:
warn_threshold: -1
abort_threshold: -1
columns_per_table:
warn_threshold: -1
abort_threshold: -1
secondary_indexes_per_table:
warn_threshold: -1
abort_threshold: -1
materialized_views_per_table:
warn_threshold: -1
abort_threshold: -1
table_properties:
ignored: []
disallowed: []
user_timestamps_enabled: true
page_size:
warn_threshold: -1
abort_threshold: -1
read_before_write_list_operations_enabled: true
{code}
[~benedict] looks to be proposing
{code}
limits:
concurrency:
reads: 32
writes: 32
counter_writes: 32
materialized_view_writes: 32
clients: 128
hint_delivery: 2
flush: 2
compaction: 1
repair: 0
auto_sstable_upgrades: 1
throughput:
streaming:
local: 25MiB/s
remote: 25MiB/s
batchlog: 1MiB/s
compaction: 16MiB/s
hint_delivery: 1MiB/s
capacity:
memtable:
heap: 2048mb
offheap: 2048mb
caching:
compressed_chunks: 512MiB
key_index:
row_index: 2KiB
partitions: 0MiB
network:
tcp:
send_buffer: 512MiB
recv_buffer: 512MiB
connection:
send_queue: 4MiB
recv_queue: 4MiB
endpoint:
send_queue: 128MiB
recv_queue: 128MiB
global:
send_queue: 512MiB
recv_queue: 512MiB
info:
gc_pause: 200ms
warn:
gc_pause: 1000ms
large_partition: 100mb
tombstones: 1000
batch_size: 5kb
partitions_in_unlogged_batch: 10
fail:
tombstones: 10
batch_size: 50kb
corrupt_value_size: 256mb
{code}
The open debate that I am seeing is on grouping within the "limits" section
(and not seeing anyone disagreeing about a limits section); the debate that I
see is: do we group under info/warn/fail or do we group at the feature which
also offers info/warn/fail?
aka (all under limits section; doing on browser so spaces maybe off)
[~benedict]
{code}
info:
gc_pause: 200ms
warn:
gc_pause: 1000ms
large_partition: 100mb
tombstones: 1000
batch_size: 5kb
partitions_in_unlogged_batch: 10
replica_filtering_protection_cached_rows_threshold: 2000
coordinator_read_size: 1g
local_read_size: 2g
row_index_size: 1g
fail:
tombstones: 10
batch_size: 50kb
corrupt_value_size: 256mb
replica_filtering_protection_cached_rows_threshold: 32000
coordinator_read_size: 2g
local_read_size: 2g
row_index_size: 2g
{code}
vs
{code}
replica_filtering_protection:
cached_rows:
warn: 2000
fail: 32000
gc_pause:
info: 200ms
warn: 1s
large_partition:
warn: 100mb
fail: 1gb (being added in CASSANDRA-17258)
batch_size:
warn: 5kb
fail: 50kb
coordinator_read_size:
warn: 1g
fail: 2g
local_read_size:
warn: 1g
fail: 2g
row_index_size:
warn: 1g
fail: 2g
{code}
Personally I am in favor of the second option; I find grouping based off the
feature/domain is the best for the following reasons
1) everything for a single topic is together
2) if people don't like nested structures, the names make more sense
(CASSANDRA-17166 will add support for dot-notation names for people who don't
like nested: limits.large_partition.warn: 100mb vs limits.warn.large_partition:
100mb); this I admit is a personal preference
3) easier to maintain in code, as naming isn't copy/pasted against multiple
objects, but rather we can use shared data types (in track_warnings I had
inconsistencies constantly until I moved to shared data types, they really help
with maintaining standard names)
If we can agree on a final structure, then the guardrail patches can move the
new stuff in that direction, and others are free to migrate existing configs to
the new structure.
> Migrate threshold for minimum keyspace replication factor to guardrails
>
[jira] [Commented] (CASSANDRA-17188) Guardrails for consistency levels
[
https://issues.apache.org/jira/browse/CASSANDRA-17188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480183#comment-17480183
]
Benedict Elliott Smith commented on CASSANDRA-17188:
I think it is reasonable to ask that a proposal is made for how guardrails will
coherently fit into the public APIs it will interface with. I don't think this
has been discussed anywhere that I have seen - at least not broadly. This isn't
in my opinion "freezing" anything as it's a core part of the proposed work.
I am not sold on the idea that work should be committed without considering
these design elements, with the justification that it can be refactored later.
In my opinion that's the same as abdicating the design work.
> Guardrails for consistency levels
> -
>
> Key: CASSANDRA-17188
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17188
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.x
>
>
> Add guardrails for read/write consistency levels, for example:
> {code:java}
> # Guardrail to warn about or reject read consistency levels.
> # By default all consistency levels are allowed.
> read_consistency_levels:
> warned: []
> disallowed: []
> # Guardrail to warn about or reject write consistency levels.
> # By default all consistency levels are allowed.
> write_consistency_levels:
> warned: []
> disallowed: []
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17188) Guardrails for consistency levels
[
https://issues.apache.org/jira/browse/CASSANDRA-17188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480181#comment-17480181
]
Ekaterina Dimitrova commented on CASSANDRA-17188:
-
I agree with [~jmckenzie] that I don't see a reason to block feature
development.
Also, I will be more than happy to review tickets for further incremental
improvements of our config post CASSANDRA-15234 which I expect to be merged
very soon.
> Guardrails for consistency levels
> -
>
> Key: CASSANDRA-17188
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17188
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.x
>
>
> Add guardrails for read/write consistency levels, for example:
> {code:java}
> # Guardrail to warn about or reject read consistency levels.
> # By default all consistency levels are allowed.
> read_consistency_levels:
> warned: []
> disallowed: []
> # Guardrail to warn about or reject write consistency levels.
> # By default all consistency levels are allowed.
> write_consistency_levels:
> warned: []
> disallowed: []
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17279) WEBSITE - update various pages to reflect CI process
[ https://issues.apache.org/jira/browse/CASSANDRA-17279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480172#comment-17480172 ] Josh McKenzie commented on CASSANDRA-17279: --- Could also remove content from cwiki and just redirect from there to official website if we're so inclined. Probably don't want to do that until content's fully stabilized as friction to editing on wiki is considerably lower than official site still. > WEBSITE - update various pages to reflect CI process > > > Key: CASSANDRA-17279 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17279 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Josh McKenzie >Priority: Normal > > See [wiki > article|https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=199530280] > See [dev list > discussion|https://lists.apache.org/thread/bq470ml17g106pwxpvwgws2stxc6d7b9] > We have a few new sites on the confluence wiki that need to at least be > linked from the official site, or preferentially have the content updated > over there to reflect what we've updated here. > We should also leave a bread crumb / trail as comments there / notes in the > cwiki to keep the content in sync between the two sources. Given how low > friction wiki updates are this shouldn't represent significant content > creation overhead; the risk is stagnation / staleness. > Pages: > 1. Build Lead: > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=199527692 > 2. Patching, versioning, and LTS releases: > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=199530302 > 3. Cassandra CI process: > https://cwiki.apache.org/confluence/display/CASSANDRA/Cassandra+CI+Process -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16878) Race in commit log replay can cause rejected mutations
[ https://issues.apache.org/jira/browse/CASSANDRA-16878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yifan Cai updated CASSANDRA-16878: -- Reviewers: Berenguer Blasi, Jacek Lewandowski, Yifan Cai (was: Berenguer Blasi, Jacek Lewandowski) > Race in commit log replay can cause rejected mutations > -- > > Key: CASSANDRA-16878 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16878 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Local Write-Read Paths >Reporter: Andres de la Peña >Assignee: Andres de la Peña >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x > > Time Spent: 1h 20m > Remaining Estimate: 0h > > We don't force order in the execution of replayed mutations and hence a > mutation can move ahead of or behind a schema change it relies on (e.g. > added/removed column), which can then cause it to be rejected because of a > schema mismatch. > To fix this, we need to identify schema mutations and make sure the log > enforces their execution after all previous mutations have completed and > before anything following is started. > Schema mutations are > [flushed|https://github.com/apache/cassandra/blob/cassandra-4.0.0/src/java/org/apache/cassandra/schema/SchemaKeyspace.java#L1266-L1271] > after being applied, so this only would be a problem if the node abruptly > stops before flushing the schema mutation. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17279) WEBSITE - update various pages to reflect CI process
[ https://issues.apache.org/jira/browse/CASSANDRA-17279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh McKenzie updated CASSANDRA-17279: -- Component/s: Documentation/Website > WEBSITE - update various pages to reflect CI process > > > Key: CASSANDRA-17279 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17279 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Josh McKenzie >Priority: Normal > > See [wiki > article|https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=199530280] > See [dev list > discussion|https://lists.apache.org/thread/bq470ml17g106pwxpvwgws2stxc6d7b9] > We have a few new sites on the confluence wiki that need to at least be > linked from the official site, or preferentially have the content updated > over there to reflect what we've updated here. > We should also leave a bread crumb / trail as comments there / notes in the > cwiki to keep the content in sync between the two sources. Given how low > friction wiki updates are this shouldn't represent significant content > creation overhead; the risk is stagnation / staleness. > Pages: > 1. Build Lead: > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=199527692 > 2. Patching, versioning, and LTS releases: > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=199530302 > 3. Cassandra CI process: > https://cwiki.apache.org/confluence/display/CASSANDRA/Cassandra+CI+Process -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17279) WEBSITE - update various pages to reflect CI process
Josh McKenzie created CASSANDRA-17279: - Summary: WEBSITE - update various pages to reflect CI process Key: CASSANDRA-17279 URL: https://issues.apache.org/jira/browse/CASSANDRA-17279 Project: Cassandra Issue Type: Task Reporter: Josh McKenzie See [wiki article|https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=199530280] See [dev list discussion|https://lists.apache.org/thread/bq470ml17g106pwxpvwgws2stxc6d7b9] We have a few new sites on the confluence wiki that need to at least be linked from the official site, or preferentially have the content updated over there to reflect what we've updated here. We should also leave a bread crumb / trail as comments there / notes in the cwiki to keep the content in sync between the two sources. Given how low friction wiki updates are this shouldn't represent significant content creation overhead; the risk is stagnation / staleness. Pages: 1. Build Lead: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=199527692 2. Patching, versioning, and LTS releases: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=199530302 3. Cassandra CI process: https://cwiki.apache.org/confluence/display/CASSANDRA/Cassandra+CI+Process -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17188) Guardrails for consistency levels
[
https://issues.apache.org/jira/browse/CASSANDRA-17188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480166#comment-17480166
]
Caleb Rackliffe edited comment on CASSANDRA-17188 at 1/21/22, 4:24 PM:
---
[~benedict] Aside from this, I still think we (more than happy to do it myself)
should create a new Jira that _does_ start to socialize our overall proposal(s)
for the config as soon as CASSANDRA-15234 merges. Even if we intend for that to
be a 5.0 item, it can inform the guardrails/limits work here before it gets
release in 4.1, which is the worry I'm sure you and I both have around this.
was (Author: maedhroz):
[~benedict] Aside from this, I still think we (more than happy to do it myself)
should create a new Jira that _does_ start to socialize our overall proposal(s)
for the config as soon as CASSANDRA-15234 merges, even if we intend for that to
be a 5.0 item.
> Guardrails for consistency levels
> -
>
> Key: CASSANDRA-17188
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17188
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.x
>
>
> Add guardrails for read/write consistency levels, for example:
> {code:java}
> # Guardrail to warn about or reject read consistency levels.
> # By default all consistency levels are allowed.
> read_consistency_levels:
> warned: []
> disallowed: []
> # Guardrail to warn about or reject write consistency levels.
> # By default all consistency levels are allowed.
> write_consistency_levels:
> warned: []
> disallowed: []
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17188) Guardrails for consistency levels
[
https://issues.apache.org/jira/browse/CASSANDRA-17188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480166#comment-17480166
]
Caleb Rackliffe commented on CASSANDRA-17188:
-
[~benedict] Aside from this, I still think we (more than happy to do it myself)
should create a new Jira that _does_ start to socialize our overall proposal(s)
for the config as soon as CASSANDRA-15234 merges, even if we intend for that to
be a 5.0 item.
> Guardrails for consistency levels
> -
>
> Key: CASSANDRA-17188
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17188
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.x
>
>
> Add guardrails for read/write consistency levels, for example:
> {code:java}
> # Guardrail to warn about or reject read consistency levels.
> # By default all consistency levels are allowed.
> read_consistency_levels:
> warned: []
> disallowed: []
> # Guardrail to warn about or reject write consistency levels.
> # By default all consistency levels are allowed.
> write_consistency_levels:
> warned: []
> disallowed: []
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17188) Guardrails for consistency levels
[
https://issues.apache.org/jira/browse/CASSANDRA-17188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480163#comment-17480163
]
Caleb Rackliffe commented on CASSANDRA-17188:
-
bq. I'd be happy waiting for CASSANDRA-15234 if we think that the rebase it's
easier. In the end we don't even have a reviewer for this ticket yet,
CASSANDRA-15234 is almost ready, and I'm already waiting for that ticket before
start working on other guardrails that will require measurement units.
It should be soon. [~dcapwell] and I are done with our reviews, and most of the
conversations from it have been resolved.
[~benedict] Do you think we should freeze all ongoing guardrails work on the
entire YAML restructuring that you and I have proposed
[here|https://github.com/maedhroz/cassandra/commit/49e83c70eba3357978d1081ecf500bbbdee960d8]
and
[here|https://github.com/belliottsmith/cassandra/commits/CASSANDRA-15234-grouping-ideas],
or just the more specific conversation around how the "limits" or "guardrails"
section in the config should look? As long as we have basic agreement that
there will be such a section, the scope of the conversation seems manageable
and something we can solve by the time we release 4.1. It's literally this in
trunk right now:
{noformat}
# Guardrails settings.
# guardrails:
# Whether guardrails are enabled or not. Guardrails are disabled by default.
# enabled: false
# Guardrail to warn or abort when creating more user keyspaces than threshold.
# The two thresholds default to -1 to disable.
# keyspaces:
# warn_threshold: -1
# abort_threshold: -1
# Guardrail to warn or abort when creating more user tables than threshold.
# The two thresholds default to -1 to disable.
# tables:
# warn_threshold: -1
# abort_threshold: -1
# Guardrail to warn or abort when creating/altering a table with more columns
per table than threshold.
# The two thresholds default to -1 to disable.
# columns_per_table:
# warn_threshold: -1
# abort_threshold: -1
# Guardrail to warn or abort when creating more secondary indexes per table
than threshold.
# The two thresholds default to -1 to disable.
# secondary_indexes_per_table:
# warn_threshold: -1
# abort_threshold: -1
# Guardrail to warn or abort when creating more materialized views per table
than threshold.
# The two thresholds default to -1 to disable.
# materialized_views_per_table:
# warn_threshold: -1
# abort_threshold: -1
# Guardrail to ignore or reject properties when creating tables. By default all
properties are allowed.
# table_properties:
# ignored: []
# disallowed: []
# Guardrail to allow/disallow user-provided timestamps. Defaults to true.
# user_timestamps_enabled: true
# Guardrail to warn or abort when using a page size greater than threshold.
# The two thresholds default to -1 to disable.
# page_size:
# warn_threshold: -1
# abort_threshold: -1
# Guardrail to allow/disallow list operations that require read before write,
i.e. setting list element by index and
# removing list elements by either index or value. Defaults to true.
# read_before_write_list_operations_enabled: true
{noformat}
We could always drag it back to the mailing list, but it's not really that
huge, and the proposals we might have for or against it in its current form
probably only deal with a few axes of design/layout.
> Guardrails for consistency levels
> -
>
> Key: CASSANDRA-17188
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17188
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.x
>
>
> Add guardrails for read/write consistency levels, for example:
> {code:java}
> # Guardrail to warn about or reject read consistency levels.
> # By default all consistency levels are allowed.
> read_consistency_levels:
> warned: []
> disallowed: []
> # Guardrail to warn about or reject write consistency levels.
> # By default all consistency levels are allowed.
> write_consistency_levels:
> warned: []
> disallowed: []
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters
[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480155#comment-17480155
]
Caleb Rackliffe edited comment on CASSANDRA-15234 at 1/21/22, 4:06 PM:
---
+1 on "fail"...we already use "abort" in many situations that relate to
transactions
was (Author: maedhroz):
+1 on fail...we already use "abort" in many situations that relate to
transactions
> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase,
> both from the yams and JVM properties. It would be nice to standardise the
> naming (such as otc_ vs internode_) as well as the provision of values with
> units - while maintaining perpetual backwards compatibility with the old
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s,
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or
> powers of 1000 such as {{KB/s}}, given these are regularly used for either
> their old or new definition e.g. {{KiB/s}}, or we could support them and
> simply log the value in bytes/s.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480155#comment-17480155
]
Caleb Rackliffe commented on CASSANDRA-15234:
-
+1 on fail...we already use "abort" in many situations that relate to
transactions
> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase,
> both from the yams and JVM properties. It would be nice to standardise the
> naming (such as otc_ vs internode_) as well as the provision of values with
> units - while maintaining perpetual backwards compatibility with the old
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s,
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or
> powers of 1000 such as {{KB/s}}, given these are regularly used for either
> their old or new definition e.g. {{KiB/s}}, or we could support them and
> simply log the value in bytes/s.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17273) Lazy transaction log replica creation allows incorrect replica content divergence during compaction
[
https://issues.apache.org/jira/browse/CASSANDRA-17273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-17273:
Reviewers: Caleb Rackliffe
> Lazy transaction log replica creation allows incorrect replica content
> divergence during compaction
> ---
>
> Key: CASSANDRA-17273
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17273
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair, Local/Compaction
>Reporter: Caleb Rackliffe
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> Recently encountered this around compaction/anticompaction:
> {noformat}
> 2022-01-13 10:18:24,325 ERROR [main]
> org.apache.cassandra.db.lifecycle.LogTransaction - Unexpected disk state:
> failed to read transaction log
> [mf_txn_anticompactionafterrepair_2f826324-742c-11ec-b293-65cae21e111c.log in
> .../d1/data/.../files-c351f12917af3a5cbc57791cdf178a1f,
> .../d2/data/.../files-c351f12917af3a5cbc57791cdf178a1f]
> Files and contents follow:
> .../d1/data/.../files-c351f12917af3a5cbc57791cdf178a1f/mf_txn_anticompactionafterrepair_2f826324-742c-11ec-b293-65cae21e111c.log
>
> ADD:[.../d2/data/.../files-c351f12917af3a5cbc57791cdf178a1f/prod_p203-files-mf-350438-big,0,8][2380834168]
>
> REMOVE:[.../d2/data/.../files-c351f12917af3a5cbc57791cdf178a1f/prod_p203-files-mf-350435-big,1642049328006,8][2338829485]
>
> REMOVE:[.../d1/data/.../files-c351f12917af3a5cbc57791cdf178a1f/prod_p203-files-mf-350436-big,1642049366291,8][4248366924]
> COMMIT:[,0,0][2613697770]
> .../d2/data/.../files-c351f12917af3a5cbc57791cdf178a1f/mf_txn_anticompactionafterrepair_2f826324-742c-11ec-b293-65cae21e111c.log
>
> ADD:[.../d2/data/.../files-c351f12917af3a5cbc57791cdf178a1f/prod_p203-files-mf-350437-big,0,8][4051162457]
> ***Does not match
>
> in first replica file
>
> ADD:[.../d2/data/.../files-c351f12917af3a5cbc57791cdf178a1f/prod_p203-files-mf-350438-big,0,8][2380834168]
>
> REMOVE:[.../d2/data/.../files-c351f12917af3a5cbc57791cdf178a1f/prod_p203-files-mf-350435-big,1642049328006,8][2338829485]
>
> REMOVE:[.../d1/data/.../files-c351f12917af3a5cbc57791cdf178a1f/prod_p203-files-mf-350436-big,1642049366291,8][4248366924]
> COMMIT:[,0,0][2613697770]
> {noformat}
> We have two data directories and two transaction log files, but one is
> missing an ADD entry when the contents of the two log replicas should be
> identical. One scenario that can cause this is the following:
> 1. Start anticompaction on a single file, in directory {{/tmp/d0}}.
> 2. Call {{trackNew()}} with 2 new files, both in a single directory, but in
> directory {{/tmp/d1}}. This initializes the log file in {{/tmp/d1}}, but
> there is still no log file in {{/tmp/d0}}.
> 3. Anticompaction only writes to one of the files in {{/tmp/d1}} (say all
> other keys were outside the repaired range).
> 4. When anticompaction is done, the empty writer is aborted and we call
> {{untrackNew()}}, which removes the added file from the registered log
> “records" (BUT NOT FROM DISK in {{/tmp/d1}}).
> 5. The REMOVE record is added. This references {{/tmp/d0}}. We lazily create
> the log file there by dumping all the records we have in memory to that file,
> which does not include the aborted SSTable above.
> 6. Now the log files contain:
> {noformat}
> /tmp/d1/logfile.log:
> ADD:[/tmp/d1/AntiCompactionTest/AntiCompactionTest-e4fdddf0746e11ecb73ad5a997381615/AntiCompactionTest-AntiCompactionTest-mf-2-big,0,8][3268492367]
> ADD:[/tmp/d1/AntiCompactionTest/AntiCompactionTest-e4fdddf0746e11ecb73ad5a997381615/AntiCompactionTest-AntiCompactionTest-mf-3-big,0,8][2813724425]
> REMOVE:[/tmp/d0/AntiCompactionTest/AntiCompactionTest-e4fdddf0746e11ecb73ad5a997381615/AntiCompactionTest-AntiCompactionTest-mf-1-big,1642078019000,8][2401235379]
> COMMIT:[,0,0][2613697770]
> ** /tmp/d0/logfile.log:
> ADD:[/tmp/d1/AntiCompactionTest/AntiCompactionTest-e4fdddf0746e11ecb73ad5a997381615/AntiCompactionTest-AntiCompactionTest-mf-3-big,0,8][2813724425]
> REMOVE:[/tmp/d0/AntiCompactionTest/AntiCompactionTest-e4fdddf0746e11ecb73ad5a997381615/AntiCompactionTest-AntiCompactionTest-mf-1-big,1642078019000,8][2401235379]
> COMMIT:[,0,0][2613697770]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17188) Guardrails for consistency levels
[
https://issues.apache.org/jira/browse/CASSANDRA-17188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480151#comment-17480151
]
Andres de la Peña commented on CASSANDRA-17188:
---
This new guardrail doesn't make any changes in the current structure and just
adds to the already existent guardrails section. The new properties don't
introduce measurement units and the only part that be mismatch CASSANDRA-15234
is whether we use "fail" or "abort". I'd be happy waiting for CASSANDRA-15234
if we think that the rebase it's easier. In the end we don't even have a
reviewer for this ticket yet, CASSANDRA-15234 is almost ready, and I'm already
waiting for that ticket before start working on other guardrails that will
require measurement units.
However, I don't think we should block any tickets adding new config properties
until we do some other config refactoring, especially because I fear we'll
always we waiting for some future config refactoring. I neither think we should
block work on new features as a means to push forward a certain redesign of
config that is yet to be agreed, especially if the features are ready and the
redesign looks far away.
I understand that what we are discussing here is a general freeze of the config
file, so no new properties can be added until we settle on a new design. If
that's the case we should probably have a discussion on the mail list to
globally impose that freeze, which can be done either before or after having
agreed to that design.
CC [~e.dimitrova]
> Guardrails for consistency levels
> -
>
> Key: CASSANDRA-17188
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17188
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.x
>
>
> Add guardrails for read/write consistency levels, for example:
> {code:java}
> # Guardrail to warn about or reject read consistency levels.
> # By default all consistency levels are allowed.
> read_consistency_levels:
> warned: []
> disallowed: []
> # Guardrail to warn about or reject write consistency levels.
> # By default all consistency levels are allowed.
> write_consistency_levels:
> warned: []
> disallowed: []
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17188) Guardrails for consistency levels
[
https://issues.apache.org/jira/browse/CASSANDRA-17188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480148#comment-17480148
]
Ekaterina Dimitrova commented on CASSANDRA-17188:
-
Btw CASSANDRA-15234 is kind of ready, except if [~mck] doesn't like it in his
last round :)
About guardrails - I thought the first ticket where the general framework was
committed and approved cleaned this topic. Did anything change since then?
Otherwise, I am all in for standardization and common understanding around the
config. Good for us, good for the users.
> Guardrails for consistency levels
> -
>
> Key: CASSANDRA-17188
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17188
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.x
>
>
> Add guardrails for read/write consistency levels, for example:
> {code:java}
> # Guardrail to warn about or reject read consistency levels.
> # By default all consistency levels are allowed.
> read_consistency_levels:
> warned: []
> disallowed: []
> # Guardrail to warn about or reject write consistency levels.
> # By default all consistency levels are allowed.
> write_consistency_levels:
> warned: []
> disallowed: []
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17278) Finalize and formalize canonical set of pre-commit tests for circleci
Josh McKenzie created CASSANDRA-17278: - Summary: Finalize and formalize canonical set of pre-commit tests for circleci Key: CASSANDRA-17278 URL: https://issues.apache.org/jira/browse/CASSANDRA-17278 Project: Cassandra Issue Type: Task Reporter: Josh McKenzie See [wiki article|https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=199530280] See [dev list discussion|https://lists.apache.org/thread/bq470ml17g106pwxpvwgws2stxc6d7b9] While a lot of good work went into this on CASSANDRA-16882 and subsequent tickets, there is still some dissent on the right set of canonical jobs we should require on circleci before a merge, when certain job suites might be acceptable to skip if ever, and the configuration output itself. Success criteria here: 1. Ratify the canonical circleci job suites to be run on all commits pre-merge if using circleci 2. Determine JDK's that need to be run pre-merge 3. Update the circleci config files to match this by default 4. Determine a majority consensus on whether circle should auto-run on push or not, and integrate a "one-command" way to toggle to the alternate version + correct provisioning size (low, mid, high) to smooth out dev workflows and satisfy multiple competing personas 5. Document the above in the [Cassandra confluence wiki|https://cwiki.apache.org/confluence/display/cassandra/] and [testing|https://cassandra.apache.org/_/development/testing.html] sites -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17277) Automate updating tickets with CI results after merge
Josh McKenzie created CASSANDRA-17277:
-
Summary: Automate updating tickets with CI results after merge
Key: CASSANDRA-17277
URL: https://issues.apache.org/jira/browse/CASSANDRA-17277
Project: Cassandra
Issue Type: Task
Reporter: Josh McKenzie
>From [the wiki
>article|https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=199530280]
{quote}ci-cassandra run bot updating ticket in JIRA w/state of test run for the
SHA (JIRA Pending; to be linked)
{quote}
We already run CI for every commit (see
[example|https://ci-cassandra.apache.org/job/Cassandra-trunk/]). The goal is to
have automation that'll tie the results of a commit to the original JIRA ticket
and update it automatically w/a comment indicating:
* The results of the CI run (duration, pass, fail, # failures)
* Any potential regressions in CI from the merge w/links to job history
([example|https://ci-cassandra.apache.org/job/Cassandra-trunk/912/testReport/junit/dtest.cqlsh_tests.test_cqlsh_copy/TestCqlshCopy/test_bulk_round_trip_with_timeouts/history/])
>From a workflow perspective we want to optimize for having as minimal friction
>as possible to see the impact of one's commit on ci-cassandra and rapidly
>verify if their change appears to have destabilized any tests on that
>infrastructure.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17276) Cassandra CI Process Improvements
Josh McKenzie created CASSANDRA-17276: - Summary: Cassandra CI Process Improvements Key: CASSANDRA-17276 URL: https://issues.apache.org/jira/browse/CASSANDRA-17276 Project: Cassandra Issue Type: Epic Reporter: Josh McKenzie Assignee: Josh McKenzie Reference dev [ML Thread|https://lists.apache.org/thread/bq470ml17g106pwxpvwgws2stxc6d7b9] Reference cwiki ratified final process: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=199530280 There are some outstanding infrastructural, documentation, and automation pieces from the agreed upon CI state we need to implement. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17188) Guardrails for consistency levels
[
https://issues.apache.org/jira/browse/CASSANDRA-17188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480136#comment-17480136
]
Josh McKenzie edited comment on CASSANDRA-17188 at 1/21/22, 3:28 PM:
-
Thanks for that clarifying context Benedict.
{quote}Ideally, we would have design documents
{quote}
Hold on now, let's not get too wild here. ;)
What's the perceived work overhead / tension of refactoring whatever config
gets merged here w/regards to CASSANDRA-17212 and CASSANDRA-15234 if it hits
before they do, or the overhead of rebasing this on top of whatever we settle
on there authoritatively long-term if we move forward on all still and they
merge first?
ISTM the real risk here is this patch making it in before a major and
CASSANDRA-15234 _not_ making it leading to us releasing with a non-agreed upon
long-term config API commitment right? Perhaps the right choice is to just make
this ticket dependent on CASSANDRA-15234 and block merge of this on that so we
don't have a release get out with an API that's not widely agreed upon. We
could push this to "completion" and rebase it (sorry [~adelapena]) on top of
that one once it hits but more or less be ready to merge.
Also, in all seriousness, config parameters and formatting are (IMO) 100% an
API choice that has huge impacts on end users; it's one of the primary ways
operators interact with the system. We should think this out and have a design
doc where we talk through things high level instead of trawling through the mud
and trenches while trying to reason about it (like we so often do =/).
I'm operating under the assumption that's something we're going to
authoritatively determine separately and the work here will be deferring to
that in its final form.
was (Author: jmckenzie):
Thanks for that clarifying context Benedict.
{quote}Ideally, we would have design documents
{quote}
Hold on now, let's not get crazy here. ;)
What's the perceived work overhead / tension of refactoring whatever config
gets merged here w/regards to CASSANDRA-17212 and CASSANDRA-15234 if it hits
before they do, or the overhead of rebasing this on top of whatever we settle
on there authoritatively long-term if we move forward on all still and they
merge first?
ISTM the real risk here is this patch making it in before a major and
CASSANDRA-15234 _not_ making it leading to us releasing with a non-agreed upon
long-term config API commitment right? Perhaps the right choice is to just make
this ticket dependent on CASSANDRA-15234 and block merge of this on that so we
don't have a release get out with an API that's not widely agreed upon. We
could push this to "completion" and rebase it (sorry [~adelapena]) on top of
that one once it hits but more or less be ready to merge.
Also, in all seriousness, config parameters and formatting are (IMO) 100% an
API choice that has huge impacts on end users; it's one of the primary ways
operators interact with the system. We should think this out and have a design
doc where we talk through things high level instead of trawling through the mud
and trenches while trying to reason about it (like we so often do =/).
I'm operating under the assumption that's something we're going to
authoritatively determine separately and the work here will be deferring to
that in its final form.
> Guardrails for consistency levels
> -
>
> Key: CASSANDRA-17188
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17188
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.x
>
>
> Add guardrails for read/write consistency levels, for example:
> {code:java}
> # Guardrail to warn about or reject read consistency levels.
> # By default all consistency levels are allowed.
> read_consistency_levels:
> warned: []
> disallowed: []
> # Guardrail to warn about or reject write consistency levels.
> # By default all consistency levels are allowed.
> write_consistency_levels:
> warned: []
> disallowed: []
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17188) Guardrails for consistency levels
[
https://issues.apache.org/jira/browse/CASSANDRA-17188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480136#comment-17480136
]
Josh McKenzie commented on CASSANDRA-17188:
---
Thanks for that clarifying context Benedict.
{quote}Ideally, we would have design documents
{quote}
Hold on now, let's not get crazy here. ;)
What's the perceived work overhead / tension of refactoring whatever config
gets merged here w/regards to CASSANDRA-17212 and CASSANDRA-15234 if it hits
before they do, or the overhead of rebasing this on top of whatever we settle
on there authoritatively long-term if we move forward on all still and they
merge first?
ISTM the real risk here is this patch making it in before a major and
CASSANDRA-15234 _not_ making it leading to us releasing with a non-agreed upon
long-term config API commitment right? Perhaps the right choice is to just make
this ticket dependent on CASSANDRA-15234 and block merge of this on that so we
don't have a release get out with an API that's not widely agreed upon. We
could push this to "completion" and rebase it (sorry [~adelapena]) on top of
that one once it hits but more or less be ready to merge.
Also, in all seriousness, config parameters and formatting are (IMO) 100% an
API choice that has huge impacts on end users; it's one of the primary ways
operators interact with the system. We should think this out and have a design
doc where we talk through things high level instead of trawling through the mud
and trenches while trying to reason about it (like we so often do =/).
I'm operating under the assumption that's something we're going to
authoritatively determine separately and the work here will be deferring to
that in its final form.
> Guardrails for consistency levels
> -
>
> Key: CASSANDRA-17188
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17188
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.x
>
>
> Add guardrails for read/write consistency levels, for example:
> {code:java}
> # Guardrail to warn about or reject read consistency levels.
> # By default all consistency levels are allowed.
> read_consistency_levels:
> warned: []
> disallowed: []
> # Guardrail to warn about or reject write consistency levels.
> # By default all consistency levels are allowed.
> write_consistency_levels:
> warned: []
> disallowed: []
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17188) Guardrails for consistency levels
[
https://issues.apache.org/jira/browse/CASSANDRA-17188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480082#comment-17480082
]
Benedict Elliott Smith commented on CASSANDRA-17188:
I wonder if we should highlight this by modifying "Test and Documentation Plan"
to "Test, Documentation and API Plan" - though I think in practice that field
is having less impact than was hoped.
> Guardrails for consistency levels
> -
>
> Key: CASSANDRA-17188
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17188
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.x
>
>
> Add guardrails for read/write consistency levels, for example:
> {code:java}
> # Guardrail to warn about or reject read consistency levels.
> # By default all consistency levels are allowed.
> read_consistency_levels:
> warned: []
> disallowed: []
> # Guardrail to warn about or reject write consistency levels.
> # By default all consistency levels are allowed.
> write_consistency_levels:
> warned: []
> disallowed: []
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17188) Guardrails for consistency levels
[
https://issues.apache.org/jira/browse/CASSANDRA-17188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480078#comment-17480078
]
Benedict Elliott Smith edited comment on CASSANDRA-17188 at 1/21/22, 1:46 PM:
--
What is a "flavor" of configuration? No coherent design for the configuration
file, and how it relates to existing context, has been presented for this epic.
This should be basic hygiene for API design in a mature project, just like
testing and QA. Once such a design has been proposed, alternatives (such as the
one I favour) can be weighed up, but right now we're talking about favouring
uncoordinated changes that consider only the change in question and none of the
broader context - even the future work part of the same declared epic. That is
really bad hygiene, whatever "flavor" you prefer.
But I anyway strongly dislike the idea of dismissing API design considerations
as flavours. There are tensions in all API design, and they need to be
discussed. While there may be people who prefer one approach over another, this
is true even for deeply technical topics, and it does not make it any less an
important consideration. Dismissing these tensions is lazy, and lands us in a
mess of incoherent design like we are addressing in CASSANDRA-15234, which is
only one part of the codebase.
was (Author: benedict):
What is a "flavor" of configuration? No coherent design for the configuration
file, and how it relates to existing context, has been presented for this epic.
This should be basic hygiene for API design in a mature project, just like
testing and QA. Once such a design has been proposed, alternatives (such as the
one I favour) can be weighed up, but right now we're talking about favouring
uncoordinated changes that consider only the change in question and none of the
broader context - even the future work part of the same declared epic. That is
really bad hygiene, whatever "flavor" you prefer.
> Guardrails for consistency levels
> -
>
> Key: CASSANDRA-17188
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17188
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.x
>
>
> Add guardrails for read/write consistency levels, for example:
> {code:java}
> # Guardrail to warn about or reject read consistency levels.
> # By default all consistency levels are allowed.
> read_consistency_levels:
> warned: []
> disallowed: []
> # Guardrail to warn about or reject write consistency levels.
> # By default all consistency levels are allowed.
> write_consistency_levels:
> warned: []
> disallowed: []
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17188) Guardrails for consistency levels
[
https://issues.apache.org/jira/browse/CASSANDRA-17188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480078#comment-17480078
]
Benedict Elliott Smith commented on CASSANDRA-17188:
What is a "flavor" of configuration? No coherent design for the configuration
file, and how it relates to existing context, has been presented for this epic.
This should be basic hygiene for API design in a mature project, just like
testing and QA. Once such a design has been proposed, alternatives (such as the
one I favour) can be weighed up, but right now we're talking about favouring
uncoordinated changes that consider only the change in question and none of the
broader context - even the future work part of the same declared epic. That is
really bad hygiene, whatever "flavor" you prefer.
> Guardrails for consistency levels
> -
>
> Key: CASSANDRA-17188
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17188
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.x
>
>
> Add guardrails for read/write consistency levels, for example:
> {code:java}
> # Guardrail to warn about or reject read consistency levels.
> # By default all consistency levels are allowed.
> read_consistency_levels:
> warned: []
> disallowed: []
> # Guardrail to warn about or reject write consistency levels.
> # By default all consistency levels are allowed.
> write_consistency_levels:
> warned: []
> disallowed: []
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17188) Guardrails for consistency levels
[
https://issues.apache.org/jira/browse/CASSANDRA-17188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480075#comment-17480075
]
Brandon Williams commented on CASSANDRA-17188:
--
I don't think configuration flavor is API design.
> Guardrails for consistency levels
> -
>
> Key: CASSANDRA-17188
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17188
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.x
>
>
> Add guardrails for read/write consistency levels, for example:
> {code:java}
> # Guardrail to warn about or reject read consistency levels.
> # By default all consistency levels are allowed.
> read_consistency_levels:
> warned: []
> disallowed: []
> # Guardrail to warn about or reject write consistency levels.
> # By default all consistency levels are allowed.
> write_consistency_levels:
> warned: []
> disallowed: []
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17265) dtest byteman errors
[ https://issues.apache.org/jira/browse/CASSANDRA-17265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480074#comment-17480074 ] Brandon Williams commented on CASSANDRA-17265: -- It looks like we're using relative (to cwd) paths for all instances of byteman scripts. This is probably a bad assumption in general and we should make them all explicit. > dtest byteman errors > > > Key: CASSANDRA-17265 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17265 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/python >Reporter: Berenguer Blasi >Priority: Normal > Fix For: 4.0.x > > > Testing on another ticket I noticed 4.0 was failing 3 dtests on circle on > missing btm files. I checked and the files _are there_. Also it doesn't repro > locally. See 4.0 vanilla runs > [here|https://app.circleci.com/pipelines/github/bereng/cassandra/555/workflows/21cfe9e4-2d17-45a2-8ea8-1593b7ed6d8b] -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17265) dtest byteman errors
[ https://issues.apache.org/jira/browse/CASSANDRA-17265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480072#comment-17480072 ] Brandon Williams edited comment on CASSANDRA-17265 at 1/21/22, 1:33 PM: Looks like an explicit byteman path does the trick: [here|https://github.com/driftx/cassandra-dtest/commit/9b0a6ed0129ad0be732766aa4e81281f5972096f] -> [https://app.circleci.com/pipelines/github/driftx/cassandra/339/workflows/bb81d632-ceb6-407a-8f09-d71d466e611e/jobs/3524] Only circle knows why and just these tests. was (Author: brandon.williams): Looks like an explicit byteman path does the trick: [https://app.circleci.com/pipelines/github/driftx/cassandra/339/workflows/bb81d632-ceb6-407a-8f09-d71d466e611e/jobs/3524] Only circle knows why and just these tests. > dtest byteman errors > > > Key: CASSANDRA-17265 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17265 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/python >Reporter: Berenguer Blasi >Priority: Normal > Fix For: 4.0.x > > > Testing on another ticket I noticed 4.0 was failing 3 dtests on circle on > missing btm files. I checked and the files _are there_. Also it doesn't repro > locally. See 4.0 vanilla runs > [here|https://app.circleci.com/pipelines/github/bereng/cassandra/555/workflows/21cfe9e4-2d17-45a2-8ea8-1593b7ed6d8b] -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17265) dtest byteman errors
[ https://issues.apache.org/jira/browse/CASSANDRA-17265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480072#comment-17480072 ] Brandon Williams commented on CASSANDRA-17265: -- Looks like an explicit byteman path does the trick: [https://app.circleci.com/pipelines/github/driftx/cassandra/339/workflows/bb81d632-ceb6-407a-8f09-d71d466e611e/jobs/3524] Only circle knows why and just these tests. > dtest byteman errors > > > Key: CASSANDRA-17265 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17265 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/python >Reporter: Berenguer Blasi >Priority: Normal > Fix For: 4.0.x > > > Testing on another ticket I noticed 4.0 was failing 3 dtests on circle on > missing btm files. I checked and the files _are there_. Also it doesn't repro > locally. See 4.0 vanilla runs > [here|https://app.circleci.com/pipelines/github/bereng/cassandra/555/workflows/21cfe9e4-2d17-45a2-8ea8-1593b7ed6d8b] -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17188) Guardrails for consistency levels
[
https://issues.apache.org/jira/browse/CASSANDRA-17188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480071#comment-17480071
]
Benedict Elliott Smith commented on CASSANDRA-17188:
> I agree, the bikeshed can always be painted the color we want later.
I think it is a real shame to consider API design bike-shedding.
> Guardrails for consistency levels
> -
>
> Key: CASSANDRA-17188
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17188
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.x
>
>
> Add guardrails for read/write consistency levels, for example:
> {code:java}
> # Guardrail to warn about or reject read consistency levels.
> # By default all consistency levels are allowed.
> read_consistency_levels:
> warned: []
> disallowed: []
> # Guardrail to warn about or reject write consistency levels.
> # By default all consistency levels are allowed.
> write_consistency_levels:
> warned: []
> disallowed: []
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17188) Guardrails for consistency levels
[
https://issues.apache.org/jira/browse/CASSANDRA-17188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480070#comment-17480070
]
Benedict Elliott Smith commented on CASSANDRA-17188:
Since this work is introducing a new concept to the configuration file that
intends to supersede existing concepts, it's sort of inherently a refactor no?
Whether or not it migrates anything in this ticket. The context of this
discussion was anyway the epic as a whole, and I'm sure I've seen several
"migration" tickets that refactor existing config. So I'd say in both ways
we're tightly coupled with that, and punting on it is IMO not great.
I think the project in general suffers from a failure take a holistic view of
its APIs, and I would prefer to see us start thinking about this earlier in the
design process. API design is hard, and leaving it until the last minute (so it
has a good chance of just being underinvested in, and "good enough") risks
perpetuating this legacy of poorly considered/incoherent API, which the yaml is
an important part of. Ideally, we would have design documents that all of our
config follows, and when we introduce new configurations we should expand the
design to account for them so that all future changes remain coherent. That
might be too much here, but at least settling on how this work fits in with
existing configuration, and its own declared near-future changes seems a
reasonable expectation.
> Guardrails for consistency levels
> -
>
> Key: CASSANDRA-17188
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17188
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.x
>
>
> Add guardrails for read/write consistency levels, for example:
> {code:java}
> # Guardrail to warn about or reject read consistency levels.
> # By default all consistency levels are allowed.
> read_consistency_levels:
> warned: []
> disallowed: []
> # Guardrail to warn about or reject write consistency levels.
> # By default all consistency levels are allowed.
> write_consistency_levels:
> warned: []
> disallowed: []
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17188) Guardrails for consistency levels
[
https://issues.apache.org/jira/browse/CASSANDRA-17188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480065#comment-17480065
]
Brandon Williams commented on CASSANDRA-17188:
--
bq. I don't think there's a problem continuing here.
I agree, the bikeshed can always be painted the color we want later.
> Guardrails for consistency levels
> -
>
> Key: CASSANDRA-17188
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17188
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.x
>
>
> Add guardrails for read/write consistency levels, for example:
> {code:java}
> # Guardrail to warn about or reject read consistency levels.
> # By default all consistency levels are allowed.
> read_consistency_levels:
> warned: []
> disallowed: []
> # Guardrail to warn about or reject write consistency levels.
> # By default all consistency levels are allowed.
> write_consistency_levels:
> warned: []
> disallowed: []
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17188) Guardrails for consistency levels
[
https://issues.apache.org/jira/browse/CASSANDRA-17188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480059#comment-17480059
]
Josh McKenzie commented on CASSANDRA-17188:
---
The PR here looks to have a minimal addition to the .yaml that would be easy to
integrate into CASSANDRA-17212 or rebase on top of that afaict:
[link|https://github.com/apache/cassandra/pull/1392/files#diff-77707d0908c31940828b6425dcb09a7409827db99b48c371f71c63294dfe1562R1625-R1632].
I don't think there's a problem continuing here.
A quick skim of the patch shows the expected property accessors for it and not
a large yaml restructing overhaul. I could be missing something however.
> Guardrails for consistency levels
> -
>
> Key: CASSANDRA-17188
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17188
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.x
>
>
> Add guardrails for read/write consistency levels, for example:
> {code:java}
> # Guardrail to warn about or reject read consistency levels.
> # By default all consistency levels are allowed.
> read_consistency_levels:
> warned: []
> disallowed: []
> # Guardrail to warn about or reject write consistency levels.
> # By default all consistency levels are allowed.
> write_consistency_levels:
> warned: []
> disallowed: []
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17188) Guardrails for consistency levels
[
https://issues.apache.org/jira/browse/CASSANDRA-17188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480060#comment-17480060
]
Andres de la Peña commented on CASSANDRA-17188:
---
[~benedict] here we are adding new properties to the current guardrails section
that came as a result of CASSANDRA-17147 and that mail list discussion about
nesting, and that is mostly identical to the existing track_warnings. No
current property from the yaml is migrated nor rearranged here.
> Guardrails for consistency levels
> -
>
> Key: CASSANDRA-17188
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17188
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.x
>
>
> Add guardrails for read/write consistency levels, for example:
> {code:java}
> # Guardrail to warn about or reject read consistency levels.
> # By default all consistency levels are allowed.
> read_consistency_levels:
> warned: []
> disallowed: []
> # Guardrail to warn about or reject write consistency levels.
> # By default all consistency levels are allowed.
> write_consistency_levels:
> warned: []
> disallowed: []
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17265) dtest byteman errors
[ https://issues.apache.org/jira/browse/CASSANDRA-17265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480051#comment-17480051 ] Brandon Williams commented on CASSANDRA-17265: -- Indeed, it runs with vnodes (and for completeness, passes for me.) This seems like its own bit of oversight, since that shouldn't (in)validate the test. > dtest byteman errors > > > Key: CASSANDRA-17265 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17265 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/python >Reporter: Berenguer Blasi >Priority: Normal > Fix For: 4.0.x > > > Testing on another ticket I noticed 4.0 was failing 3 dtests on circle on > missing btm files. I checked and the files _are there_. Also it doesn't repro > locally. See 4.0 vanilla runs > [here|https://app.circleci.com/pipelines/github/bereng/cassandra/555/workflows/21cfe9e4-2d17-45a2-8ea8-1593b7ed6d8b] -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17188) Guardrails for consistency levels
[
https://issues.apache.org/jira/browse/CASSANDRA-17188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480033#comment-17480033
]
Benedict Elliott Smith commented on CASSANDRA-17188:
[~adelapena] you are actively restructuring the yaml as part of this work, so
what shape it should take is inherently part of this work as far as I can tell?
> Guardrails for consistency levels
> -
>
> Key: CASSANDRA-17188
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17188
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.x
>
>
> Add guardrails for read/write consistency levels, for example:
> {code:java}
> # Guardrail to warn about or reject read consistency levels.
> # By default all consistency levels are allowed.
> read_consistency_levels:
> warned: []
> disallowed: []
> # Guardrail to warn about or reject write consistency levels.
> # By default all consistency levels are allowed.
> write_consistency_levels:
> warned: []
> disallowed: []
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480032#comment-17480032
]
Benedict Elliott Smith commented on CASSANDRA-15234:
+1 for {{fail}}
> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase,
> both from the yams and JVM properties. It would be nice to standardise the
> naming (such as otc_ vs internode_) as well as the provision of values with
> units - while maintaining perpetual backwards compatibility with the old
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s,
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or
> powers of 1000 such as {{KB/s}}, given these are regularly used for either
> their old or new definition e.g. {{KiB/s}}, or we could support them and
> simply log the value in bytes/s.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17212) Migrate threshold for minimum keyspace replication factor to guardrails
[
https://issues.apache.org/jira/browse/CASSANDRA-17212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480031#comment-17480031
]
Benedict Elliott Smith commented on CASSANDRA-17212:
That isn't the right way to go about things IMO. If we are porting things, and
introducing new configurations, we should consider how they fit together
properly upfront - particularly if there is disagreement about how it should
work. Punting on this in the past is why our config file is a complete mess
today, and why Ekaterina has had to put in so much work to fix it.
> Migrate threshold for minimum keyspace replication factor to guardrails
> ---
>
> Key: CASSANDRA-17212
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17212
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Priority: Normal
>
> The config property
> [{{minimum_keyspace_rf}}|https://github.com/apache/cassandra/blob/5fdadb25f95099b8945d9d9ee11d3e380d3867f4/conf/cassandra.yaml]
> that was added by CASSANDRA-14557 can be migrated to guardrails, for example:
> {code}
> guardrails:
> ...
> replication_factor:
> warn_threshold: 2
> abort_threshold: 3
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17212) Migrate threshold for minimum keyspace replication factor to guardrails
[
https://issues.apache.org/jira/browse/CASSANDRA-17212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480026#comment-17480026
]
Andres de la Peña commented on CASSANDRA-17212:
---
I agree that we should move toward nesting, the part that I'm not convinced
about is grouping warn/fail thresholds.
That dev mail discussion thread about nesting was started during the guardrails
prototype, that's why guardrails are already nested. We might change how
properties are grouped and/or named in the future, but I also think that those
changes can be easily retrofitted at a later stage, and that shouldn't stop us
from adding new guardrails with the current structure. The guardrails framework
systematizes how certain soft/hard limits are treated, so it should make it
easier for us to move to a different yaml structure once we have agreed on it,
compared to porting many ad-hoc limits.
> Migrate threshold for minimum keyspace replication factor to guardrails
> ---
>
> Key: CASSANDRA-17212
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17212
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Priority: Normal
>
> The config property
> [{{minimum_keyspace_rf}}|https://github.com/apache/cassandra/blob/5fdadb25f95099b8945d9d9ee11d3e380d3867f4/conf/cassandra.yaml]
> that was added by CASSANDRA-14557 can be migrated to guardrails, for example:
> {code}
> guardrails:
> ...
> replication_factor:
> warn_threshold: 2
> abort_threshold: 3
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
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 (43bcee5 -> 5f2beae)
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 43bcee5 generate docs for a0022ebd new 5f2beae generate docs for a0022ebd 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 (43bcee5) \ N -- N -- N refs/heads/asf-staging (5f2beae) 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 4740057 -> 4740057 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] [Assigned] (CASSANDRA-17275) FAQ page contains bullet list of div tags
[ https://issues.apache.org/jira/browse/CASSANDRA-17275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Grasso reassigned CASSANDRA-17275: -- Assignee: Andrew Hogg (was: Anthony Grasso) > FAQ page contains bullet list of div tags > - > > Key: CASSANDRA-17275 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17275 > Project: Cassandra > Issue Type: Bug > Components: Documentation/Website >Reporter: Andrew Hogg >Assignee: Andrew Hogg >Priority: Normal > Fix For: 3.11.x, 4.0.x > > Attachments: Screenshot 2022-01-21 at 10.28.16.png > > Time Spent: 10m > Remaining Estimate: 0h > > Within the versioned documentation, the FAQ page has a bullet list at the top > which relates to the div's within the layout that is used for navigation. > This bullet list is not a set of hyperlinks / clickable, they are just shown. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17275) FAQ page contains bullet list of div tags
[ https://issues.apache.org/jira/browse/CASSANDRA-17275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Grasso reassigned CASSANDRA-17275: -- Assignee: Anthony Grasso (was: Andrew Hogg) > FAQ page contains bullet list of div tags > - > > Key: CASSANDRA-17275 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17275 > Project: Cassandra > Issue Type: Bug > Components: Documentation/Website >Reporter: Andrew Hogg >Assignee: Anthony Grasso >Priority: Normal > Fix For: 3.11.x, 4.0.x > > Attachments: Screenshot 2022-01-21 at 10.28.16.png > > Time Spent: 10m > Remaining Estimate: 0h > > Within the versioned documentation, the FAQ page has a bullet list at the top > which relates to the div's within the layout that is used for navigation. > This bullet list is not a set of hyperlinks / clickable, they are just shown. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17275) FAQ page contains bullet list of div tags
[ https://issues.apache.org/jira/browse/CASSANDRA-17275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Grasso updated CASSANDRA-17275: --- Reviewers: Anthony Grasso, Anthony Grasso Anthony Grasso, Anthony Grasso (was: Anthony Grasso) Status: Review In Progress (was: Patch Available) > FAQ page contains bullet list of div tags > - > > Key: CASSANDRA-17275 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17275 > Project: Cassandra > Issue Type: Bug > Components: Documentation/Website >Reporter: Andrew Hogg >Assignee: Anthony Grasso >Priority: Normal > Fix For: 3.11.x, 4.0.x > > Attachments: Screenshot 2022-01-21 at 10.28.16.png > > Time Spent: 10m > Remaining Estimate: 0h > > Within the versioned documentation, the FAQ page has a bullet list at the top > which relates to the div's within the layout that is used for navigation. > This bullet list is not a set of hyperlinks / clickable, they are just shown. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17275) FAQ page contains bullet list of div tags
[ https://issues.apache.org/jira/browse/CASSANDRA-17275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Hogg updated CASSANDRA-17275: Impacts: Docs (was: None) Test and Documentation Plan: Website was built using : ./run.sh website build -g -b cassandra:cassandra-3.11 -u cassandra:/andrewhogg-cassandra and manually inspected. Status: Patch Available (was: In Progress) > FAQ page contains bullet list of div tags > - > > Key: CASSANDRA-17275 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17275 > Project: Cassandra > Issue Type: Bug > Components: Documentation/Website >Reporter: Andrew Hogg >Assignee: Andrew Hogg >Priority: Normal > Fix For: 3.11.x, 4.0.x > > Attachments: Screenshot 2022-01-21 at 10.28.16.png > > Time Spent: 10m > Remaining Estimate: 0h > > Within the versioned documentation, the FAQ page has a bullet list at the top > which relates to the div's within the layout that is used for navigation. > This bullet list is not a set of hyperlinks / clickable, they are just shown. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17275) FAQ page contains bullet list of div tags
[ https://issues.apache.org/jira/browse/CASSANDRA-17275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17479992#comment-17479992 ] Andrew Hogg commented on CASSANDRA-17275: - Pull request opened : [https://github.com/apache/cassandra/pull/1418] This change will apply to 3.11, 4.0 and trunk. > FAQ page contains bullet list of div tags > - > > Key: CASSANDRA-17275 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17275 > Project: Cassandra > Issue Type: Bug > Components: Documentation/Website >Reporter: Andrew Hogg >Assignee: Andrew Hogg >Priority: Normal > Fix For: 3.11.x, 4.0.x > > Attachments: Screenshot 2022-01-21 at 10.28.16.png > > Time Spent: 10m > Remaining Estimate: 0h > > Within the versioned documentation, the FAQ page has a bullet list at the top > which relates to the div's within the layout that is used for navigation. > This bullet list is not a set of hyperlinks / clickable, they are just shown. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17275) FAQ page contains bullet list of div tags
[ https://issues.apache.org/jira/browse/CASSANDRA-17275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Grasso updated CASSANDRA-17275: --- Bug Category: Parent values: Documentation(13562) Complexity: Low Hanging Fruit Discovered By: User Report Fix Version/s: 3.11.x 4.0.x Severity: Normal Status: Open (was: Triage Needed) > FAQ page contains bullet list of div tags > - > > Key: CASSANDRA-17275 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17275 > Project: Cassandra > Issue Type: Bug > Components: Documentation/Website >Reporter: Andrew Hogg >Assignee: Andrew Hogg >Priority: Normal > Fix For: 3.11.x, 4.0.x > > Attachments: Screenshot 2022-01-21 at 10.28.16.png > > > Within the versioned documentation, the FAQ page has a bullet list at the top > which relates to the div's within the layout that is used for navigation. > This bullet list is not a set of hyperlinks / clickable, they are just shown. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17275) FAQ page contains bullet list of div tags
Andrew Hogg created CASSANDRA-17275: --- Summary: FAQ page contains bullet list of div tags Key: CASSANDRA-17275 URL: https://issues.apache.org/jira/browse/CASSANDRA-17275 Project: Cassandra Issue Type: Bug Components: Documentation/Website Reporter: Andrew Hogg Assignee: Andrew Hogg Attachments: Screenshot 2022-01-21 at 10.28.16.png Within the versioned documentation, the FAQ page has a bullet list at the top which relates to the div's within the layout that is used for navigation. This bullet list is not a set of hyperlinks / clickable, they are just shown. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17273) Lazy transaction log replica creation allows incorrect replica content divergence during compaction
[
https://issues.apache.org/jira/browse/CASSANDRA-17273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson reassigned CASSANDRA-17273:
---
Assignee: Marcus Eriksson (was: Caleb Rackliffe)
> Lazy transaction log replica creation allows incorrect replica content
> divergence during compaction
> ---
>
> Key: CASSANDRA-17273
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17273
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair, Local/Compaction
>Reporter: Caleb Rackliffe
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> Recently encountered this around compaction/anticompaction:
> {noformat}
> 2022-01-13 10:18:24,325 ERROR [main]
> org.apache.cassandra.db.lifecycle.LogTransaction - Unexpected disk state:
> failed to read transaction log
> [mf_txn_anticompactionafterrepair_2f826324-742c-11ec-b293-65cae21e111c.log in
> .../d1/data/.../files-c351f12917af3a5cbc57791cdf178a1f,
> .../d2/data/.../files-c351f12917af3a5cbc57791cdf178a1f]
> Files and contents follow:
> .../d1/data/.../files-c351f12917af3a5cbc57791cdf178a1f/mf_txn_anticompactionafterrepair_2f826324-742c-11ec-b293-65cae21e111c.log
>
> ADD:[.../d2/data/.../files-c351f12917af3a5cbc57791cdf178a1f/prod_p203-files-mf-350438-big,0,8][2380834168]
>
> REMOVE:[.../d2/data/.../files-c351f12917af3a5cbc57791cdf178a1f/prod_p203-files-mf-350435-big,1642049328006,8][2338829485]
>
> REMOVE:[.../d1/data/.../files-c351f12917af3a5cbc57791cdf178a1f/prod_p203-files-mf-350436-big,1642049366291,8][4248366924]
> COMMIT:[,0,0][2613697770]
> .../d2/data/.../files-c351f12917af3a5cbc57791cdf178a1f/mf_txn_anticompactionafterrepair_2f826324-742c-11ec-b293-65cae21e111c.log
>
> ADD:[.../d2/data/.../files-c351f12917af3a5cbc57791cdf178a1f/prod_p203-files-mf-350437-big,0,8][4051162457]
> ***Does not match
>
> in first replica file
>
> ADD:[.../d2/data/.../files-c351f12917af3a5cbc57791cdf178a1f/prod_p203-files-mf-350438-big,0,8][2380834168]
>
> REMOVE:[.../d2/data/.../files-c351f12917af3a5cbc57791cdf178a1f/prod_p203-files-mf-350435-big,1642049328006,8][2338829485]
>
> REMOVE:[.../d1/data/.../files-c351f12917af3a5cbc57791cdf178a1f/prod_p203-files-mf-350436-big,1642049366291,8][4248366924]
> COMMIT:[,0,0][2613697770]
> {noformat}
> We have two data directories and two transaction log files, but one is
> missing an ADD entry when the contents of the two log replicas should be
> identical. One scenario that can cause this is the following:
> 1. Start anticompaction on a single file, in directory {{/tmp/d0}}.
> 2. Call {{trackNew()}} with 2 new files, both in a single directory, but in
> directory {{/tmp/d1}}. This initializes the log file in {{/tmp/d1}}, but
> there is still no log file in {{/tmp/d0}}.
> 3. Anticompaction only writes to one of the files in {{/tmp/d1}} (say all
> other keys were outside the repaired range).
> 4. When anticompaction is done, the empty writer is aborted and we call
> {{untrackNew()}}, which removes the added file from the registered log
> “records" (BUT NOT FROM DISK in {{/tmp/d1}}).
> 5. The REMOVE record is added. This references {{/tmp/d0}}. We lazily create
> the log file there by dumping all the records we have in memory to that file,
> which does not include the aborted SSTable above.
> 6. Now the log files contain:
> {noformat}
> /tmp/d1/logfile.log:
> ADD:[/tmp/d1/AntiCompactionTest/AntiCompactionTest-e4fdddf0746e11ecb73ad5a997381615/AntiCompactionTest-AntiCompactionTest-mf-2-big,0,8][3268492367]
> ADD:[/tmp/d1/AntiCompactionTest/AntiCompactionTest-e4fdddf0746e11ecb73ad5a997381615/AntiCompactionTest-AntiCompactionTest-mf-3-big,0,8][2813724425]
> REMOVE:[/tmp/d0/AntiCompactionTest/AntiCompactionTest-e4fdddf0746e11ecb73ad5a997381615/AntiCompactionTest-AntiCompactionTest-mf-1-big,1642078019000,8][2401235379]
> COMMIT:[,0,0][2613697770]
> ** /tmp/d0/logfile.log:
> ADD:[/tmp/d1/AntiCompactionTest/AntiCompactionTest-e4fdddf0746e11ecb73ad5a997381615/AntiCompactionTest-AntiCompactionTest-mf-3-big,0,8][2813724425]
> REMOVE:[/tmp/d0/AntiCompactionTest/AntiCompactionTest-e4fdddf0746e11ecb73ad5a997381615/AntiCompactionTest-AntiCompactionTest-mf-1-big,1642078019000,8][2401235379]
> COMMIT:[,0,0][2613697770]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17273) Lazy transaction log replica creation allows incorrect replica content divergence during compaction
[
https://issues.apache.org/jira/browse/CASSANDRA-17273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17479921#comment-17479921
]
Marcus Eriksson commented on CASSANDRA-17273:
-
It is not as likely to occur on 3.11+, but still needs to be fixed (compactions
write to multiple directories after range movements for example)
> Lazy transaction log replica creation allows incorrect replica content
> divergence during compaction
> ---
>
> Key: CASSANDRA-17273
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17273
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair, Local/Compaction
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> Recently encountered this around compaction/anticompaction:
> {noformat}
> 2022-01-13 10:18:24,325 ERROR [main]
> org.apache.cassandra.db.lifecycle.LogTransaction - Unexpected disk state:
> failed to read transaction log
> [mf_txn_anticompactionafterrepair_2f826324-742c-11ec-b293-65cae21e111c.log in
> .../d1/data/.../files-c351f12917af3a5cbc57791cdf178a1f,
> .../d2/data/.../files-c351f12917af3a5cbc57791cdf178a1f]
> Files and contents follow:
> .../d1/data/.../files-c351f12917af3a5cbc57791cdf178a1f/mf_txn_anticompactionafterrepair_2f826324-742c-11ec-b293-65cae21e111c.log
>
> ADD:[.../d2/data/.../files-c351f12917af3a5cbc57791cdf178a1f/prod_p203-files-mf-350438-big,0,8][2380834168]
>
> REMOVE:[.../d2/data/.../files-c351f12917af3a5cbc57791cdf178a1f/prod_p203-files-mf-350435-big,1642049328006,8][2338829485]
>
> REMOVE:[.../d1/data/.../files-c351f12917af3a5cbc57791cdf178a1f/prod_p203-files-mf-350436-big,1642049366291,8][4248366924]
> COMMIT:[,0,0][2613697770]
> .../d2/data/.../files-c351f12917af3a5cbc57791cdf178a1f/mf_txn_anticompactionafterrepair_2f826324-742c-11ec-b293-65cae21e111c.log
>
> ADD:[.../d2/data/.../files-c351f12917af3a5cbc57791cdf178a1f/prod_p203-files-mf-350437-big,0,8][4051162457]
> ***Does not match
>
> in first replica file
>
> ADD:[.../d2/data/.../files-c351f12917af3a5cbc57791cdf178a1f/prod_p203-files-mf-350438-big,0,8][2380834168]
>
> REMOVE:[.../d2/data/.../files-c351f12917af3a5cbc57791cdf178a1f/prod_p203-files-mf-350435-big,1642049328006,8][2338829485]
>
> REMOVE:[.../d1/data/.../files-c351f12917af3a5cbc57791cdf178a1f/prod_p203-files-mf-350436-big,1642049366291,8][4248366924]
> COMMIT:[,0,0][2613697770]
> {noformat}
> We have two data directories and two transaction log files, but one is
> missing an ADD entry when the contents of the two log replicas should be
> identical. One scenario that can cause this is the following:
> 1. Start anticompaction on a single file, in directory {{/tmp/d0}}.
> 2. Call {{trackNew()}} with 2 new files, both in a single directory, but in
> directory {{/tmp/d1}}. This initializes the log file in {{/tmp/d1}}, but
> there is still no log file in {{/tmp/d0}}.
> 3. Anticompaction only writes to one of the files in {{/tmp/d1}} (say all
> other keys were outside the repaired range).
> 4. When anticompaction is done, the empty writer is aborted and we call
> {{untrackNew()}}, which removes the added file from the registered log
> “records" (BUT NOT FROM DISK in {{/tmp/d1}}).
> 5. The REMOVE record is added. This references {{/tmp/d0}}. We lazily create
> the log file there by dumping all the records we have in memory to that file,
> which does not include the aborted SSTable above.
> 6. Now the log files contain:
> {noformat}
> /tmp/d1/logfile.log:
> ADD:[/tmp/d1/AntiCompactionTest/AntiCompactionTest-e4fdddf0746e11ecb73ad5a997381615/AntiCompactionTest-AntiCompactionTest-mf-2-big,0,8][3268492367]
> ADD:[/tmp/d1/AntiCompactionTest/AntiCompactionTest-e4fdddf0746e11ecb73ad5a997381615/AntiCompactionTest-AntiCompactionTest-mf-3-big,0,8][2813724425]
> REMOVE:[/tmp/d0/AntiCompactionTest/AntiCompactionTest-e4fdddf0746e11ecb73ad5a997381615/AntiCompactionTest-AntiCompactionTest-mf-1-big,1642078019000,8][2401235379]
> COMMIT:[,0,0][2613697770]
> ** /tmp/d0/logfile.log:
> ADD:[/tmp/d1/AntiCompactionTest/AntiCompactionTest-e4fdddf0746e11ecb73ad5a997381615/AntiCompactionTest-AntiCompactionTest-mf-3-big,0,8][2813724425]
> REMOVE:[/tmp/d0/AntiCompactionTest/AntiCompactionTest-e4fdddf0746e11ecb73ad5a997381615/AntiCompactionTest-AntiCompactionTest-mf-1-big,1642078019000,8][2401235379]
> COMMIT:[,0,0][2613697770]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17273) Lazy transaction log replica creation allows incorrect replica content divergence during compaction
[
https://issues.apache.org/jira/browse/CASSANDRA-17273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-17273:
Authors: Marcus Eriksson (was: Caleb Rackliffe)
Test and Documentation Plan: new unit test, cci run
Status: Patch Available (was: Open)
[trunk|https://github.com/apache/cassandra/pull/1415]
[cci|https://app.circleci.com/pipelines/github/krummas/cassandra?branch=marcuse%2F17273-trunk]
[4.0|https://github.com/apache/cassandra/pull/1414]
[cci|https://app.circleci.com/pipelines/github/krummas/cassandra?branch=marcuse%2F17273-4.0]
[3.11|https://github.com/apache/cassandra/pull/1416]
[cci|https://app.circleci.com/pipelines/github/krummas/cassandra?branch=marcuse%2F17273-3.11]
[3.0|https://github.com/apache/cassandra/pull/1417]
[cci|https://app.circleci.com/pipelines/github/krummas/cassandra?branch=marcuse%2F17273]
> Lazy transaction log replica creation allows incorrect replica content
> divergence during compaction
> ---
>
> Key: CASSANDRA-17273
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17273
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair, Local/Compaction
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> Recently encountered this around compaction/anticompaction:
> {noformat}
> 2022-01-13 10:18:24,325 ERROR [main]
> org.apache.cassandra.db.lifecycle.LogTransaction - Unexpected disk state:
> failed to read transaction log
> [mf_txn_anticompactionafterrepair_2f826324-742c-11ec-b293-65cae21e111c.log in
> .../d1/data/.../files-c351f12917af3a5cbc57791cdf178a1f,
> .../d2/data/.../files-c351f12917af3a5cbc57791cdf178a1f]
> Files and contents follow:
> .../d1/data/.../files-c351f12917af3a5cbc57791cdf178a1f/mf_txn_anticompactionafterrepair_2f826324-742c-11ec-b293-65cae21e111c.log
>
> ADD:[.../d2/data/.../files-c351f12917af3a5cbc57791cdf178a1f/prod_p203-files-mf-350438-big,0,8][2380834168]
>
> REMOVE:[.../d2/data/.../files-c351f12917af3a5cbc57791cdf178a1f/prod_p203-files-mf-350435-big,1642049328006,8][2338829485]
>
> REMOVE:[.../d1/data/.../files-c351f12917af3a5cbc57791cdf178a1f/prod_p203-files-mf-350436-big,1642049366291,8][4248366924]
> COMMIT:[,0,0][2613697770]
> .../d2/data/.../files-c351f12917af3a5cbc57791cdf178a1f/mf_txn_anticompactionafterrepair_2f826324-742c-11ec-b293-65cae21e111c.log
>
> ADD:[.../d2/data/.../files-c351f12917af3a5cbc57791cdf178a1f/prod_p203-files-mf-350437-big,0,8][4051162457]
> ***Does not match
>
> in first replica file
>
> ADD:[.../d2/data/.../files-c351f12917af3a5cbc57791cdf178a1f/prod_p203-files-mf-350438-big,0,8][2380834168]
>
> REMOVE:[.../d2/data/.../files-c351f12917af3a5cbc57791cdf178a1f/prod_p203-files-mf-350435-big,1642049328006,8][2338829485]
>
> REMOVE:[.../d1/data/.../files-c351f12917af3a5cbc57791cdf178a1f/prod_p203-files-mf-350436-big,1642049366291,8][4248366924]
> COMMIT:[,0,0][2613697770]
> {noformat}
> We have two data directories and two transaction log files, but one is
> missing an ADD entry when the contents of the two log replicas should be
> identical. One scenario that can cause this is the following:
> 1. Start anticompaction on a single file, in directory {{/tmp/d0}}.
> 2. Call {{trackNew()}} with 2 new files, both in a single directory, but in
> directory {{/tmp/d1}}. This initializes the log file in {{/tmp/d1}}, but
> there is still no log file in {{/tmp/d0}}.
> 3. Anticompaction only writes to one of the files in {{/tmp/d1}} (say all
> other keys were outside the repaired range).
> 4. When anticompaction is done, the empty writer is aborted and we call
> {{untrackNew()}}, which removes the added file from the registered log
> “records" (BUT NOT FROM DISK in {{/tmp/d1}}).
> 5. The REMOVE record is added. This references {{/tmp/d0}}. We lazily create
> the log file there by dumping all the records we have in memory to that file,
> which does not include the aborted SSTable above.
> 6. Now the log files contain:
> {noformat}
> /tmp/d1/logfile.log:
> ADD:[/tmp/d1/AntiCompactionTest/AntiCompactionTest-e4fdddf0746e11ecb73ad5a997381615/AntiCompactionTest-AntiCompactionTest-mf-2-big,0,8][3268492367]
> ADD:[/tmp/d1/AntiCompactionTest/AntiCompactionTest-e4fdddf0746e11ecb73ad5a997381615/AntiCompactionTest-AntiCompactionTest-mf-3-big,0,8][2813724425]
> REMOVE:[/tmp/d0/AntiCompactionTest/AntiCompactionTest-e4fdddf0746e11ecb73ad5a997381615/AntiCompactionTest-AntiCompactionTest-mf-1-big,1642078019000,8][2401235379]
> COMMIT:[,0,0][2613697770]
> ** /tmp/d0/logfile.log:
>
[jira] [Commented] (CASSANDRA-17274) Broken link for contribute to cassandra on community page
[ https://issues.apache.org/jira/browse/CASSANDRA-17274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17479899#comment-17479899 ] Yash Ladha commented on CASSANDRA-17274: Thanks [~mck] for the quick review. > Broken link for contribute to cassandra on community page > - > > Key: CASSANDRA-17274 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17274 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Yash Ladha >Assignee: Yash Ladha >Priority: Normal > Labels: pull-request-available > Fix For: NA > > Attachments: image-2022-01-21-10-45-44-885.png > > > When visiting the community page of cassandra and going to `How to > contribute` session the link is not rendered properly. > !image-2022-01-21-10-45-44-885.png! > > We can see that _contribute to Cassandra_ is a simple text instead of a blank > link tag. > > Cause for the issue was in content we were using the URL macro but instead > have to use link macro. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17274) Broken link for contribute to cassandra on community page
[ https://issues.apache.org/jira/browse/CASSANDRA-17274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17479889#comment-17479889 ] Michael Semb Wever commented on CASSANDRA-17274: Live. > Broken link for contribute to cassandra on community page > - > > Key: CASSANDRA-17274 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17274 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Yash Ladha >Assignee: Yash Ladha >Priority: Normal > Labels: pull-request-available > Fix For: NA > > Attachments: image-2022-01-21-10-45-44-885.png > > > When visiting the community page of cassandra and going to `How to > contribute` session the link is not rendered properly. > !image-2022-01-21-10-45-44-885.png! > > We can see that _contribute to Cassandra_ is a simple text instead of a blank > link tag. > > Cause for the issue was in content we were using the URL macro but instead > have to use link macro. -- This message was sent by Atlassian Jira (v8.20.1#820001) - 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 (7213b05 -> 43bcee5)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to branch asf-site in repository https://gitbox.apache.org/repos/asf/cassandra-website.git. discard 7213b05 generate docs for 540e0817 add a0022eb Fix link syntax community component add 43bcee5 generate docs for a0022ebd 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 (7213b05) \ N -- N -- N refs/heads/asf-site (43bcee5) 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: content/_/community.html | 2 +- .../4.0.0/cassandra/tools/nodetool/bootstrap.html | 8 +- .../4.0.0/cassandra/tools/nodetool/nodetool.html | 10 +-- .../cassandra/tools/nodetool/repair_admin.html | 85 +-- .../4.0.1/cassandra/tools/nodetool/bootstrap.html | 8 +- .../4.0.1/cassandra/tools/nodetool/nodetool.html | 10 +-- .../cassandra/tools/nodetool/repair_admin.html | 85 +-- .../4.0/cassandra/tools/nodetool/bootstrap.html| 8 +- .../doc/4.0/cassandra/tools/nodetool/nodetool.html | 10 +-- .../4.0/cassandra/tools/nodetool/repair_admin.html | 85 +-- .../4.1/cassandra/tools/nodetool/bootstrap.html| 8 +- .../doc/4.1/cassandra/tools/nodetool/nodetool.html | 9 ++- .../4.1/cassandra/tools/nodetool/repair_admin.html | 90 ++--- .../latest/cassandra/tools/nodetool/bootstrap.html | 8 +- .../latest/cassandra/tools/nodetool/nodetool.html | 9 ++- .../cassandra/tools/nodetool/repair_admin.html | 90 ++--- .../stable/cassandra/tools/nodetool/bootstrap.html | 8 +- .../stable/cassandra/tools/nodetool/nodetool.html | 10 +-- .../cassandra/tools/nodetool/repair_admin.html | 85 +-- .../trunk/cassandra/tools/nodetool/bootstrap.html | 8 +- .../trunk/cassandra/tools/nodetool/nodetool.html | 9 ++- .../cassandra/tools/nodetool/repair_admin.html | 90 ++--- content/search-index.js| 2 +- .../source/modules/ROOT/pages/community.adoc | 2 +- site-ui/build/ui-bundle.zip| Bin 4740057 -> 4740057 bytes 25 files changed, 373 insertions(+), 366 deletions(-) - 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 (c5a1b27 -> 43bcee5)
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 c5a1b27 generate docs for 540e0817 add a0022eb Fix link syntax community component new 43bcee5 generate docs for a0022ebd 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 (c5a1b27) \ N -- N -- N refs/heads/asf-staging (43bcee5) 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/_/community.html | 2 +- content/search-index.js| 2 +- .../source/modules/ROOT/pages/community.adoc | 2 +- site-ui/build/ui-bundle.zip| Bin 4740057 -> 4740057 bytes 4 files changed, 3 insertions(+), 3 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17273) Lazy transaction log replica creation allows incorrect replica content divergence during compaction
[
https://issues.apache.org/jira/browse/CASSANDRA-17273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-17273:
Summary: Lazy transaction log replica creation allows incorrect replica
content divergence during compaction (was: Lazy transaction log replica
creation allows incorrect replica content divergence during anticompaction)
> Lazy transaction log replica creation allows incorrect replica content
> divergence during compaction
> ---
>
> Key: CASSANDRA-17273
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17273
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair, Local/Compaction
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> Recently encountered this around compaction/anticompaction:
> {noformat}
> 2022-01-13 10:18:24,325 ERROR [main]
> org.apache.cassandra.db.lifecycle.LogTransaction - Unexpected disk state:
> failed to read transaction log
> [mf_txn_anticompactionafterrepair_2f826324-742c-11ec-b293-65cae21e111c.log in
> .../d1/data/.../files-c351f12917af3a5cbc57791cdf178a1f,
> .../d2/data/.../files-c351f12917af3a5cbc57791cdf178a1f]
> Files and contents follow:
> .../d1/data/.../files-c351f12917af3a5cbc57791cdf178a1f/mf_txn_anticompactionafterrepair_2f826324-742c-11ec-b293-65cae21e111c.log
>
> ADD:[.../d2/data/.../files-c351f12917af3a5cbc57791cdf178a1f/prod_p203-files-mf-350438-big,0,8][2380834168]
>
> REMOVE:[.../d2/data/.../files-c351f12917af3a5cbc57791cdf178a1f/prod_p203-files-mf-350435-big,1642049328006,8][2338829485]
>
> REMOVE:[.../d1/data/.../files-c351f12917af3a5cbc57791cdf178a1f/prod_p203-files-mf-350436-big,1642049366291,8][4248366924]
> COMMIT:[,0,0][2613697770]
> .../d2/data/.../files-c351f12917af3a5cbc57791cdf178a1f/mf_txn_anticompactionafterrepair_2f826324-742c-11ec-b293-65cae21e111c.log
>
> ADD:[.../d2/data/.../files-c351f12917af3a5cbc57791cdf178a1f/prod_p203-files-mf-350437-big,0,8][4051162457]
> ***Does not match
>
> in first replica file
>
> ADD:[.../d2/data/.../files-c351f12917af3a5cbc57791cdf178a1f/prod_p203-files-mf-350438-big,0,8][2380834168]
>
> REMOVE:[.../d2/data/.../files-c351f12917af3a5cbc57791cdf178a1f/prod_p203-files-mf-350435-big,1642049328006,8][2338829485]
>
> REMOVE:[.../d1/data/.../files-c351f12917af3a5cbc57791cdf178a1f/prod_p203-files-mf-350436-big,1642049366291,8][4248366924]
> COMMIT:[,0,0][2613697770]
> {noformat}
> We have two data directories and two transaction log files, but one is
> missing an ADD entry when the contents of the two log replicas should be
> identical. One scenario that can cause this is the following:
> 1. Start anticompaction on a single file, in directory {{/tmp/d0}}.
> 2. Call {{trackNew()}} with 2 new files, both in a single directory, but in
> directory {{/tmp/d1}}. This initializes the log file in {{/tmp/d1}}, but
> there is still no log file in {{/tmp/d0}}.
> 3. Anticompaction only writes to one of the files in {{/tmp/d1}} (say all
> other keys were outside the repaired range).
> 4. When anticompaction is done, the empty writer is aborted and we call
> {{untrackNew()}}, which removes the added file from the registered log
> “records" (BUT NOT FROM DISK in {{/tmp/d1}}).
> 5. The REMOVE record is added. This references {{/tmp/d0}}. We lazily create
> the log file there by dumping all the records we have in memory to that file,
> which does not include the aborted SSTable above.
> 6. Now the log files contain:
> {noformat}
> /tmp/d1/logfile.log:
> ADD:[/tmp/d1/AntiCompactionTest/AntiCompactionTest-e4fdddf0746e11ecb73ad5a997381615/AntiCompactionTest-AntiCompactionTest-mf-2-big,0,8][3268492367]
> ADD:[/tmp/d1/AntiCompactionTest/AntiCompactionTest-e4fdddf0746e11ecb73ad5a997381615/AntiCompactionTest-AntiCompactionTest-mf-3-big,0,8][2813724425]
> REMOVE:[/tmp/d0/AntiCompactionTest/AntiCompactionTest-e4fdddf0746e11ecb73ad5a997381615/AntiCompactionTest-AntiCompactionTest-mf-1-big,1642078019000,8][2401235379]
> COMMIT:[,0,0][2613697770]
> ** /tmp/d0/logfile.log:
> ADD:[/tmp/d1/AntiCompactionTest/AntiCompactionTest-e4fdddf0746e11ecb73ad5a997381615/AntiCompactionTest-AntiCompactionTest-mf-3-big,0,8][2813724425]
> REMOVE:[/tmp/d0/AntiCompactionTest/AntiCompactionTest-e4fdddf0746e11ecb73ad5a997381615/AntiCompactionTest-AntiCompactionTest-mf-1-big,1642078019000,8][2401235379]
> COMMIT:[,0,0][2613697770]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail:
