FailedChanges

Summary

  1. sdn: don't allow pod bandwidth/QoS changes after pod start (commit: 83a87b5) (details)
  2. ovs: split out flow parsing code, expose API, and parse actions (commit: 4a25979) (details)
  3. sdn: use OVS flow parsing utils for AlreadySetUp() (commit: 97df98d) (details)
  4. sdn: don't require netns on Update action (commit: 805157b) (details)
Commit 83a87b5a717a8f31198c5087366822a2379b66a1 by dcbw
sdn: don't allow pod bandwidth/QoS changes after pod start
In general kubelet doesn't really allow changes to pod attributes after
the pod has started.  We still want to allow VNID changes at least (for
join/split) but bandwidth is not something we really want to support
changing on-the-fly.  It's hard to figure out how to change it if we
can't get the pod's hostVethName, for which we need the pod's NetNS,
which we can't get on Update() anymore due to CRI.
(commit: 83a87b5)
The file was modifiedpkg/sdn/plugin/pod_linux.go (diff)
Commit 4a25979ff0a3d6c4059aac92145540f117353e83 by dcbw
ovs: split out flow parsing code, expose API, and parse actions
(commit: 4a25979)
The file was addedpkg/util/ovs/parse_test.go
The file was modifiedpkg/sdn/plugin/ovscontroller_test.go (diff)
The file was addedpkg/util/ovs/parse.go
The file was modifiedpkg/util/ovs/fake_ovs.go (diff)
The file was modifiedpkg/util/ovs/fake_ovs_test.go (diff)
Commit 97df98d094e74eed6e5676047fc2d8d8d035fcae by dcbw
sdn: use OVS flow parsing utils for AlreadySetUp()
(commit: 97df98d)
The file was modifiedpkg/sdn/plugin/ovscontroller_test.go (diff)
The file was modifiedpkg/sdn/plugin/ovscontroller.go (diff)
Commit 805157b27272fad86e631afc0b9a4d450d290552 by dcbw
sdn: don't require netns on Update action
With the move to CRI, we don't get a Docker runtime from which we can
grab the container's NetNS on update.  But we don't actually need one,
we can scrape OVS flows and grab the required details from there.
The one downside is that if OpenShift crashed before pod flows were
added, we cannot read the pod details on restart, and the pod will be
left "ready" (because Docker started it) but with broken networking
(because we can't fix it), but that's something that should be fixed
upstream by ensuring that pods which have not successfully completed
network setup are not considered "ready" by the runtime.
(commit: 805157b)
The file was modifiedpkg/sdn/plugin/pod_linux.go (diff)
The file was modifiedpkg/sdn/plugin/ovscontroller_test.go (diff)
The file was modifiedpkg/sdn/plugin/ovscontroller.go (diff)