Changing spec.sentinel.serviceAnnotations does not update sentinel service's annotation

[hoyhbx]

Expected behaviour

I was trying to modify the spec.sentinel.serviceAnnotations field to add annotations to the service/rfs-redisfailover resource. When adding the key: value under spec.sentinel.serviceAnnotations, I was expecting to see the key: value annotation shows up in the service/rfs-redisfailover resource.

Actual behaviour

But I found that adding key value pairs under this field has no effect.
The field spec.sentinel.serviceAnnotations only has effect if it was specified when creating the cluster.

Steps to reproduce the behaviour

1. Deploy the redis-operator
2. Deploy a simple redis cluster using the following yaml file

apiVersion: databases.spotahome.com/v1
kind: RedisFailover
metadata:
  name: redisfailover
spec:
  redis:
    replicas: 2
  sentinel:
    replicas: 2

3. Add additional annotations under the field spec.sentinel.serviceAnnotations by applying the following yaml file:

apiVersion: databases.spotahome.com/v1
kind: RedisFailover
metadata:
  name: redisfailover
spec:
  redis:
    replicas: 2
  sentinel:
    replicas: 2
    serviceAnnotations:
      key: value

4. Observe that nothing changed in the service/rfs-redisfailover resource - the key: value annotation does not show up.

   `kubectl get service/rfs-redisfailover -o yaml`

   apiVersion: v1
   kind: Service
   metadata:
     creationTimestamp: "2022-04-29T03:51:32Z"
     labels:
       app.kubernetes.io/component: sentinel
       app.kubernetes.io/managed-by: redis-operator
       app.kubernetes.io/name: redisfailover
       app.kubernetes.io/part-of: redis-failover
       redisfailovers.databases.spotahome.com/name: redisfailover
     name: rfs-redisfailover
     namespace: acto-namespace
     ownerReferences:
     - apiVersion: databases.spotahome.com/v1
       blockOwnerDeletion: true
       controller: true
       kind: RedisFailover
       name: redisfailover
       uid: bd08ee05-f3c5-4e71-9a57-298e499ae2b3
     resourceVersion: "777"
     uid: ca96dbf4-5ef0-4265-acec-6d61616860ef
   spec:
     clusterIP: 10.96.113.217
     clusterIPs:
     - 10.96.113.217
     ipFamilies:
     - IPv4
     ipFamilyPolicy: SingleStack
     ports:
     - name: sentinel
       port: 26379
       protocol: TCP
       targetPort: 26379
     selector:
       app.kubernetes.io/component: sentinel
       app.kubernetes.io/name: redisfailover
       app.kubernetes.io/part-of: redis-failover
     sessionAffinity: None
     type: ClusterIP
   status:
     loadBalancer: {}

Environment

How are the pieces configured?

• Redis Operator version: quay.io/spotahome/redis-operator:v1.1.0
• Kubernetes version:

client Version: version.Info{Major:"1", Minor:"23", GitVersion:"v1.23.1", GitCommit:"86ec240af8cbd1b60bcc4c03c20da9b98005b92e", GitTreeState:"clean", BuildDate:"2021-12-16T11:41:01Z", GoVersion:"go1.17.5", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"20", GitVersion:"v1.20.15",
 GitCommit:"8f1e5bf0b9729a899b8df86249b56e2c74aebc55", GitTreeState:"clean", BuildDate:"2022-03-07T09:32:18Z", GoVersion:"go1.15.15", Compiler:"gc", Platform:"linux/amd64"}

• Kubernetes configuration used (eg: Is RBAC active?) yes

Logs

I didn't find any related lines regarding this bug in the operator log. The log is attached as a file below
operator.log

Possible root cause and fix

We suspect this behavior is caused by only creating but not updating the service resource. As shown at this line in the code, the service resource is only created if not exist, but never updated:

redis-operator/operator/redisfailover/service/client.go

Line 52 in 6e08a31

return r.K8SService.CreateIfNotExistsService(rf.Namespace, svc)

Potential fix is to change the CreateIfNotExistsService to CreateOrUpdateService so that the service resource is also updated. We are happy to provide a patch for this.

[github-actions]

This issue is stale because it has been open for 45 days with no activity.

[github-actions]

This issue was closed because it has been inactive for 14 days since being marked as stale.