Consul: can't find github.com/envoyproxy/go-control-plane/pkg/util

[bspp1314]

when I run "go get github.com/hashicorp/consul" in centos,The following problems occurred。

build github.com/hashicorp/consul: cannot load github.com/envoyproxy/go-control-plane/pkg/util: module github.com/envoyproxy/go-control-plane@latest found (v0.9.1), but does not contain package github.com/envoyproxy/go-control-plane/pkg/util

and my go env is

go env
GO111MODULE="on"
GOARCH="amd64"
GOBIN="/usr/local/go/bin"
GOCACHE="/root/.cache/go-build"
GOENV="/root/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/workplace/go"
GOPRIVATE=""
GOPROXY="https://goproxy.io"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/workplace/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build601479543=/tmp/go-build -gno-record-gcc-switches"

[banks]

Hi @bspp1314, which version of Go are you using? I don't see it in the env output pasted.

Go get appears to work for me here. We only support go 1.12 currently - see #6879.

[banks]

Also, not sure if it's related but this PR is needed to go get with 1.13 currently: #6938

[worming004]

Hello,
About #6938 , I didn't get the same error message. Not sure that both issues are related

[vincentjorgensen]

I encounter the same error whether I use go 1.12 or 1.13.

[gordallott]

This is still an issue, the import no longer exists in the go-control-plane repository. if go getting works for you it's likely because you have cache.

this can be fixed locally with go get -u github.com/envoyproxy/go-control-plane@61acc60f25df359e5c433b986a04b41c1da58a22 which is the last commit hash before they removed the package directory

this should be fixed in this repo by pinning github.com/envoyproxy/go-control-plane to a commit, right now the repo has been functionally non-working for months

[dantodor]

Well, I'm trying to write an integration between Envoy and Consul. I have the same issue, won't compile, even with the above hack, because I'm also using the Envoy control plane in my code. I'm baffled on how this issue is just plainly ignored. Using 0.8.0 while the control plane is at 0.9.4 ... I guess I'll just retort to using http api, and in the future trying to avoid Consul.

[stacknowledge]

Not related to consul anyways but, it was moved under:

"github.com/envoyproxy/go-control-plane/pkg/conversion"

[banks]

Thanks for the reports folks. Can someone who is seeing this give their detailed reproduction steps please? I've cleared go mod cache several times recently and can still build Consul correctly with go get:

$ go clean -modcache
$ go get github.com/hashicorp/consul
go: downloading github.com/hashicorp/consul v1.7.2
go: github.com/hashicorp/consul upgrade => v1.7.2
...
$ which consul
/Users/banks/src/go/bin/consul
$ consul version
Consul 1.7.2-dev
Protocol 2 spoken by default, understands 2 to 3 (agent will automatically use protocol >2 when speaking to compatible agents)

It's still possible this only works because of some state - I still have Consul checked out locally but this was run from a different dir but if you can provide detailed steps we can look into it.

Also worth noting that Consul's master supports go 1.14 and that's what I'm using. If you have an older go version we might be able to update the mod file to prevent this however the go version in the mod file is typically only used as a warning if the build fails it doesn't prevent older versions from actually working so you may still see the failure if it's a tooling thing between version not an API compatibility issue.

FYI while we do aim to keep Consul go gettable so want to fix this, the preferred way to build it if you actually intend to work on consul is using make dev which includes lots of other tooling that helps us develop in a consistent way.

We're aware the go-control-plane dependency is behind upstream now and will upgrade soon however it introduced some big changes we've not yet had time to refactor Consul to accommodate and we can still support all stable versions of Envoy currently without that refactor so it's not been a priority yet.

[mmailhos]

hi @banks
the go clean -modcache just triggers this issue on the following go get:

# github.com/hashicorp/consul/agent/xds
../../../../go/pkg/mod/github.com/hashicorp/[email protected]/agent/xds/clusters.go:180:3: cannot use time.Duration(cfg.LocalConnectTimeoutMs) * time.Millisecond (type time.Duration) as type *time.Duration in field value
../../../../go/pkg/mod/github.com/hashicorp/[email protected]/agent/xds/clusters.go:184:4: cannot use []endpoint.LocalityLbEndpoints literal (type []endpoint.LocalityLbEndpoints) as type []*endpoint.LocalityLbEndpoints in field value
../../../../go/pkg/mod/github.com/hashicorp/[email protected]/agent/xds/clusters.go:186:6: cannot use []endpoint.LbEndpoint literal (type []endpoint.LbEndpoint) as type []*endpoint.LbEndpoint in field value
../../../../go/pkg/mod/github.com/hashicorp/[email protected]/agent/xds/clusters.go:229:4: cannot use time.Duration(cfg.ConnectTimeoutMs) * time.Millisecond (type time.Duration) as type *time.Duration in field value
../../../../go/pkg/mod/github.com/hashicorp/[email protected]/agent/xds/clusters.go:333:4: cannot use node.Resolver.ConnectTimeout (type time.Duration) as type *time.Duration in field value
../../../../go/pkg/mod/github.com/hashicorp/[email protected]/agent/xds/clusters.go:447:3: cannot use time.Duration(cfg.ConnectTimeoutMs) * time.Millisecond (type time.Duration) as type *time.Duration in field value
../../../../go/pkg/mod/github.com/hashicorp/[email protected]/agent/xds/endpoints.go:250:3: cannot use make([]endpoint.LocalityLbEndpoints, 0, len(endpointGroups)) (type []endpoint.LocalityLbEndpoints) as type []*endpoint.LocalityLbEndpoints in field value
../../../../go/pkg/mod/github.com/hashicorp/[email protected]/agent/xds/endpoints.go:285:25: cannot use endpoint.LocalityLbEndpoints literal (type endpoint.LocalityLbEndpoints) as type *endpoint.LocalityLbEndpoints in append
../../../../go/pkg/mod/github.com/hashicorp/[email protected]/agent/xds/endpoints.go:287:4: cannot use es (type []endpoint.LbEndpoint) as type []*endpoint.LbEndpoint in field value
../../../../go/pkg/mod/github.com/hashicorp/[email protected]/agent/xds/listeners.go:243:3: cannot use makeAddress(addr, port) (type core.Address) as type *core.Address in field value

This issue is blocking our Consul upgrade as we would like to have our lib in sync with the server version (especially because it adds some features that we need like the Catalogue Node Service List)

I have just noticed this thread so you may want to close https://github.com/hashicorp/consul/issues/7765 also.

[banks]

we would like to have our lib in sync with the server

@mmailhos can you share what you are doing with your lib - does it import Consul as a dependency? In general that's not ideal as we don't guarantee API consistency outside of the /api submodule so it would help to know a bit more about your use case.

I still don't think anyone on the team here has managed to reproduce this - I've not so far which makes it pretty hard to figure out how to fix without creating a worse go mod mystery somewhere else! (Most changes we've made to fix issues like this since go mod have seemed to break someone else's workflow it seems.)

[mmailhos]

@banks actually that's a good point, I only need api v1.4.0. And go mod tidy removed consul 1.7.2 for me. Thank you!

If anyone is hitting the same issue, I have been able to properly run go get after:
go get github.com/envoyproxy/[email protected].