Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

K8SSAND-1036 ⁃ Is there any way of changing additional cassandra.yaml parameters ? #1166

Closed
mikekuzak opened this issue Nov 4, 2021 · 3 comments · Fixed by #1180
Closed
Assignees
Labels
question Further information is requested

Comments

@mikekuzak
Copy link

mikekuzak commented Nov 4, 2021

Hi All,

When looking though the Helm charts I couldn't find a way to change some additional settings like:

Especially:

  • batch_size_warn_threshold_in_kb
  • batch_size_fail_threshold_in_kb

But also these:

  • counter_write_request_timeout_in_ms
  • request_timeout_in_ms
  • read_request_timeout_in_ms
  • range_request_timeout_in_ms
  • write_request_timeout_in_ms

Thanks for any suggestion on how to adjust these.

┆Issue is synchronized with this Jira Task by Unito
┆Reviewer: Michael Burman
┆epic: Advanced Component Configuration
┆fixVersions: k8ssandra-1.4.0
┆friendlyId: K8SSAND-1036
┆priority: Medium

@mikekuzak mikekuzak added the question Further information is requested label Nov 4, 2021
@sync-by-unito sync-by-unito bot changed the title Is there any way of changing additional cassandra.yaml parameters ? K8SSAND-1036 ⁃ Is there any way of changing additional cassandra.yaml parameters ? Nov 4, 2021
@jdonenine
Copy link
Contributor

Hey @mikekuzak it would be possible to manipulate the CassandraDatacenter resources that get deployed after installation, but you would lose those settings when you upgrade the charts later, so admittedly it's not a perfect answer.

With 1.x we've taken a very opinionated view of directly representing the settings available within the charts. For the k8ssandra-operator we've kicked around a lot the question of if that's the best way to go or should we be able to just dump a blob of configuration in and pass it through. Much more flexible but it then lacks the saftey we might like.

We'd definitely be interested to hear what you think about that tradeoff -- is having access to any and every configuration option more important for you there?

@mikekuzak
Copy link
Author

mikekuzak commented Nov 4, 2021

Hi I think access to the cassandra.yaml properties should be provided as a customization form. I default values should still stay as they are, but there are centain scenarios where you want to customize them.

Example:
With 3 Env. (none k8s) we are doing weekly dump and restore from Prod to UAT|QA, having auto_snapshot on is a waist of diskspace and time in this case. The Truncate command creates snapshots . we are talking about 80G per node here.

I understand templating so many options via helm is a nightmare, but more secure that a blob option. The advantage also is you can override only specific values.

@jsanda
Copy link
Contributor

jsanda commented Nov 10, 2021

While we are still trying to figure out the best way(s) to expose and manage configs, I do think it is worthwhile to expose some of these settings in the short term. These and other settings have come up before (see #1023). If you want to use K8ssandra for production, it certainly makes sense to want a lot of these properties to be configurable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
3 participants