[timescale-multinode]feat: Add possibility to specify internal ip range

[griseau]

When running inside a kubernetes cluster, internal ip range could be different (for example could be 10.108.0.0/14 on GCP).

This PR allow you to set the internal IP range so that it's added inside the pg_hba.conf file during init.

Happy to take feedback :)

[CLAassistant]

All committers have signed the CLA.

[paulfantom]

Won't that be run on pod restarts too?

[griseau]

I did not think about this case, but you're right, coming from Kubernetes documentation :
"If the Pod restarts, or is restarted, all init containers must execute again." https://kubernetes.io/docs/concepts/workloads/pods/init-containers/

It's also the case for the command executed just above this one. How would you handle it ? Override the whole file instead of just appending this new line ?

[griseau]

Or I can do the same as it's done here

[griseau]

@paulfantom updated according to your comment :)

[paulfantom]

I was thinking about it a bit more and even with grep this may go sideways.

Let's assume someone is doing an upgrade of the helm chart and changed internalIpRange value. In such a scenario grep would fail and echo would be run again, which in turn would result in pg_hba.conf having old and new configuration options.

For me it look like we have 2 options:

1. Force full management of pg_hba.conf via ConfigMap. (I am not really a fan of this)
2. Create line markers and modify only options between line markers.

A bit more explanation on option 2. On the first run of the helm chart, we would add 3 lines, something like:

# START of the section managed by helm chart
host all all {{ .Values.internalIpRange }} trust
# END of the section managed by helm chart

Later in all subsequent runs, we can use grep to look for such a section and edit only the content of this section. This way even if internalIpRange changed on upgrade, helm chart would be able to update it accordingly.