Initial work for clouds secrets and user-defined configmap #205
Conversation
Signed-off-by: Alex Lourie <[email protected]>
Fixes instaclustr#213 Fixes instaclustr#208 * Fixed some comments from PR review * Added Env to CRD to allow specifying environment for containers (exists in java version) * Added userConfigMap handling (instaclustr#213) * Restored PrivelegedSupported handling (instaclustr#208) * Backup secret volume allows providing GOOGLE_APPLICATION_CREDENTIALS in a secret * Cloud providers creds can be set using Env field in CRD Signed-off-by: Alex Lourie <[email protected]>
| @@ -165,7 +212,7 @@ func newSysctlLimitsContainer(cdc *cassandraoperatorv1alpha1.CassandraDataCenter | |||
| Image: cdc.Spec.CassandraImage, | |||
| ImagePullPolicy: cdc.Spec.ImagePullPolicy, | |||
| SecurityContext: &corev1.SecurityContext{ | |||
| Privileged: func() *bool { b := true; return &b }(), | |||
| Privileged: boolRef(cdc.Spec.PrivilegedSupported), | |||
There was a problem hiding this comment.
Is there a point in running the sysctl init container unprivileged? Shouldn't we completely drop the container if cdc.Spec.PrivilegedSupported == false?
There was a problem hiding this comment.
That's a very good question. In Java version we did this, so I assumed we might want to do this here too. The cluster seems to be working fine in my local testing, but I'm not sure it actually tests this flow properly.
There was a problem hiding this comment.
Here is what happens when the sysctl container runs unprivileged:
kubectl logs -f cassandra-test-dc-cassandra-0 -c sysctl-limits
+ sysctl -w vm.max_map_count=1048575
sysctl: setting key "vm.max_map_count": Read-only file system
+ true
The pod starts fine because we're doing || true, however it has no effect in this case as it cannot modify the setting on the host.
AFAICT we can drop this container when we can't run as privileged.
|
Superseded by #218 |
WIP, can be used to push backup secrets
Signed-off-by: Alex Lourie [email protected]