Writing a k8s operator defaultvm in kubebuilder mainly strings up the creation of ovn network and virtual machine to provide default available virtual machine for users.

Kubebuilder is a framework for building the Kubernetes API based on CRD, which can be used to build APIs, Controller s, and Admission Webhook s.

The code calls virtualmachine defined by kubevirt.io/client-go, uses go mod for dependency management, and refers to kubevirt.io/client-go v0.23.0 by default, but compiles incorrectly without getting the package of prometheus

go: github.com/prometheus/prometheus@v2.9.2+incompatible: unexpected status (https://goproxy.io/github.com/prometheus/prometheus/@v/v2.9.2+incompatible.info): 410 Gone

Confirm Dependency Issues

Use go mod download alone to verify that packages do not get pulled.

[root@master01 queqiao]# go mod download github.com/prometheus/prometheus@v2.9.2+incompatible
go: finding github.com/prometheus/prometheus v2.9.2+incompatible
github.com/prometheus/prometheus@v2.9.2+incompatible: reading https://goproxy.io/github.com/prometheus/prometheus/@v/v2.9.2+incompatible.info: 410 Gone

google found a statement that for domestic wall reasons, only export GOPROXY=https://goproxy.io&export GO111MODULE=on can be used, and goproxy.io lacks support for prometheus@v2.9.2+incompatible.You can try to change GOPROXY to direct, export GOPROXY=direct, but because of the domestic fgw, when you change to direct, you get stuck and can only give up.

Cut-down version of kubevirt

prometheus@v2.9.2+incompatible is a dependence of kubevit and we can't control it. We can only control kubevirt. We know from our little partner that kubevit v0.19.0 has no dependence on prometheus v2.9.2+incompatible.

go mod edit -replace=kubevirt.io/client-go@v0.23.0=kubevirt.io/client-go@v0.19.0

Switch back to kubevit v0.19.0 using go mod edit and the compilation is successful.Sadly, however, after a period of debugging, a new bug in kubevirt was triggered and fixed in v0.23.0

Reference resources: https://github.com/kubevirt/k...

So we can only face the dependency problem again

Pull kubevirt code

In order not to rely on kubevirt, we decided to dig out the definition of virtual machine in kubevirt directly.This worked, reducing the dependency on kubevirt, but cr eating a series of versions mismatch between packages that I didn't expect

For example: the first error encountered

# k8s.io/client-go/rest
vendor/k8s.io/client-go/rest/request.go:598:31: not enough arguments in call to watch.NewStreamWatcher
    have (*versioned.Decoder)
    want (watch.Decoder, watch.Reporter)

Dependent libraries of go are all managed automatically with go mod, and it is unexpected that there will be version mismatch between dependent libraries.

Match Dependent Library Version

Since there are problems with go mod management, you can only start with the problem and manually match the correct version of the dependent library.

Reference resources: https://github.com/kubernetes...

That apimachinery change is in the master branch, and the call you linked to is updated in client-go on master.

The client-go@v11.0.0 tag works with the release-1.14 branch of apimachinery, which still has the signature that matches client-go v11.0.0:

https://github.com/kubernetes/apimachinery/blob/release-1.14/pkg/watch/streamwatcher.go#L51-L52

Ensure you are using the release-1.14 branch of apimachinery.

Use release-1.14 apimachinery, as prompted by the big man.

[root@master01 queqiao]# go mod download -json k8s.io/apimachinery@release-1.14
go: finding k8s.io/apimachinery release-1.14
go: finding k8s.io/apimachinery latest
{
    "Path": "k8s.io/apimachinery",
    "Version": "v0.0.0-20191004074956-c5d2f014d689",
    "Info": "/root/go/pkg/mod/cache/download/k8s.io/apimachinery/@v/v0.0.0-20191004074956-c5d2f014d689.info",
    "GoMod": "/root/go/pkg/mod/cache/download/k8s.io/apimachinery/@v/v0.0.0-20191004074956-c5d2f014d689.mod",
    "Zip": "/root/go/pkg/mod/cache/download/k8s.io/apimachinery/@v/v0.0.0-20191004074956-c5d2f014d689.zip",
    "Dir": "/root/go/pkg/mod/k8s.io/apimachinery@v0.0.0-20191004074956-c5d2f014d689",
    "Sum": "h1:q9CWH+mCm21qUeXH537D0Q9K1jdEkreNSRU5E7jh+QM=",
    "GoModSum": "h1:ccL7Eh7zubPUSh9A3USN90/OzHNSVN6zxzde07TDCL0="
}

The previous error was actually resolved.However, there are still new errors, which rely on library calls to troubleshoot, then switch to release-1.14 in a similar way, and the manually configured version of the dependent Library in go.mod is:

replace (
    k8s.io/api => k8s.io/api v0.0.0-20191004102349-159aefb8556b
    k8s.io/apiextensions-apiserver => k8s.io/apiextensions-apiserver v0.0.0-20191004105649-b14e3c49469a
    k8s.io/apimachinery => k8s.io/apimachinery v0.0.0-20191004074956-c5d2f014d689
    sigs.k8s.io/controller-runtime => sigs.k8s.io/controller-runtime v0.3.0
)

Finally, mention sigs.k8s.io/controller-runtime, look at all its versions, and try again and again to find that v0.3.0 can be compiled and passed.

Mood

This dependency library problem took me nearly two days, during which I searched a lot of methods, stepped on a lot of pits, much worse than described in the article.Write it down because you are in a bad mood. On the one hand, you can deepen your experience, on the other hand, you can hope to help a little partner who also has this problem.

in the peace