When running newrelic-logging with a persistent volume for storing the fluent-bit database file, an init container is deployed to delete old database files.
This init container can currently not be modified using the values.yaml file.
Being able to modify the definition of this init container would help to stay compliant with automatic security checks that might be performed on a Kubernetes cluster.
In our case, it would be very helpful if we could define the security context and the resources of the init container.
Any other required init container can be fully defined by the user, only the init container created when running in persistentVolume mode cannot be modified. A good solution in my opinion would be to allow the users to add any extra options under fluentBit.persistence.persistentVolume.extra.initContainer. This would allow to define extra options for the init container in the same way as for the persistent volume or the claim, all of which are specific to running in persistentVolume mode.
If you like this proposal I'm happy to contribute with a PR.
Acceptance Criteria
A user is able to add extra options to the definition of the init container that gets created when running in persistentVolume mode.
Describe Alternatives
An alternative could be to make the init container creation optional, so that users can define their own init container for deleting old database files.
Dependencies
None
Additional context
What else should we know about this story that might not fit into the other categories?
Estimates
S
For Maintainers Only or Hero Triaging this bug
Suggested Priority (P1,P2,P3,P4,P5):Suggested T-Shirt size (S, M, L, XL, Unknown):
workato-integration[bot]
commented
1 month ago
Description
When running
newrelic-loggingwith a persistent volume for storing the fluent-bit database file, an init container is deployed to delete old database files. This init container can currently not be modified using thevalues.yamlfile. Being able to modify the definition of this init container would help to stay compliant with automatic security checks that might be performed on a Kubernetes cluster. In our case, it would be very helpful if we could define the security context and the resources of the init container.Any other required init container can be fully defined by the user, only the init container created when running in persistentVolume mode cannot be modified. A good solution in my opinion would be to allow the users to add any extra options under
fluentBit.persistence.persistentVolume.extra.initContainer. This would allow to define extra options for the init container in the same way as for the persistent volume or the claim, all of which are specific to running in persistentVolume mode.If you like this proposal I'm happy to contribute with a PR.
Acceptance Criteria
A user is able to add extra options to the definition of the init container that gets created when running in persistentVolume mode.
Describe Alternatives
An alternative could be to make the init container creation optional, so that users can define their own init container for deleting old database files.
Dependencies
None
Additional context
What else should we know about this story that might not fit into the other categories?
Estimates
S
For Maintainers Only or Hero Triaging this bug
Suggested Priority (P1,P2,P3,P4,P5): Suggested T-Shirt size (S, M, L, XL, Unknown):