summaryrefslogtreecommitdiff
path: root/vendor/github.com/vishvananda/netns/README.md
diff options
context:
space:
mode:
authorPaul Holzinger <pholzing@redhat.com>2021-09-17 15:39:16 +0200
committerPaul Holzinger <pholzing@redhat.com>2021-09-22 11:51:40 +0200
commitaf49810a6e08ed084294ce03e1c8a5efb8d1a705 (patch)
tree719dbe463ccfbfc54914869576b2f1bbcf4c6680 /vendor/github.com/vishvananda/netns/README.md
parent8e2d25e93706190acf25bcf74bd18cdf98fb3a12 (diff)
downloadpodman-af49810a6e08ed084294ce03e1c8a5efb8d1a705.tar.gz
podman-af49810a6e08ed084294ce03e1c8a5efb8d1a705.tar.bz2
podman-af49810a6e08ed084294ce03e1c8a5efb8d1a705.zip
Bump CNI to v1.0.1
Update CNI so we can match wrapped errors. This should silence ENOENT warnings when trying to read the cni conflist files. Fixes #10926 Because CNI v1.0.0 contains breaking changes we have to change some import paths. Also we cannot update the CNI version used for the conflist files created by `podman network create` because this would require at least containernetwork-plugins v1.0.1 and a updated dnsname plugin. Because this will take a while until it lands in most distros we should not use this version. So keep using v0.4.0 for now. The update from checkpoint-restore/checkpointctl is also required to make sure it no longer uses CNI to read the network status. [NO TESTS NEEDED] Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Diffstat (limited to 'vendor/github.com/vishvananda/netns/README.md')
-rw-r--r--vendor/github.com/vishvananda/netns/README.md11
1 files changed, 11 insertions, 0 deletions
diff --git a/vendor/github.com/vishvananda/netns/README.md b/vendor/github.com/vishvananda/netns/README.md
index 6b45cfb89..1fdb2d3e4 100644
--- a/vendor/github.com/vishvananda/netns/README.md
+++ b/vendor/github.com/vishvananda/netns/README.md
@@ -48,3 +48,14 @@ func main() {
}
```
+
+## NOTE
+
+The library can be safely used only with Go >= 1.10 due to [golang/go#20676](https://github.com/golang/go/issues/20676).
+
+After locking a goroutine to its current OS thread with `runtime.LockOSThread()`
+and changing its network namespace, any new subsequent goroutine won't be
+scheduled on that thread while it's locked. Therefore, the new goroutine
+will run in a different namespace leading to unexpected results.
+
+See [here](https://www.weave.works/blog/linux-namespaces-golang-followup) for more details.