Listeners timeout constantly updated

[Maysa de Macedo Souza]

It's possible that the Listener timeouts data was
included in the CRD status, even though there is
no annotation on the Service, probably the Listener
was not present on the CRD, but created and the
controller attempts to find it and includes the timeouts
value. The timeouts included on the CRD then differs
from the spec values causing the constant update
of the Listener.

     2021-05-28 14:37:45.579 24 INFO octavia.api.v2.controllers.listener [req-f8ed9d9f-8c6e-4f4f-a6e6-08999153b5d3 - 3583506d9c92457b9971b468f85fa720 - default default] Sending update Listener 443151ce-a7da-406b-90d1-37c7edd745e0 to provider ovn

     $ openstack loadbalancer list |grep cluster-baremetal-operator-service
openstack | aba05c65-2628-406b-b71f-b12d36a9215b | openshift-machine-api/cluster-baremetal-operator-service | 3583506d9c92457b9971b468f85fa720 | 172.30.244.252 | PENDING_UPDATE | ovn |

$ oc get klb cluster-baremetal-operator-service -n openshift-machine-api -o yaml
apiVersion: openstack.org/v1
kind: KuryrLoadBalancer
metadata:
  creationTimestamp: "2021-05-28T12:00:47Z"
  finalizers:
  - kuryr.openstack.org/kuryrloadbalancer-finalizers
  generation: 6577
  name: cluster-baremetal-operator-service
  namespace: openshift-machine-api
  resourceVersion: "113259"
  uid: bb7c616d-35a3-45e5-b053-88663a3b016d
spec:
  endpointSlices:
  - endpoints:
    - addresses:
      - 10.128.16.101
      conditions:
        ready: true
      targetRef:
        kind: Pod
        name: cluster-baremetal-operator-856b58cc6c-hvdqp
        namespace: openshift-machine-api
        resourceVersion: "30913"
        uid: 3a5818b1-8138-4216-96d6-4fd569bdaacf
    ports:
    - name: https
      port: 8443
      protocol: TCP
  ip: 172.30.244.252
  ports:
  - name: https
    port: 8443
    protocol: TCP
    targetPort: https
  project_id: 3583506d9c92457b9971b468f85fa720
  provider: ovn
  security_groups_ids:
  - 475e073a-c0bc-47a7-97f0-6955258b0bde
  subnet_id: b853adda-2f75-4cf8-99c3-21568a9b8d0c
  timeout_client_data: 0
  timeout_member_data: 0
  type: ClusterIP
status:
  listeners:
  - id: 443151ce-a7da-406b-90d1-37c7edd745e0
    loadbalancer_id: aba05c65-2628-406b-b71f-b12d36a9215b
    name: openshift-machine-api/cluster-baremetal-operator-service:TCP:8443
    port: 8443
    project_id: 3583506d9c92457b9971b468f85fa720
    protocol: TCP
    timeout_client_data: 50000
    timeout_member_data: 50000

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.opendev.org/c/openstack/kuryr-kubernetes/+/793768

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/kuryr-kubernetes/+/793768
Committed: https://opendev.org/openstack/kuryr-kubernetes/commit/b24380b4ae30f9a4659b1965839068cb623853cc
Submitter: "Zuul (22348)"
Branch: master

commit b24380b4ae30f9a4659b1965839068cb623853cc
Author: Maysa Macedo <email address hidden>
Date: Mon May 31 11:00:31 2021 +0000

    Fix Listener timeouts update

    It's possible that the Listener timeouts data was
    included in the CRD status, even though there is
    no annotation on the Service, probably the Listener
    was not present on the CRD, but created and the
    controller attempts to find it and includes the timeouts
    value. The timeouts included on the CRD then differs
    from the spec values causing the constant update
    of the Listener. This commit fixes the issue by ensuring
    the timeouts information is only included on the CRD
    when there was annoation(s) on the Service.

    Closes-bug: 1930220
    Change-Id: Iaaa6805287c175de618e0ec20099887f129e7536

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/kuryr-kubernetes 5.0.0.0rc1 release candidate.