"operator-sdk init" fails while updating "go.mod"

[umangachapagain]

Bug Report

What did you do?

In a project that has rook v1.4.5 as dependency in go.mod, I ran operator-sdk init

What did you expect to see?

Project initialized correctly with updated dependency.

What did you see instead? Under which circumstances?

go: github.com/rook/[email protected] requires
	k8s.io/[email protected]: reading k8s.io/kube-controller-manager/go.mod at revision v0.0.0: unknown revision v0.0.0
Error: failed to initialize project with version "3-alpha": exit status 1

Environment

Operator type:

Kubernetes cluster type:

$ operator-sdk version : operator-sdk version: "v1.0.1", commit: "4169b318b578156ed56530f373d328276d040a1b", kubernetes version: "v1.18.2", go version: "go1.13.15 linux/amd64", GOOS: "linux", GOARCH: "amd64"

$ go version (if language is Go) go version go1.15.2 linux/amd64

$ kubectl version

Possible Solution

Additional context

go get github.com/rook/[email protected] works but operator-sdk init complains about dependency.

Bug raised on Rook: rook/rook#6428

[camilamacedo86]

Hi @umangachapagain,

The default scaffold shows not download this dep. I am unable to get it as well.

camilamacedo@Camilas-MacBook-Pro ~/go/src/mytest (master) $ go get github.com/rook/[email protected]
go: finding github.com/rook/rook v1.4.5
go: finding github.com/rook v1.4.5
go: finding github.com v1.4.5
go: downloading github.com/rook/rook v1.4.5
go: extracting github.com/rook/rook v1.4.5
go get: github.com/rook/[email protected] requires
	k8s.io/[email protected]: reading k8s.io/kube-controller-manager/go.mod at revision v0.0.0: unknown revision v0.0.0
camilamacedo@Camilas-MacBook-Pro ~/go/src/mytest (master) $ rm -rf *
camilamacedo@Camilas-MacBook-Pro ~/go/src/mytest (master) $ operator-sdk init
Writing scaffold for you to edit...
Get controller runtime:
$ go get sigs.k8s.io/[email protected]
Update go.mod:
$ go mod tidy
Running make:
$ make
/Users/camilamacedo/go/bin/controller-gen object:headerFile="hack/boilerplate.go.txt" paths="./..."
go fmt ./...
go vet ./...
go build -o bin/manager main.go
Next: define a resource with:
$ operator-sdk create api
camilamacedo@Camilas-MacBook-Pro ~/go/src/mytest (master) $ 

Are your GOPROXY env with "https://proxy.golang.org,direct"?

[umangachapagain]

Hi @umangachapagain,

The default scaffold shows not download this dep. I am unable to get it as well.

camilamacedo@Camilas-MacBook-Pro ~/go/src/mytest (master) $ go get github.com/rook/[email protected]
go: finding github.com/rook/rook v1.4.5
go: finding github.com/rook v1.4.5
go: finding github.com v1.4.5
go: downloading github.com/rook/rook v1.4.5
go: extracting github.com/rook/rook v1.4.5
go get: github.com/rook/[email protected] requires
	k8s.io/[email protected]: reading k8s.io/kube-controller-manager/go.mod at revision v0.0.0: unknown revision v0.0.0

This worked for me for some reason. According to rook/rook#6428 (comment) it was always working.

camilamacedo@Camilas-MacBook-Pro ~/go/src/mytest (master) $ rm -rf *
camilamacedo@Camilas-MacBook-Pro ~/go/src/mytest (master) $ operator-sdk init
Writing scaffold for you to edit...
Get controller runtime:
$ go get sigs.k8s.io/[email protected]
Update go.mod:
$ go mod tidy
Running make:
$ make
/Users/camilamacedo/go/bin/controller-gen object:headerFile="hack/boilerplate.go.txt" paths="./..."
go fmt ./...
go vet ./...
go build -o bin/manager main.go
Next: define a resource with:
$ operator-sdk create api
camilamacedo@Camilas-MacBook-Pro ~/go/src/mytest (master) $

Are your GOPROXY env with "https://proxy.golang.org,direct"?

I have GOPROXY=https://proxy.golang.org

[camilamacedo86]

So, could you please update your GOPROXY for the default configuration "https://proxy.golang.org,direct" and let us know if the problem will be solved for you?

[joelanford]

@umangachapagain It looks like one of your dependencies depends on k8s.io/[email protected], which is not a real version. You would need to use a replace k8s.io/kube-controller-manager => k8s.io/kube-controller-manager <some version> line in your go.mod file.

[umangachapagain]

@umangachapagain It looks like one of your dependencies depends on k8s.io/[email protected], which is not a real version. You would need to use a replace k8s.io/kube-controller-manager => k8s.io/kube-controller-manager <some version> line in your go.mod file.

We do use that. And, like I said go get works but scaffolding doesn't.
I even updated my project to Rook 1.4.5 and then tried sdk init, it still complains about the dependency.

[umangachapagain]

So, could you please update your GOPROXY for the default configuration "https://proxy.golang.org,direct" and let us know if the problem will be solved for you?

Didn't work.

[camilamacedo86]

Hi @umangachapagain,

In a project that has rook v1.4.5 as dependency in go.mod, I ran operator-sdk init

You have a project already and then you are trying to init a project on it. it shows that you have conflicts of go mod dependencies whcih is related to your customizations.

I'd recommend you do:

• create a new dir
• run the operator-sdk init
• then check its go.mod and try to update your existent project to have the same deps and versions
• after you make it works then try to run the init inside of your project

It might solve, however, the tool is not developed to address this scenario. I mean, it is expected the dir where the tool will be executed is empty. So, it is not possible to ensure that it will not face issues in your scenario. Shows that your goal is to migrate your project to use the tool then, I'd like to recommend you the following steps :

• create a new project with the tool in an empty dir
• scaffold the APIs used in your project with the same GKV
• Then, port your implementation to the new project

[camilamacedo86]

Hi @umangachapagain,

This issue was discussed in the bug triage meeting and then we reach a consensus that the recommended path to make a pre-existing project to work with the tool would be scaffold a new project and then, copy and past your implementation accordingly. See that it would not be the only possible issue faced and try to make the project work with the tool by running operator-sdk init on that will means much more work and effort than just copy and paste.

Also, we are thinking about to limit this option for the v3+ plugins and make simplicity that the dir where was executed the command operator-sdk init should be empty or do not have the specific files and directories. See: #4067

Anyway, a few options and explanation were provided in #4027 (comment) and #4027 (comment). So, we are closing this one since it would not be the workflow recommended. However, please feel free to ping us and/or raise new issues if you need.