[jira] [Commented] (CASSANDRA-17148) Adapt track_warnings to Guardrails
[ https://issues.apache.org/jira/browse/CASSANDRA-17148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17487325#comment-17487325 ] David Capwell commented on CASSANDRA-17148: --- for the moment I think we should defer linking track_warnings with guardrails until the config conversation is finalized... personally I rather block track_warnings from the config layer and leave the feature JMX only for the moment... > 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-17148) Adapt track_warnings to Guardrails
[
https://issues.apache.org/jira/browse/CASSANDRA-17148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17485915#comment-17485915
]
Andres de la Peña commented on CASSANDRA-17148:
---
I have created CASSANDRA-17341 as a subtask for merging the configurations of
guardrails and track warnings. Both configs are mostly identical so any future
change in the structure of {{cassandra.yaml}} would be easier if we have both
sections together.
> 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-17148) Adapt track_warnings to Guardrails
[
https://issues.apache.org/jira/browse/CASSANDRA-17148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17481997#comment-17481997
]
Caleb Rackliffe commented on CASSANDRA-17148:
-
Just created CASSANDRA-17292 to host the discussion around the long term
structure of {{cassandra.yaml}}.
> 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-17148) Adapt track_warnings to Guardrails
[ https://issues.apache.org/jira/browse/CASSANDRA-17148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17481317#comment-17481317 ] Andres de la Peña commented on CASSANDRA-17148: --- So we would have a separate ticket to merge the configurations, and then we would work on a tighter integration beyond config in this ticket, right? Also, probably we should wait for CASSANDRA-15234, which seems about to be merged. > 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-17148) Adapt track_warnings to Guardrails
[ https://issues.apache.org/jira/browse/CASSANDRA-17148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17481271#comment-17481271 ] David Capwell commented on CASSANDRA-17148: --- I am cool moving configs under guardrails to be consistent, but can we make a subtask or new JIRA to track that work? Would be good for 1 commit = 1 jira IMO > 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-17148) Adapt track_warnings to Guardrails
[ https://issues.apache.org/jira/browse/CASSANDRA-17148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17479538#comment-17479538 ] Caleb Rackliffe commented on CASSANDRA-17148: - 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-17148) Adapt track_warnings to Guardrails
[
https://issues.apache.org/jira/browse/CASSANDRA-17148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17477856#comment-17477856
]
Andres de la Peña commented on CASSANDRA-17148:
---
As an initial step, the following patch moves the configuration and JMX methods
for track_warnings to guardrails:
||PR||CI||
|[trunk|https://github.com/apache/cassandra/pull/1406]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1245/workflows/2f2d6f91-3f19-4f2f-bd72-84b13adf11cf]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/1245/workflows/f19f1c10-3795-48c9-899f-9957ecb563e6]|
That way, the configuration would look like:
{code:java}
guardrails:
enabled: false
...
coordinator_read_size:
warn_threshold_in_kb: -1
abort_threshold_in_kb: -1
local_read_size:
warn_threshold_in_kb: -1
abort_threshold_in_kb: -1
row_index_size:
warn_threshold_in_kb: -1
abort_threshold_in_kb: -1
{code}
The patch only changes configuration and JMX methods, which is the minimum that
we would need before making a release so we don't need to deprecate any current
properties in the near future. The changes don't go beyond this, so nothing in
track_warnings is extending the {{Guardrail}} class and, conversely, nothing in
{{Guardrail}} and its extending classes is changed.
The next step would be getting to a tighter integration between both types of
threshold. I guess we should either extending the capabilities of the current
{{o.a.c.db.guardrails.Threshold}} class, or adding a new subclass of
{{Guardrail}} specifically for track_warnings. Some of the things to consider
are:
* track warnings throw dedicated, specific exceptions
({{{}ReadSizeAbortException{}}}), while all guardrails throw the same type of
exception.
* track_warnings update specific metrics, while guardrails don't track any
metrics. Metric recording can be easily added to guardrails, maybe with the
listeners that we discarded during CASSANDRA-17147.
* IIUC {{coordinator_read_size}} accumulates multiple checks before issuing a
warning, so we don't emit multiple warnings. The class {{Threshold.Counter}}
that we discarded during CASSANDRA-17147 was meant to do this, we can bring it
back to life.
* IIUC track warnings are applied to all queries, whereas guardrails are not
applied to super user nor internal queries. Those queries are ignored checking
the query's {{{}ClientState{}}}, which doesn't seem easy to get for
{{local_read_size}} and {{{}row_index_size{}}}.
I wonder if we should break this into two tickets, so we first set the common
the configuration that is visible to users and then we try to get a better
integration, or do it all in the same patch. [~dcapwell] what do you think?
> 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
