@thecodeassassin-mycu Below is the overrides file snippet. I’ve also added comments to hopefully make the YAML more meaningful and hopefully answer your question on how the multiple helm deployments over multiple clusters combine into a single universe.
# To signify if the deployment spans multiple zones.
isMultiAz: True
# Set if you would like to deploy this deployments pods specifically on nodes in a particular zone
# (affinitized by using node label: failure-domain.beta.kubernetes.io/zone)
AZ: "<zone>"
# Since in a single cluster spanning multiple zones, the PVC cannot be controlled by the helm deployment.
# So to pin the pods to the required zone, we need to ensure that there is a storage class created just for that zone.
storage:
master:
storageClass: "standard-<zone>"
tserver:
storageClass: "standard-<zone>"
# The master addresses is how the YugaByteDB finds the rest of the members of the requested universe which may have been deployed
# in different helm deployments (and by extension, in different zones/clusters)
masterAddresses: "yb-master-0.yb-masters.yb-demo-<zone1>.svc.cluster.local:7100, yb-master-0.yb-masters.yb-demo-<zone2>.svc.cluster.local:7100, yb-master-0.yb-masters.yb-demo-<zone3>.svc.cluster.local:7100"
# The number of pods corresponding to each service that you would like to bring up in the particular helm deployment.
# The totalMasters specifies the total number of masters in the universe (so essentially the required replacement factor)
# The number of masters also specifies the min number of replicas in that zone, so always masters <= tservers.
replicas:
master: 1
tserver: 1
totalMasters: 3
# These are the flags that specifies to the master the placement information, and ensures that data is replicated according to
# the user's request.
gflags:
master:
placement_cloud: "kubernetes"
placement_region: "<region>"
placement_zone: "<zone>"
tserver:
placement_cloud: "kubernetes"
placement_region: "<region>"
placement_zone: "<zone>"