2.0.1 is not functional in an application with a deny-all NetworkPolicy

[benlangfeld]

Expected behaviour

• The operator should delete NetworkPolicy objects it created and no longer intends to manage, so that upgrades of the operator and new Redis deployments work identically. RedisFailover should become unhealthy and make it obvious that the upgraded operator version is incompatible with the application.
• Optionally the operator should have test coverage for the scenario of being deployed in a namespace with a deny-all NetworkPolicy.
• Patch (or minor) releases should not break applications. Backwards incompatible changes should be released in new major versions to indicate additional caution to the user performing an upgrade.

Actual behaviour

When upgrading the operator for an existing RedisFailover

If the RedisFailover was previously created by the operator at version < 2.0.0, Redis will continue to work until the abandoned NetworkPolicy resources are manually deleted.

When deploying a new RedisFailover with the existing operator

Redis and Sentinel pods are unable to connect to each other and are never marked healthy.

Steps to reproduce the behaviour

• Deploy a NetworkPolicy as such to the namespace:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
spec:
  podSelector: {}
  policyTypes:
  - Ingress

• Deploy the operator at version 2.0.0.
• Create a RedisFailover and wait for it to become healthy.
• Deploy the operator at version 2.0.2.
• Observe the first RedisFailover continuing to work.
• Create a second RedisFailover. Observe that it does not work.