K8SPSMDB-791: fix loadBalancerSourceRanges

[pooknull]

https://jira.percona.com/browse/K8SPSMDB-791

DESCRIPTION

Problem:
When .spec.sharding.mongos.expose.loadBalancerSourceRanges is set when expose type is not LoadBalancer or when
.spec.replsets.expose.exposeType.loadBalancerSourceRanges is set, the cluster is stuck in an initializing state.

Cause:
The operator sets loadBalancerSourceRanges for headless service and doesn't check the expose type for mongos service

Solution:
The operator should set loadBalancerSourceRanges only if expose type is LoadBalancer.

CHECKLIST

Jira

• Is the Jira ticket created and referenced properly?
• Does the Jira ticket have the proper statuses for documentation (Needs Doc) and QA (Needs QA)?
• Does the Jira ticket link to the proper milestone (Fix Version field)?

Tests

• Is an E2E test/test case added for the new feature/change?
• Are unit tests added where appropriate?
• Are OpenShift compare files changed for E2E tests (compare/*-oc.yml)?

Config/Logging/Testability

• Are all needed new/changed options added to default YAML files?
• Are the manifests (crd/bundle) regenerated if needed?
• Did we add proper logging messages for operator actions?
• Did we ensure compatibility with the previous version or cluster upgrade process?
• Does the change support oldest and newest supported MongoDB version?
• Does the change support oldest and newest supported Kubernetes version?

[fbaligant]

Hi, I wanted to report success. We tried a custom Docker image built with this branch/PR and it does indeed fix our issue with the latest released version1.14.0 about using .spec.loadBalancerSourceRanges on a replSet.

[JNKPercona]

Test name	Status
arbiter	passed
cross-site-sharded	passed
data-at-rest-encryption	passed
data-sharded	passed
demand-backup	passed
demand-backup-eks-credentials	passed
demand-backup-physical	passed
demand-backup-physical-sharded	passed
demand-backup-sharded	passed
expose-sharded	passed
ignore-labels-annotations	passed
init-deploy	passed
limits	passed
liveness	passed
mongod-major-upgrade	passed
mongod-major-upgrade-sharded	passed
monitoring-2-0	passed
multi-cluster-service	failure
non-voting	passed
one-pod	passed
operator-self-healing-chaos	passed
pitr	passed
pitr-sharded	passed
recover-no-primary	passed
rs-shard-migration	passed
scaling	passed
scheduled-backup	passed
security-context	passed
self-healing-chaos	passed
service-per-pod	passed
serviceless-external-nodes	passed
smart-update	passed
storage	passed
upgrade	passed
upgrade-consistency	passed
upgrade-sharded	passed
users	passed
version-service	passed
We run 38 out of 38

commit: 2331e44
image: perconalab/percona-server-mongodb-operator:PR-1264-2331e444