chore: add support for hostNetwork in chart

[marckhair]

When running in eks, the deployment is failing because of the webhook with the following error:

Internal error occurred: failed calling webhook "mcluster.cnpg.io": failed to call webhook: Address is not allowed

The fix would be to set hostNetwork true but it is not configurable in the chart.

In addition to that, the dnsPolicy needs to be set to ClusterFirstWithHostNet to give hostNetwork pods access to internal DNS.

[mboutet]

So it seems like #185 also partially addresses the same issue with running cloudnative-pg on EKS with a custom CNI. However, that other PR misses the dnsPolicy field.

That other PR has been opened for months without any attention being given to it from the maintainers. For such a simple change that would help a lot of folks, I'd expect maintainers to accept and merge this PR without excessive delays. I totally understand the open source aspect of such a project, but again, those two PRs can easily be reviewed in a few minutes and would bring a lot of value to some people.

Thank you for building cloudnative-pg, it is an incredibly useful operator!

[marckhair]

@gbartolini @leonardoce @mnencia @phisco @sxd
We would greatly appreciate it if anyone could take a quick look at this PR

[itay-grudev]

@mboutet The problem is a lack of test suite, for both helm charts. We've made mistakes in the past, merging bugs. And the time requirements for merging with manual testing are increased.

I tried KUTTL a while ago, but mostly had issues with it. @phisco suggested I try Chainsaw instead, but before we have something like that merging will be slow.

I know it's 15 lines of code, but we've done damage with less.

[itay-grudev]

How is ClusterFirst better than Default with hostNetowork: false?

[itay-grudev]

Shouldn't it be kept to Default for backwards compatibility?

[mboutet]

I think we could simply keep it as an empty string which will result in the field not being rendered in the Deployment.

However, from https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/#pod-s-dns-policy, it seems like ClusterFirst is the actual default if the field is not specified in the PodSpec.

[marckhair]

Changed the default value of dnsPolicy to an empty string: 4bd27cd

[mboutet]

Suggested change

	dnsPolicy: "ClusterFirst"
	dnsPolicy: ""

[sxd]

As @itay-grudev properly mention this should be "Default" since that's the proper default an empty string is not on the list of possible options

[sxd]

On the other hands, these two values should be set only if there's any value set, having a default it's like mandatory, in platforms like OpenShift this hostNetwork value and dnsPolicy may not need to be set

[mboutet]

@sxd, the default is actually ClusterFirst as per https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/#pod-s-dns-policy.

"Default" is not the default DNS policy. If dnsPolicy is not explicitly specified, then "ClusterFirst" is used.

[sxd]

As I said, better to not set any default value, only set if it's set by the user

[marckhair]

Changed the default value of dnsPolicy to an empty string: 4bd27cd

[mboutet]

On the other hands, these two values should be set only if there's any value set, having a default it's like mandatory, in platforms like OpenShift this hostNetwork value and dnsPolicy may not need to be set

That's why I suggested we use "" for dnsPolicy in the values.yaml file. That way, the field won't get rendered in the deployment template.

hostNetwork is already false by default in the values.yaml, so it won't get rendered as it is wrapped in a conditional.

Edit: Wrote this before seeing #324 (comment).

[marckhair]

Tested default value | non default value combinations using helm template locally.

[itay-grudev]

Tested default value | non default value combinations using helm template locally.

The problem is not if they will render, but whether they will be accepted by K8s. I think a --dry-run is more appropriate if you don't want to install.

[marckhair]

Tested default value | non default value combinations using helm template locally.

The problem is not if they will render, but whether they will be accepted by K8s. I think a --dry-run is more appropriate if you don't want to install.

I passed the output of helm template to kubeconform in strict mode. Dry run is too complicated, it requires a cluster.