What is the correct way to modify the pod spec for Connect

Description

The Connect helm chart has a few ways to modify the pod spec.

• There is a pod key:

pod:
  # -- A helper that defines the RSTUDIO_CONNECT_HASTE environment variable
  haste: true
  # -- An array of maps that is injected as-is into the "env:" component of the pod.container spec
  env: []
  # -- An array of maps that is injected as-is into the "volumes:" component of the pod spec
  volumes: []
  # -- An array of maps that is injected as-is into the "volumeMounts" component of the pod spec
  volumeMounts: []
  # -- Additional annotations to add to the rstudio-connect pods
  annotations: {}
  # -- Additional labels to add to the rstudio-connect pods
  labels: {}
  # -- An array of containers that will be run alongside the main pod
  sidecar: false
  # -- A map used verbatim as the pod's "affinity" definition
  affinity: {}
  # -- Values to set the `securityContext` for the connect pod
  securityContext: {}
  # -- The containerPort used by the main pod container
  port: 3939
  # -- The termination grace period seconds allowed for the pod before shutdown
  terminationGracePeriodSeconds: 120
  # -- Array of hostnames to supply to the main pod
  hostAliases: []

• And there are several top level keys:

# -- A map used verbatim as the pod's "affinity" definition
affinity: {}
# -- A map used verbatim as the pod's "nodeSelector" definition
nodeSelector: {}
# -- An array used verbatim as the pod's "topologySpreadConstraints" definition
topologySpreadConstraints: []
# -- An array used verbatim as the pod's "tolerations" definition
tolerations: []
# -- The pod's priorityClassName
priorityClassName: ""
# -- Pod disruption budget
podDisruptionBudget: {}

In the case of affinity vs. pod.affinity I don’t think the affinity key is doing anything. The template uses pod.affinity

https://github.com/rstudio/helm/blob/a50aa6e5a785182e10b1976e69ec1ea1f4603578/charts/rstudio-connect/templates/deployment.yaml#L44-L49

That specific case aside, in general it is confusing to have a pod key and then top level keys relaetd to the pod. Should/could everything be moved under pod that impacts the pod spec? How can/should we be consistent with Workbench and Connect (e.g. Workbench and Connect both use Values.affinity instead of Values.pod.affinity.

Start with charts/rstudio-connect/values.yaml and templates/deployment.yaml, then compare how Workbench and Connect use Values.affinity. Trace which pod-spec keys are consumed and identify the maintainer-approved organization; done when the configuration approach is decided and the ambiguity across the referenced charts is resolved.