If it's just logs then it makes more sense to follow standard approaches and ensure the containers send their logs to standard output to integrate with both the standard Container Runtime and Kubernetes logging architectures, or forward them with something like our existing Fluent Bit solution.
Adding a whole persistence approach just for the sake of getting to logs seems the wrong way to approach the problem. It introduces extra complexity to the overall solution as we have to manage an extra combination of supported platforms with or without persistence.
Now we have the logs in a PV but then we need to go get them out of it using another bespoke approach rather than just deploying one of the many logging solutions that will pick them up from the CRI. I imagine a customer would prefer logs all work with the same tooling and it would also prevent losing information due to log rotation.
Anuj Sahni, this change is staged for 2.2 https://github.com/couchbase-partners/helm-charts/commit/31aeb6699d0640aaf30896dcbfb8e4ede4fab21a
Before merging I wanted a clear understanding of the use-case. As I tested this I couldn't think of a path that needed to be persisted since sync gateway is completely stateless. What path is the customer looking to mount with persistent volumes?
Also does it have to be a Statefulset? Because a regular deployment type can still have persistent volumeMounts.