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.

Mostly the use-case is persistent volumes used to persist logs even after pod crashed. I am attaching current version of YAML file where you can see that customer is distributing pods across AZs and writing logs to PV:

apiVersion: apps/v1
kind: StatefulSet
metadata:
name: sync-gateway
namespace: cb
spec:
replicas: 3
serviceName: sync-gateway
selector:
matchLabels:
app: sync-gateway
template:
metadata:
labels:
app: sync-gateway
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:

• matchExpressions:
• key: topology.kubernetes.io/zone
  operator: In
  values:
• us-west-2a
• us-west-2b
• us-west-2c
  preferredDuringSchedulingIgnoredDuringExecution:
• weight: 5
  preference:
  matchExpressions:
• key: topology.kubernetes.io/hostname
  operator: Exists
  containers:
• name: sync-gateway
  image: couchbase/sync-gateway:2.8.0-enterprise
  args: [ "/sync-gateway-config/sgw-config.json" ]
  volumeMounts:
• name: sgw-config-volume
  mountPath: /sync-gateway-config
  readOnly: true
• name: sgw-pv-home
  mountPath: "/home"
  env:
• name: GOMAXPROCS
  value: "6"
  resources:
  requests:
  cpu: "6"
  memory: 50Gi
  #sync gateway exporter sidecar container- for metrics collection
• name: exporter
  image: couchbasesamples/sync-gateway-prometheus-exporter:latest
  args: ["--log.level=info"]
  ports:
• name: metrics
  containerPort: 9421
  resources:
  requests:
  cpu: 100m
  limits:
  cpu: 100m
  volumes:
• name: sgw-config-volume
  secret:
  secretName: sgw-config
  volumeClaimTemplates:
• metadata:
  name: sgw-pv-home
  spec:
  storageClassName: gp2-multi-data
  accessModes:
• ReadWriteOnce
  resources:
  requests:
  storage: 128Gi

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 I recommend Patrick's approach of streaming the logs.  But just to follow up here, the fix for this already exists in 2.2.1 chart 

# syncGateway configuration

syncGateway: 

    kind: Deployment # -- suppports (Deployment | Statefulset)