Open MalteJoe opened 1 year ago
It seems like the vm.* settings are considered unsafe sysctl
s which is why they might not be available depending on the kubernetes setup. However, other Helm Charts like ElasticSearch seem to use an Init Container to set this value properly.
Hello!
We allow you to inject any init container you need, so you can already do it via initContainers in the group spec.
I do not see any need to allow more than this, as the above will solve all issues.
We will prepare a container definition to set all sysctl settings for ArangoDB, which you will be able to copy-paste into your ArangoDeployment.
Best, Adam.
Hi Adam,
thanks for the info. I couldn't find documentation of the custom initContainers anywhere, so I assume I just need to add them to the group spec and they will be executed before (or after?) the other initContainers (in case of single
)?
Hello!
Link to the API: https://github.com/arangodb/kube-arangodb/blob/master/pkg/apis/deployment/v2alpha1/server_group_spec.go#L143
They gonna be executed after ArangoDB initContainers, but before DB will start.
Hi!
Sorry, I didn't consider some go files in the sources as part of the API, shouldn't it be part of the documentation at https://www.arangodb.com/docs/stable/deployment-kubernetes-deployment-resource.html ?
As we're not talking about securityContext.sysctls
anymore, I would rewrite this issue to include an initContainer by the operator itself to set the sysctls like you have written in https://github.com/arangodb/kube-arangodb/issues/1303#issuecomment-1527809620 .
I will create another issue for the missing documentation of custom initContainers if that's fine with you.
When running
Single
instances via the operator, they produce a warning to modify the virtual memory property:It would be nice to configure the
securityContext.sysctls
properties in the deployment CR to let the pod have more memory handles as suggested by the warning or is there another way?