Uploaded image for project: 'Network Observability'
  1. Network Observability
  2. NETOBSERV-1293

flowcollector status oscillates between DeploymentInProgress and Ready

    XMLWordPrintable

Details

    • False
    • None
    • False
    • Hide
      Previously, the FlowCollector status could sometimes oscillate between "DeploymentInProgress" and "Ready" states during reconciliation.
      Now, actual readiness is correctly detected, and the status only becomes "Ready" when all underlying components are fully ready.


      (old - RN 1.4: known issue)
      Currently, when the processor metric server is configured to use a provided certificate (`processor.metrics.server.tls.type` is `PROVIDED`), the operator enters in an unsteady state that might affect its performances and resource consumption. It is recommended to not use a provided certificate until this issue is resolved, and prefer using an auto-generated certificate (set `processor.metrics.server.tls.type` to `AUTO`).
      Show
      Previously, the FlowCollector status could sometimes oscillate between "DeploymentInProgress" and "Ready" states during reconciliation. Now, actual readiness is correctly detected, and the status only becomes "Ready" when all underlying components are fully ready. (old - RN 1.4: known issue) Currently, when the processor metric server is configured to use a provided certificate (`processor.metrics.server.tls.type` is `PROVIDED`), the operator enters in an unsteady state that might affect its performances and resource consumption. It is recommended to not use a provided certificate until this issue is resolved, and prefer using an auto-generated certificate (set `processor.metrics.server.tls.type` to `AUTO`).
    • NetObserv - Sprint 242, NetObserv - Sprint 243

    Description

      This was found while testing NETOBSERV-1087 when transitioned from DISABLED to PROVIDED mode and new FLP containers are being created, flowcollectors status oscillated between DeploymentInProgress and Ready until it became fully Ready:

      oc get flowcollector -w
cluster   EBPF    1                 DIRECT             DeploymentInProgress
cluster   EBPF    1                 DIRECT             Ready
cluster   EBPF    1                 DIRECT             DeploymentInProgress
cluster   EBPF    1                 DIRECT             Ready
cluster   EBPF    1                 DIRECT             DeploymentInProgress
cluster   EBPF    1                 DIRECT             Ready
cluster   EBPF    1                 DIRECT             DeploymentInProgress
cluster   EBPF    1                 DIRECT             Ready
cluster   EBPF    1                 DIRECT             DeploymentInProgress
cluster   EBPF    1                 DIRECT             Ready
cluster   EBPF    1                 DIRECT             DeploymentInProgress
cluster   EBPF    1                 DIRECT             Ready

      Expected results

      It should stick to DeploymentInProgress until rollout is complete before marking it Ready and should not oscillate

      Attachments

        Issue Links

          blocks

          Story - Created by Jira Software - do not edit or delete. Issue type for a user story. NETOBSERV-1093 update test case OCP-54043 for FLP metrics PROVIDED mode

          • Minor - To be worked after urgent, high, and medium priorities are resolved. This term is chosen when the severity of the issue is low, or the complexity or effort to correct it may be higher, relatively speaking. For low priority issues, known workarounds exist or are not needed due to the trivial effort needed to address the issue.
          • Closed
          is caused by

          Bug - A problem that impairs or prevents the functions of the product. NETOBSERV-1087 Support certificate verification in FLP ServiceMonitor when certificates are provided by the user

          • Normal - To be worked after urgent and high priorities are resolved. This term is chosen when the severity of an issue is relatively close to the level of effort to fix it. The existence of an easily implemented workaround can also lead to this priority level instead of a higher priority.
          • Closed
          links to

          GitHub netobserv/network-observability-operator#450: NETOBSERV-1293: Fix status oscillation

          GitHub openshift/openshift-docs#63934: Network Observability 1.4 Release Notes

          GitHub openshift/openshift-docs#70738: Network Observability 1.5 release notes

          GitHub openshift/openshift-tests-private#14052: Better readiness check and replace wait.Poll with PollUntilContextTimeout

          Web Link RHSA-2023:121076 Network Observability 1.5.0 for OpenShift

          mentioned on

          GitLab Merge request - Updated 2 upstream sources

          Activity

            People

              ocazade@redhat.com Olivier Cazade
              rhn-support-memodi Mehul Modi
              Amogh Rameshappa Devapura Amogh Rameshappa Devapura
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: