[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=17528334#comment-17528334
]
Savni Nagarkar edited comment on CASSANDRA-17212 at 4/26/22 5:52 PM:
-
||min_rf||ci||
|[GitHub|https://github.com/apache/cassandra/pull/1583/]|[j8|https://app.circleci.com/pipelines/github/thingtwin1/cassandra/44/workflows/a6691dc4-6512-4c66-b175-7e275e2c9343]
[j11|https://app.circleci.com/pipelines/github/thingtwin1/cassandra/44/workflows/21882e40-7a6c-478c-aa0e-371b9a0aaa05]|
was (Author: JIRAUSER284678):
||min_rf||ci||
|[GitHub|https://github.com/apache/cassandra/pull/1583/]|[j8|https://app.circleci.com/pipelines/github/thingtwin1/cassandra/44/workflows/a6691dc4-6512-4c66-b175-7e275e2c9343]
[j11\|https://app.circleci.com/pipelines/github/thingtwin1/cassandra/44/workflows/21882e40-7a6c-478c-aa0e-371b9a0aaa05
]|
> 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
>Assignee: Savni Nagarkar
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> 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.7#820007)
-
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=17528334#comment-17528334
]
Savni Nagarkar edited comment on CASSANDRA-17212 at 4/26/22 5:51 PM:
-
||min_rf||ci||
|[GitHub|https://github.com/apache/cassandra/pull/1583/]|[j8|https://app.circleci.com/pipelines/github/thingtwin1/cassandra/44/workflows/a6691dc4-6512-4c66-b175-7e275e2c9343]
[j11\|https://app.circleci.com/pipelines/github/thingtwin1/cassandra/44/workflows/21882e40-7a6c-478c-aa0e-371b9a0aaa05
]|
was (Author: JIRAUSER284678):
||min_rf||ci||
|[GitHub\|https://github.com/apache/cassandra/pull/1583/]|[j8
|https://app.circleci.com/pipelines/github/thingtwin1/cassandra/44/workflows/a6691dc4-6512-4c66-b175-7e275e2c9343][j11\|[https://app.circleci.com/pipelines/github/thingtwin1/cassandra/44/workflows/21882e40-7a6c-478c-aa0e-371b9a0aaa05]]|
> 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
>Assignee: Savni Nagarkar
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> 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.7#820007)
-
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=17480375#comment-17480375
]
Benedict Elliott Smith edited comment on CASSANDRA-17212 at 1/22/22, 9:20 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.
In my experience this is a near-impossible task to do consistently with an
intuitive structure, as nobody really agrees what features should be called,
let alone their hierarchy.
For instance, once you have a {{query}} heading, should that then include
coordinator level configurations? timeouts? concurrency? CQL configurations?
caches? Logically it _could_ include half of the settings.
Many things also don't neatly fall under any feature, so we will fabricate
features for them: non-query timeouts cannot be grouped under {{query}}, so now
we probably _won't_ group query timeouts under {{query}} either, else it will
be inconsistent. But now both are inconsistent, there's no rules underpinning
it anymore.
This kind of grouping can also be more volatile - once a new setting (and
suitable grouping) is introduced, it more readily affects the decisions for the
existing hierarchy. This means this kind of layout probably needs a lot of
upfront work to produce a coherent grouping for the whole config file, to
demonstrate that it can be done in a manner everyone agrees on, and to avoid
lots of churn.
I think when I tried to produce groupings, your approach was what I tried
initially before deciding this approach was cleaner. Plus it has the added
benefit that a user that _doesn't_ know the config options (i.e. most users),
when encountering instability, will have good discoverability of dials that can
be modified to improve cluster health. I think this is a very underrated
benefit, as most users cannot afford teams of developers that are intimately
familiar with the codebase.
TL;DR: it's messy, arbitrary and inconsistent. Some upfront work needs to be
done to work out what it would like in totality.
was (Author: benedict):
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.
In my experience this is a near-impossible task to do consistently with an
intuitive structure, as nobody really agrees what features should be called,
let alone their hierarchy.
For instance, once you have a {{query}} heading, should that then include
coordinator level configurations? timeouts? concurrency? CQL configurations?
caches? Logically it _could_ include half of the settings.
Many things also don't neatly fall under any feature, so we will fabricate
features for them: non-query timeouts cannot be grouped under {{query}}, so now
we probably _won't_ group query timeouts under {{query}} either, else it will
be inconsistent. But now both are inconsistent, there's no rules underpinning
it anymore.
This kind of grouping can also be more volatile - once a new setting (and
suitable grouping) is introduced, it more readily affects the decisions for the
existing hierarchy. This means this kind of layout probably needs a lot of
upfront work to produce a coherent grouping for the whole config file, to
demonstrate that it can be done in a manner everyone agrees on, and to avoid
lots of churn.
I think when I tried to produce groupings, your approach was what I tried
initially before deciding this approach was cleaner. Plus it has the added
benefit that a user that _doesn't_ know the config options (i.e. most users),
when encountering instability, will have good discoverability of dials that can
be modified to improve cluster health. I think this is a very underrated
benefit, as most users cannot afford teams of developers that are intimately
familiar with the codebase.
> 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)
[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=17480375#comment-17480375
]
Benedict Elliott Smith edited comment on CASSANDRA-17212 at 1/22/22, 9:19 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.
In my experience this is a near-impossible task to do consistently with an
intuitive structure, as nobody really agrees what features should be called,
let alone their hierarchy.
For instance, once you have a {{query}} heading, should that then include
coordinator level configurations? timeouts? concurrency? CQL configurations?
caches? Logically it _could_ include half of the settings.
Many things also don't neatly fall under any feature, so we will fabricate
features for them: non-query timeouts cannot be grouped under {{query}}, so now
we probably _won't_ group query timeouts under {{query}} either, else it will
be inconsistent. But now both are inconsistent, there's no rules underpinning
it anymore.
This kind of grouping can also be more volatile - once a new setting (and
suitable grouping) is introduced, it more readily affects the decisions for the
existing hierarchy. This means this kind of layout probably needs a lot of
upfront work to produce a coherent grouping for the whole config file, to
demonstrate that it can be done in a manner everyone agrees on, and to avoid
lots of churn.
I think when I tried to produce groupings, your approach was what I tried
initially before deciding this approach was cleaner. Plus it has the added
benefit that a user that _doesn't_ know the config options (i.e. most users),
when encountering instability, will have good discoverability of dials that can
be modified to improve cluster health. I think this is a very underrated
benefit, as most users cannot afford teams of developers that are intimately
familiar with the codebase.
was (Author: benedict):
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.
In my experience this is not only a near-impossible task, but leads to
inconsistency (in both leaf-node naming and in grouping) and a non-intuitive
structure, as nobody really agrees what any features should be called, and
certainly not what they should be grouped under. Names and groupings are
entirely arbitrary, and something that is natural to some will be unnatural to
another.
For instance, once you have a {{query}} heading, should that then include
coordinator level configurations? timeouts? concurrency? CQL configurations?
Logically it could include half of the settings. So it becomes arbitrary, and
importantly much more volatile - once a new setting and suitable grouping is
introduced for a new property, either the consistency is harmed or settings
need to be moved to another group, much like they would with an internal API.
It would also likely need to be a much bigger bang piece of work, and would
likely necessitate much more disparate documentation, as the _effect_ of each
setting likely needs to be described repetitiously. At the very least, anybody
who wants this kind of layout needs to try producing such a coherent grouping
for the whole config file, to demonstrate that it can be done, and to avoid
lots of churn.
TL;DR: it's messy, arbitrary and inconsistent. But if that's what everyone
wants, some work needs to be done upfront to prove it can be done cleanly IMO.
> 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=17480375#comment-17480375
]
Benedict Elliott Smith edited comment on CASSANDRA-17212 at 1/22/22, 8:51 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.
In my experience this is not only a near-impossible task, but leads to
inconsistency (in both leaf-node naming and in grouping) and a non-intuitive
structure, as nobody really agrees what any features should be called, and
certainly not what they should be grouped under. Names and groupings are
entirely arbitrary, and something that is natural to some will be unnatural to
another.
For instance, once you have a {{query}} heading, should that then include
coordinator level configurations? timeouts? concurrency? CQL configurations?
Logically it could include half of the settings. So it becomes arbitrary, and
importantly much more volatile - once a new setting and suitable grouping is
introduced for a new property, either the consistency is harmed or settings
need to be moved to another group, much like they would with an internal API.
It would also likely need to be a much bigger bang piece of work, and would
likely necessitate much more disparate documentation, as the _effect_ of each
setting likely needs to be described repetitiously. At the very least, anybody
who wants this kind of layout needs to try producing such a coherent grouping
for the whole config file, to demonstrate that it can be done, and to avoid
lots of churn.
TL;DR: it's messy, arbitrary and inconsistent. But if that's what everyone
wants, some work needs to be done upfront to prove it can be done cleanly IMO.
was (Author: benedict):
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.
In my experience this is not only an impossible task, but leads to
inconsistency and a non-intuitive structure, as nobody really agrees what any
features should be called, and certainly not what they should be grouped under.
Names and groupings are entirely arbitrary, and something that is natural to
some will be unnatural to another.
For instance, once you have a {{query}} heading, should that then include
coordinator level configurations? timeouts? concurrency? CQL configurations?
Logically it could include half of the settings. So it becomes arbitrary, and
importantly much more volatile - once a new setting and suitable grouping is
introduced for a new property, either the consistency is harmed or settings
need to be moved to another group, much like they would with an internal API.
It would also likely need to be a much bigger bang piece of work, and would
likely necessitate much more disparate documentation, as the _effect_ of each
setting likely needs to be described repetitiously. At the very least, anybody
who wants this kind of layout needs to try producing such a coherent grouping
for the whole config file, to demonstrate that it can be done, and to avoid
lots of churn.
TL;DR: it's messy, arbitrary and inconsistent. But if that's what everyone
wants, some work needs to be done upfront to prove it can be done cleanly IMO.
> 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=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] [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] [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] [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=17478015#comment-17478015
]
Benedict Elliott Smith edited comment on CASSANDRA-17212 at 1/18/22, 4:26 PM:
--
The problem with your proposed layout is that you seem to fan out on the
involved part of Cassandra rather than the category of effect, so that at the
very least there is high fan out - but, also for consistency you would
naturally expect concurrency limits to be nested under read, write, etc,
leading to a config that look like this:
{code}
limits:
read:
concurrency: 32
write:
concurrency:32
{code}
I think consistency is important in a config file, as is maximally grouping
concepts. But also we want the config file to be naturally discoverable, and
self-documenting. For instance, I may know I have a warning I want to modify,
but do I know in advance if it is called {{corrupt_value_size}}? Probably not.
So I can find it more easily by the alternative approach. Similarly,
documentation can span an entire category of limit, with hopefully most
terminal parameter names being adequately descriptive of the part of system we
are addressing, to obviate further documentation (or else, it can be renamed,
or a minimal single line may suffice)
I'm not entirely sold on the idea of globally enabling/disabling limits either,
but perhaps it might make sense to permit switching on/off categories of limit
(warn, error, info etc)?
was (Author: benedict):
The problem with your proposed layout is that you seem to fan out on the
affected system rather than the systemic effect, so that at the very least
there is high fan out, but also for consistency you would expect concurrency
limits to be nested under read, write, etc, leading to a config that look like
this:
{code}
limits:
read:
concurrency: 32
write:
concurrency:32
{code}
I think consistency is important in a config file, as is maximally grouping
concepts. But also we want the config file to be naturally discoverable, and
self-documenting. For instance, I may know I have a warning I want to modify,
but do I know in advance if it is called {{corrupt_value_size}}? Probably not.
So I can find it more easily by the alternative approach. Similarly,
documentation can span an entire systemic impact, with hopefully most terminal
parameter names being adequately descriptive to obviate further documentation
(or else, it can be renamed, or a minimal single line may suffice)
I'm not entirely sold on the idea of globally enabling/disabling limits either,
but perhaps it might make sense to permit switching on/off categories of limit
(warn, error, info etc)?
> 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=17477826#comment-17477826
]
Benedict Elliott Smith edited comment on CASSANDRA-17212 at 1/18/22, 12:51 PM:
---
Right, I'm saying we should not distinguish kinds of limits in this way. Why is
one kind of limit a safety limit or guardrail and another is not? We need to
start having a holistic view of configuration, not a piecemeal one based on
features we are developing, if we hope to have user friendly config.
For comparison, see [my
proposal|https://github.com/belliottsmith/cassandra/blob/5f80d1c0d38873b7a27dc137656d8b81f8e6bbd7/conf/cassandra_nocomment.yaml]
for a configuration file layout with various limits grouped together. If we
are refactoring the config file, we should be doing so with a wider long term
view, in my opinion.
was (Author: benedict):
Right, I'm saying we should not distinguish kinds of limits in this way. Why is
one kind of limit a safety limit or guardrail and another is not? We need to
start having a holistic view of configuration, not a piecemeal one based on
features we are developing, if we hope to have user friendly config.
> 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=17460356#comment-17460356
]
Caleb Rackliffe edited comment on CASSANDRA-17212 at 12/16/21, 1:54 AM:
Just an aside, there's a mechanism in CASSANDRA-15234 to automatically
translate old YAML option names to new ones, the {{@Replaces}} annotation. I'm
not sure if it works translating from non-nested to nested though...
was (Author: maedhroz):
Just an aside, there's [a
mechanism|https://github.com/ekaterinadimitrova2/cassandra/pull/191/files?authenticity_token=sJmDGDBnNmsM1hvUl53SB%2BLF1Wu3figjB1J36vgRc3daSXvF%2FLdEBfHFVAKs%2BnMIS60xF178btDObW4YmbzEXA%3D%3D%5B%5D=.java%5B%5D=.rst%5B%5D=.sh%5B%5D=.spec%5B%5D=.txt%5B%5D=.yaml%5B%5D=.yml=true#diff-c0183ea76992a610729dcd0482fc92842d9e19e1d8bc1692944bcab153ecc134R34]
in CASSANDRA-15234 to automatically translate old YAML option names to new
ones, the {{@Replaces}} annotation. I'm not sure if it works translating from
non-nested to nested though...
> 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
