[
https://issues.apache.org/jira/browse/CASSANDRA-21093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18050200#comment-18050200
]
Stefan Miklosovic edited comment on CASSANDRA-21093 at 1/6/26 6:29 PM:
-----------------------------------------------------------------------
hi [~nickbar01234], yes, configurability is something we would need to add to
this. I was making existing startup checks configurable. It did not cross my
mind that somebody would ever want their custom checks but here we are ...
The current solution when it comes to configuration is based on
{{Map<StartupCheckType, Map<String, Object>>}}, the advantage of having an enum
as a key is that snakeyaml will fail to parse cassandra.yml if there is invalid
name of the startup check as it maps to StartupCheck enum and we have this
validaton virtually for free.
If you want to expand that then key would need to start to be String, and then
we would need to sanitize the names and fail if something invalid is there.
This is a little bit more involved patch than it seems. Feel free to implement
this and we will help. If you are not either capable or not willing to do that,
that is also fine, please just let us know that you are not working on this.
was (Author: smiklosovic):
hi [~nickbar01234], yes, configurability is something we would need to add to
this. I was making existing startup checks configurable. It did not cross my
mind that somebody would ever want their custom checks but here we are ...
The current solution when it comes to configuration is based on
{{Map<StartupCheckType, Map<String, String>>}}, the advantage of having an enum
as a key is that snakeyaml will fail to parse cassandra.yml if there is invalid
name of the startup check as it maps to StartupCheck enum and we have this
validaton virtually for free.
If you want to expand that then key would need to start to be String, and then
we would need to sanitize the names and fail if something invalid is there.
This is a little bit more involved patch than it seems. Feel free to implement
this and we will help. If you are not either capable or not willing to do that,
that is also fine, please just let us know that you are not working on this.
> Custom startup checks plugin
> ----------------------------
>
> Key: CASSANDRA-21093
> URL: https://issues.apache.org/jira/browse/CASSANDRA-21093
> Project: Apache Cassandra
> Issue Type: Improvement
> Reporter: Nick Doan
> Assignee: Nick Doan
> Priority: Normal
>
> {{Currently, the list of available startup checks is fixed for a given
> distribution. Users can optionally override whether a check type is executed
> using {_}startup_checks{_}.}}
>
> In some deployment environments, users may want to have additional checks in
> place, but currently, this would require running these checks separately
> before launching the Cassandra daemon. Can we potentially add support for
> {_}custom_startup_checks{_}, which takes a list of classes to be dynamically
> loaded at runtime from classpath? Alternatively, if custom deployments wraps
> CassandraDaemon, we can also consider exposing startup checks as a public
> singleton so that the wrapper can register additional startup checks.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
