added value overrides for master broadcastaddress

[ssung-yugabyte]

FOR GKE MCS support.
GKE MCS will need the override of server_broadcast_addresses.

[tvesely]

+1. Just like the tservers, the masters need to be able to set the broadcast address. Small nit: this should be in the values file as well.

[tvesely]

This looks like a typo. This line should be removed.

[iSignal]

@tvesely : is Stanley around to update this PR? Otherwise, can you please send a new PR with the typo removed?

[bhavin192]

@tvesely you mean we should not remove the trailing slash, right?
Cause if we remove this line, a feature used by community users, might stop working.

charts/stable/yugabyte/values.yaml

Lines 293 to 302 in 8ae394e

	# For more https://docs.yugabyte.com/latest/reference/configuration/yugabyted/#environment-variables
	authCredentials:
	ysql:
	user: ""
	password: ""
	database: ""
	ycql:
	user: ""
	password: ""
	keyspace: ""

[bhavin192]

While I support this change, I'm trying to understand how do we plan to use it for GKE MCS.

When we set a value of master.serverBroadcastAddresses, the same value is passed to all the master pods created by the chart release. So, we will have to specifically set it for each release in each region/AZ to something like $(HOSTNAME).us-east-a.yb-masters.us-east-a-ns.svc.clusterset.local.

Other option is to keep the broadcast address unchanged and use masterAddresses like this: {<service name global across clusters - master-0>, <service name local to the cluster - master-0>}, {yb-master-1.us-east-a.yb-masters.ans.svc.clusterset.local,yb-master-1.yb-masters.ans.svc.cluster.local}....

This format makes it possible to tell TServer and Masters that each master has two ways to reach it. Need to test if this method works with GKE MCS though, that is something similar which we used for Istio multi-cluster setup. https://gist.github.com/bhavin192/ad3e0a7be5e23c00784fca864db9e1fc