[
https://issues.apache.org/jira/browse/CASSANDRA-17147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17451796#comment-17451796
]
Andres de la Peña commented on CASSANDRA-17147:
-----------------------------------------------
bq. Once you merge into the PR can view whole patch together; think we are
close!
I have added the nested config to the PR, rebased and run CI for
[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1184/workflows/2c0a4c55-f740-41db-8356-9b222bb38815]
and
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/1184/workflows/ecab9e8a-f7a5-430b-bf13-884a7c54852f].
bq. though would drop "_values" in table_properties
Makes sense, done.
bq. then CASSANDRA-17166 can fix your concerns for getter/setters; I know that
the yaml will be interesting with your patch, but prefer CASSANDRA-17166 fixes
those issues rather than you dealing with it in this patch (your getter/setters
are currently exposed as camel case in yaml; found the same bug in
TrackWarnings).
It would be great if we were able to use Jackson annotations and have private
attributes. I guess that those annotations would also make things easier for
the settings virtual table. In the meantime, I guess we could leave the camel
case getters/setters and public snake case attributes and wait for a better
solution in CASSANDRA-17166. We could also use snake casing in the
getters/setters, but that would mean extending the snake casing workaround up
to the getters in the {{Threshold.Config}}/{{Values.Config}} interfaces, which
is not ideal IMO.
> Guardrails prototype
> --------------------
>
> Key: CASSANDRA-17147
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17147
> 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
>
> Time Spent: 14h 50m
> Remaining Estimate: 0h
>
> The purpose of this ticket is creating an initial implementation of the
> guardrails framework, as well as adding a few simple guardrails using this
> framework.
> To keep things easy, this initial implementation would only support
> guardrails that are triggered on the coordinator, and they would be
> dynamically updatable only through JMX.
> Once we have this initial framework ready in a feature branch we can have
> multiple tickets addressing all the things that would have been left out of
> the scope of this ticket, such as:
> * Dynamic updates through virtual tables
> * Being able to notify about guardrails triggered on replicas
> * Using custom exceptions other than {{InvalidRequestException}}.
> * Porting existing limits to use the new guardrails framework
> * Adding new guardrails beyond the initial ones
> The reason for having this simpler prototype is that it will give us a common
> ground to parallelize work on the parts mentioned above.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
