Sidecar approach for logs (via storage/PVC in k8s)

[gheorghitamutu]

Hello,
I'm playing a bit with Dragonfly operator and I'm trying to get a sidecar for logging.
While there are some options, CR supports additionalContainers, additionalVolumes, I couldn't find anything for volumeMounts or additionalVolumeMounts. Without this, I cannot do patterns like: file-based log sidecars, config/data injection into the main container or shared scratch/work directories between main and sidecar.
The plain Dragonfly Helm chart already supports extraVolumes and extraVolumeMounts for the main container - the operator CRD is missing the equivalent capability.

This would align operator functionality with the chart but I'm wondering if I'm missing something. Of course, there are some options to collect these logs via stdout but it's not something I'd like to do in this situation.

Thank you!

[cookesan]

For the sidecar itself, yes: the operator CRD exposes additionalContainers as full Kubernetes container specs, so that sidecar can define its own volumeMounts, and additionalVolumes can add the pod volume.

What I do not see in the operator API is a generic additionalVolumeMounts hook for the operator-managed Dragonfly container. The generated StatefulSet adds mounts for built-in features such as ACL/TLS/tiering/snapshotting, then merges additional containers and volumes. So a shared volume mounted only into the sidecar is straightforward; mounting an arbitrary log volume into the main Dragonfly container is not supported by a first-class field.

For log collection, I would prefer stdout/stderr collection unless the operator adds a main-container volumeMount hook.

[gheorghitamutu]

While stdout is an option... in environments like GCP the logs would reach more targets that I would like to.

An example would be a datasource for Grafana, like Loki.
So if I want to have the stdout to Loki only, I would have to do some manual intervention in GCP to actually somehow drop the logs before/after reaching the target/sink.