Charts: [incubator/cassandra] Pods CrashLoopBackOff Using configmap

Created on 23 May 2019  路  6Comments  路  Source: helm/charts

Describe the bug
When adding the following config map:

configOverrides:
  cassandra.yaml: |
    auto_bootstrap: false
    cluster_name: staging
    endpoint_snitch: GossipingPropertyFileSnitch

Pods will not start and log the following output:
chown: changing ownership of '/etc/cassandra/cassandra.yaml': Read-only file system
Version of Helm and Kubernetes:
helm 2.11
kubernetes: 1.11.5

Which chart:
incubator/cassandra

What happened:
Added config map which caused pods to crash on start

What you expected to happen:
Config map to be added and successfully start the pod.

How to reproduce it (as minimally and precisely as possible):
Add something similar to the configOverrides:

configOverrides:
  cassandra.yaml: |
    auto_bootstrap: false
    cluster_name: staging
    endpoint_snitch: GossipingPropertyFileSnitch

Anything else we need to know:

lifecyclstale

Most helpful comment

Sorry to re-open this issue, but it seems valid. I'm having the same problem and not sure what's the solution for it?

All 6 comments

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Any further update will cause the issue/pull request to no longer be considered stale. Thank you for your contributions.

This issue is being automatically closed due to inactivity.

Sorry to re-open this issue, but it seems valid. I'm having the same problem and not sure what's the solution for it?

I believe this is happening because the chart is trying to mount the overriden cassandra.yaml as a config map into the pod's filesystem. Then as Cassandra tries to start it detects that the file has read-only permissions (kubernetes enforces that for config maps after v1.9.4 I think) and stops.
I don't have a solution unfortunately.

This bug is affecting me as well, and I would like to suggest it be reopened. @hampos is correct, as far as I can tell. However, there are other issues, which I'd like to bring up.

  1. Every config file must be provided if using configOverrides. This is because the entire directory is deleted if you mount configmaps as files in that directory.
  2. Certain config files cannot be provided because of their names containing an underscore. For example, commitlog_archiving.properties will cause an error at deploy-time.

I think a better solution is to mount the configmaps as a volume in some scratch directory and then use an init container to copy the ones that are present over to the regular read/write cassandra config directory, with a transparent renaming scheme to deal with the underscores. This would require changes to the chart's templates and cannot be achieved using the chart as-is.

I could take a crack at doing this and make a pull request, provided this sketch of a design is approved.

Please note it is still very painful to override just one or two parameters of cassandra.yaml...
As mentioned by @Fizzixnerd we have to copy/paste ALL the config files already present in /etc/cassandra/ into configOverrides to build the full configmap, and allows cassandra to start.

It would be good to only replace the overridden files, and keep the other ones.
Even better, only replace the overridden properties values, at least for properties files..

Was this page helpful?
0 / 5 - 0 ratings