Uploaded image for project: 'OpenShift Core Networking'
  1. OpenShift Core Networking
  2. CORENET-5161

Fix CNO logic to restart pods on configMap changes

XMLWordPrintable

    • Icon: Story Story
    • Resolution: Won't Do
    • Icon: Undefined Undefined
    • None
    • None
    • None
    • Future Sustainability
    • False
    • Hide

      None

      Show
      None
    • False
    • None
    • None
    • None
    • SDN Sprint 254, SDN Sprint 255

      Now we use multiple files to pass config parameters

      https://github.com/openshift/cluster-network-operator/blob/6aa2f0fbf2b06ce52db1a2a039bbdbcaf588c409/bindata/network/ovn-kubernetes/common/008-script-lib.yaml is only used by ovnkube-node to start its containers like https://github.com/openshift/cluster-network-operator/blob/6aa2f0fbf2b06ce52db1a2a039bbdbcaf588c409/bindata/network/ovn-kubernetes/self-hosted/ovnkube-node.yaml#L137

      every version of that configmap is hashed by https://github.com/openshift/cluster-network-operator/blob/6aa2f0fbf2b06ce52db1a2a039bbdbcaf588c409/pkg/network/ovn_kubernetes.go#L356-L378  and included to ovnkube-node DS as an annotation https://github.com/openshift/cluster-network-operator/blob/6aa2f0fbf2b06ce52db1a2a039bbdbcaf588c409/bindata/network/ovn-kubernetes/self-hosted/ovnkube-node.yaml#L37  which causes ovnkube-node ds to restart ovnkube-node pods on every configmap change, and ovnkube-node picks up new config.

      At the same time we have another configmap https://github.com/openshift/cluster-network-operator/blob/master/bindata/network/ovn-kubernetes/self-hosted/004-config.yaml that is used both by script-lib (aka by ovnkube-node) https://github.com/openshift/cluster-network-operator/blob/6aa2f0fbf2b06ce52db1a2a039bbdbcaf588c409/bindata/network/ovn-kubernetes/common/008-script-lib.yaml#L590 and control-plane https://github.com/openshift/cluster-network-operator/blob/6aa2f0fbf2b06ce52db1a2a039bbdbcaf588c409/bindata/network/ovn-kubernetes/self-hosted/ovnkube-control-plane.yaml#L131 . This configmap is not hashed in any way in the spec, so it will not cause components restart when some values are updated. That may cause problems, e.g. for feature-gated features, that will not cause control-plane restart when the feature gate is enabled. There are some variables that should cause control-plane restart, all of them are listed directly in the DS spec, e.g. https://github.com/openshift/cluster-network-operator/blob/6aa2f0fbf2b06ce52db1a2a039bbdbcaf588c409/bindata/network/ovn-kubernetes/self-hosted/ovnkube-control-plane.yaml#L110

      we should figure out a common way for both ovnkube-node and control-plane to be restarted on configmap updates.

              npinaeva@redhat.com Nadia Pinaeva (Inactive)
              npinaeva@redhat.com Nadia Pinaeva (Inactive)
              None
              None
              None
              None
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated:
                Resolved: