vendor: remove most "replace" rules and update github.com/armon/go-radix#44498
vendor: remove most "replace" rules and update github.com/armon/go-radix#44498thaJeztah merged 3 commits intomoby:masterfrom
Conversation
thaJeztah
commented
Nov 18, 2022
- fixes libnetwork: NetworkDB: fix synchronisation and upgrade github.com/armon/go-radix #42646
- fixes libnetwork: fix (or replace) usage of github.com/armon/go-radix #43753
- fixes vendor: github.com/armon/go-radix v1.0.0 libnetwork#2581 (comment)
- fixes PANIC due to a nil pointer derefence or illegal memory address during whatever looks to be an internal "clean networks up" operation. #42645
- relates to Allow calling Delete() inside Walk() and WalkPrefix() armon/go-radix#22
Previously we had to use a replace rule, as later versions of this module resulted in a panic. This issue was fixed in: armon/go-radix@f30034d Which means we can remove the replace rule, and update the dependency. No new release was tagged yet, so sticking to a "commit" for now. Signed-off-by: Sebastiaan van Stijn <[email protected]>
While this replace was needed in swarmkit itself, it looks like it doesn't cause issues when removed in this repository, so let's remove it here. Signed-off-by: Sebastiaan van Stijn <[email protected]>
Signed-off-by: Sebastiaan van Stijn <[email protected]>
| github.com/golang/protobuf v1.5.2 // indirect | ||
| github.com/google/btree v1.1.2 // indirect | ||
| github.com/google/certificate-transparency-go v1.1.2 // indirect | ||
| github.com/google/certificate-transparency-go v1.1.2 // indirect; replaced; see "replace" section at the bottom of this file for the actual version. |
There was a problem hiding this comment.
| github.com/google/certificate-transparency-go v1.1.2 // indirect; replaced; see "replace" section at the bottom of this file for the actual version. | |
| github.com/google/certificate-transparency-go v1.1.2 // indirect; replaced |
I don't think we need the full explanation, the semantics of go.mod and replace directives should be well known/I would expect anyone sophisticated enough to edit a go.mod to know where to look for replacement rules.
There was a problem hiding this comment.
I tried to be explicit, as it's definitely not obvious to many (I know many missed it in the BuildKit repository, and ended up with "unpredictable" outcomes.
There was a problem hiding this comment.
Fair enough; if you think it's helpful I don't think it's objectionable 😆
There was a problem hiding this comment.
| // swarmkit) by pinning the certificate-transparency-go version. Remove once | ||
| // module go.etcd.io/etcd/server/v3 has upgraded its dependency on | ||
| // go.opentelemetry.io/otel to v1. | ||
| replace github.com/google/certificate-transparency-go => github.com/google/certificate-transparency-go v1.0.20 |
There was a problem hiding this comment.
You don't need this anymore, etcd upgraded to otel v1.
There was a problem hiding this comment.
There was a problem hiding this comment.
Yes, working on that one (currently struggling with SwarmKit CI), so I'll do that in a follow-up 😄
| github.com/Microsoft/hcsshim v0.9.5 | ||
| github.com/RackSec/srslog v0.0.0-20180709174129-a4725f04ec91 | ||
| github.com/armon/go-radix v0.0.0-20180808171621-7fddfc383310 | ||
| github.com/armon/go-radix v1.0.1-0.20221118154546-54df44f2176c |
There was a problem hiding this comment.
In case you change your mind and prefer a better maintained repo: https://github.com/moby/moby/compare/master...tiborvass:immutable_radix?expand=1
There was a problem hiding this comment.
That was my initial attempt in moby/libnetwork#2581, but (don't recall exactly) I think it didn't work. But must admit that I didn't dive deeply into why (or forgot that I did) 😂
There was a problem hiding this comment.
What was the problem? From looking at your branch, what possibly didn't work is that you take the lock twice. createOrUpdateEntry should not have a lock because the caller has to lock.
I'm opening #44501 we can discuss it there.
|
Let me bring these in as a stepping-stone, then look at #44501 |